i2p.www/i2p2www/meetings/logs/247.log

20:00:05 <zzz> 0) Hi
20:00:05 <zzz> 1) Items open from previous meetings http://zzz.i2p/topics/2093
20:00:05 <zzz> 2) Replacement of kytv roles and services http://zzz.i2p/topics/2098
20:00:05 <zzz> 3) 0.9.26 planning update http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960
20:00:05 <zzz> 4) HOPE planning http://zzz.i2p/topics/1968
20:00:05 <zzz> 5) Brief review of monthly meetings and project management after 3 months
20:00:10 <zzz> 0) Hi
20:00:12 <zzz> hi
20:00:38 <zzz> 1) Items open from previous meetings http://zzz.i2p/topics/2093
20:00:55 <orignal_> hi
20:01:00 <zzz> - Reseed campaign prep, by end of January:
20:01:00 <zzz> ** Sadie to contact backup to discuss OPEN, new date April 5
20:01:11 <zzz> sadie, status?
20:02:10 <zzz> - Strengthing the network - home page and additional pages
20:02:10 <zzz> ** str4d, gravy, cacapo: Add use cases, what are we best at, more "passion" and "fat", add / highlight Bote, by end of January OPEN, str4d to add use cases to website by Mar. 6, more changes on passion etc by Apr. 5
20:02:15 <zzz> str4d, status?
20:03:06 <zzz> - Add I2P "Story" / history / why
20:03:06 <zzz> ** comraden to edit / polish / enhance / post by end of February OPEN, new date Apr. 1, draft back to zzz by mid-March
20:03:11 <zzz> comradenosebleed, status?
20:03:34 <str4d> hi
20:04:40 <zzz> Ticket management - currently ad hoc
20:04:40 <zzz> ** Sadie to review, make recommendations or possibly start managing them (by when?) OPEN, str4d and sadie to schedule meeting or make report by April 5(?)
20:04:50 <zzz> sadie, str4d: status?
20:05:49 <hottuna> hi
20:05:59 <zzz> str4d  OPEN - Android 0.9.24 release March 3, TODO list collated by March 6, roadmap draft by March 6, to be reviewed March 5-6
20:06:05 <zzz> str4d, status?
20:06:33 <str4d> We discussed it
20:06:41 <str4d> (sorry, doing 2 meetings at once)
20:06:54 <zzz> str4d and zzz to review VRP ticket by Feb 12; Will make some decisions during March 5-6 roadmap meetings (zzz done feb. 8, str4d by March 6)
20:06:56 <str4d> re: tickets
20:06:57 <zzz> str4d, status?
20:07:29 <zzz> sadie and anonimal to come back with a CoC edits based on Monero 0mq at the April 5 meeting
20:07:36 <zzz> sadie, anonimal: status?
20:08:25 <str4d> I decided previously to have the "new" status for tickets that need triaging, and I still think that is the way to go
20:09:00 <str4d> I also think it might be a good idea to set up a regular time for a few of us to go through these tickets
20:09:09 <str4d> re: android
20:09:59 <str4d> Hasn't happened yet because blocking on the build script
20:10:17 <eche|on> uhh
20:10:54 <str4d> VRP ticket: hasn't happened yet because I've been sick when I was planning to work on it
20:11:00 <zzz> it's clear that the current project management style isn't working because nothing is happening. Let's move on, and I put 5) on the agenda to decide if we should continue monthly meetings or not
20:11:10 <zzz> almost all of these items are 3 1/3 months old
20:11:19 <str4d> What *has* happened, which is not on zzz's list, is I finished the spec migration and am well into migrating the proposals
20:11:37 <zzz> great news on specs/proposals, well done
20:12:09 <str4d> So I'd argue that "nothing" is incorrect, just moving prioritisations that aren't reflected in the current PM style
20:12:17 <str4d> So yes, we need to refine
20:12:20 <zzz> ok. good perspective
20:12:25 <zzz> anything else on 1) ?
20:13:04 <str4d> For everyone else here, the proposal stuff is at http://vekw35szhzysfq7cwsly37coegsnb4rrsggy5k4wtasa6c34gy5a.b32.i2p/spec/proposals - please review and comment :)
20:13:26 <zzz> 2) Replacement of kytv roles and services http://zzz.i2p/topics/2098
20:13:34 <zzz> there's a list of about 20 things he did
20:13:44 <str4d> Nothing else for me
20:13:47 <str4d> (I did do I2P Android work, just didn't quite get to release)
20:13:55 <zzz> I've been focused on what I saw as the highest priorities - launchpad and debian
20:14:14 <zzz> some others are researching other things, and we swapped out a couple of console home page links in .25
20:14:33 <zzz> to me the next most important thing is tails maintainer
20:15:06 <zzz> is there anybody here that knows tails AND debian packaging and can help? if not, I will put out the call on twitter asap
20:15:24 <zzz> we will be thrown out of tails in as soon as the next release in two months
20:15:32 <zzz> 2.4 I believe
20:15:50 <zzz> it's more than I can handle. I won't be doing it.
20:16:02 <str4d> Ugh
20:16:19 <str4d> What does Tails require at a minimum
20:16:19 <str4d> ?
20:16:20 <zzz> job is to take the debian packaging I do, and tweak/insert into tails, test test test, plus a number of existing tails i2p tickets
20:16:49 <zzz> there's a big writeup that kytv did i think, it's linked from the kytv thread on zzz.i2p
20:17:04 <zzz> basically the input to tails is a deb package
20:17:19 <zzz> but I think they have a backlog of grievances
20:17:25 <eche|on> call out on twitter
20:17:33 <str4d> +1 on Twitter
20:17:35 <zzz> anybody else have anything to report on kytv replacement stuff?
20:18:07 <str4d> I haven't made any more movement on the Buildbot CI server since I last mentioned it in IRC a week or two ago
20:18:23 <str4d> I'll do some more work on it this weekend
20:18:42 <zzz> ok. there's a lot on the list, lets everybody pick something important.
20:19:02 <zzz> last call for 2)
20:19:46 <str4d> If no one else does it, I *may* pick up the IRC bot/relay. Unlikely for now.
20:20:34 <zzz> i think the deb builds are in decent shape but there's still some stuff like arm for jessie that I may have fixed today, or may not have
20:21:19 <zzz> 3) 0.9.26 planning update http://i2p-projekt.i2p/en/get-involved/roadmap http://zzz.i2p/topics/1960
20:21:33 <zzz> ok I want to do 3a) schedule and then 3b) GMP 6
20:21:38 <zzz> 3a) schedule
20:22:03 <zzz> the roadmap says 'may' and 6-7 weeks from the last release march 22 would be early-mid may
20:22:36 <zzz> at the roadmap meetings a month ago, we came up with an ambitious plan including the addressbook subscription protocol
20:23:16 <zzz> but that all fell apart the next day as kytv's stuff all went down and it grew less likely he would return
20:23:36 <zzz> so I haven't started yet on anything 26-related. last 2-3 weeks have been full time debian/launchpad stuff
20:24:01 <str4d> ~seven weeks from now is the end of May. Do you think that would be feasible?
20:24:15 <str4d> (Now that the debian stuff is mostly under control)
20:24:19 <zzz> that will push 26 to probably June, and will be well past the tails 2.4 deadline
20:24:37 <str4d> Ugh
20:24:37 <zzz> end may could happen, but getting less likely by the day
20:24:42 <str4d> When is the tails deadline?
20:25:11 <zzz> don't know offhand. I already re-asked them to pull in 25 themselves (they refused once already)
20:25:23 <eche|on> I think june is fine, as tails is on the judge currently
20:25:45 <zzz> they don't have any visibility as to tails i2p usage and don't hear any clamor, so they see it as more trouble than it's worth
20:26:18 <eche|on> yeas
20:26:33 <zzz> normally for a big feature like addressbook subscription protocol, I'd be done with it a week before the _previous_ release, ready to prop
20:26:54 <zzz> so that's 3 weeks behind, plus the dev time which is a couple weeks at least, or 5 weeks behind total
20:27:39 <zzz> so that's the status. I haven't pushed anything out on the official roadmap yet, but will need to soon
20:27:49 <zzz> anything else on 3a) schedule ?
20:27:58 <str4d> What did we have planned to go in the actual 0.9.27 release?
20:28:16 <zzz> see the roadmap link above
20:28:31 <zzz> early ntcp2/dh/pt
20:29:18 <str4d> I still think things need to happen in the order there, so what we *could* do is push the address subscription protocol to 0.9.27
20:29:27 <str4d> That gives you May to work on it
20:29:47 <zzz> but there is no .26 yet. nothing has happened. there's nothing in there but deb changes
20:29:50 <str4d> And then .26 can be CRLs and some general cleanup maybe
20:30:08 <zzz> until somebody (including me) does something, there's nothing to release
20:30:27 <zzz> so we'll see how it goes. I gotta take a couple days off to do my taxes also :)
20:30:37 <zzz> anything else on 3a) schedule ?
20:30:55 <eche|on> do not look to hard on the planned schedule
20:30:56 <str4d> I have some initial UI tweaks that have come out of my and sadie's discussions that I could get applied
20:31:20 <zzz> 3b) GMP 6
20:31:25 <str4d> (not the major redesign I have planned but some general refinements)
20:31:50 <zzz> after about 15 months of work, tuna and I are close to ready to prop over the gmp6 branch to trunk for 26
20:32:05 <zzz> tuna has about a hundred binaries built over the last 6 months, awaiting checkin
20:32:25 <zzz> built in a variety of ways - vms, native, microsoft, borrowed systems, etc.
20:32:53 <zzz> traditionally we've checked in detailed notes on the build environment (compiler revs, system os details etc) for each binary we check in
20:33:13 <zzz> unfortunately, tuna kept no records on any of the builds. 
20:34:06 <zzz> so the question is, do we start over (possibly costing us 6 months), or I just build the linux binaries and ignore everything else, or do we not really need these notes and we proceed with taking everything tuna has done? 
20:34:08 <eche|on> any chance to redo them?
20:34:47 <zzz> tuna says impossible. anybody could build the linux 32/64 binaries. but all the rest is problematic
20:35:00 <eche|on> good question, in this case: redo or take, not way in between
20:35:25 <eche|on> we need the mac, win and arm gmp stuff
20:35:29 <zzz> last tuna told me was take it or leave it, he's done
20:35:54 <zzz> even if the builds are fast, the testing is slow
20:36:25 <str4d> Do we have the test process written up somewhere?
20:36:54 <zzz> if you go to the last page of http://zzz.i2p/topics/1960 he's submitted all the build notes he has
20:36:56 <eche|on> (just to note, we did accept some other stuff without notes already)
20:37:07 <str4d> because this sounds exactly like what we should be putting into a CI server
20:37:38 <zzz> he's updated the readme's on how to build. there's some info in the thread on how to test, and I've developed my own methods also
20:38:07 <zzz> recall that he has released 13 versions of the binaries collection over the last 6 months
20:38:36 <zzz> hottuna, you have anything to add?
20:38:37 <str4d> If someone can write up a test methodology, I can get that turned into a build type in Buildbot
20:38:58 <str4d> Then it's just finding machines to hook that up to.
20:39:08 <hottuna> one sec
20:39:24 <str4d> I'm thinking we should probably just invest in a Mac that we can leave running somewhere as a buildslave
20:39:44 <hottuna> eche|on: re rebuild: not impossible, but it's too much work for me now. by far.
20:40:02 <str4d> nothing too expensive, but something that we can actually use to complete the trio (we already will have linux and windows buildslaves once I get VM stuff sorted with eche)
20:40:10 <eche|on> hottuna: is there any way on howto rebuilt ? 
20:40:27 <zzz> even if the build for all 100 files happened tomorrow, it would be 3 months to test
20:40:39 <hottuna> there is a readme document that _should_ contain everything you need.
20:40:48 <str4d> At the very least, we have benefited from hottuna's improvements to the various scripts
20:41:10 <str4d> But the other question is, if we rebuild now, do we skip to 6.1
20:41:11 <zzz> plus there's massive changes in the cpuid code itself
20:41:23 <hottuna> str4d: the scripts aren't flawless now, but they're better anyway.
20:41:23 <zzz> right, maybe 6.1
20:41:25 <str4d> Yep
20:41:30 <hottuna> str4d: if we rebuild, we should skip to 6.1
20:41:44 <eche|on> does the new code work fine?
20:41:57 <hottuna> eche|on: as far as we know it's bug free (hah!).
20:42:07 <zzz> of course on debian builds, we link dynamically, so you'd get 6.1 anyway if installed (and that reminds me, we haven't tested gmp 6 dynamic libs)
20:42:10 <str4d> I'm just not sure how much the scripts need to change to do 6.1, but I'd hope it basically works drop-in
20:42:14 <eche|on> if the tests were fine, include it. and lets rebuild with 6.1 in a sidechannel and let the info get in later
20:42:38 <eche|on> as I see it, we did test it quite well yet
20:42:51 <hottuna> eche|on: the tricky part was not really running the actual scripts. getting machines, setting up environments and testing was the tricky/slow part
20:43:03 <eche|on> yeah
20:43:13 <str4d> hottuna, that is what I want to get into CI
20:43:15 <zzz> let's get back to the original question. Do we want to throw out 6 months of work (actually been at it since early 2015) or can we accept the binaries we have, without any notes on the specifics
20:43:25 <str4d> How many distinct machines do you think you used?
20:43:37 <zzz> let's put aside CI etc. for the moment and decide if we have a problem or not
20:43:52 <hottuna> str4d: it should be mostly drop in, with an added target or two. no point in not having support for the latest archs supported by gmp
20:44:13 <str4d> zzz, I'd be inclined to accept the binaries predicated on us doing a migration to 6.1
20:44:24 <hottuna> str4d: ~6 distinct environments
20:44:29 <zzz> 6.1 is on the roadmap for the end of this year
20:44:39 <zzz> the current binaries are 6.0
20:44:41 <str4d> What are the knock-on effects of us accepting the binaries?
20:44:41 <hottuna> str4d: no machines necessarily due when cross-compiling
20:44:51 <str4d> 1) they end up in mtn
20:45:01 <zzz> also recall, it gives us big speedups on certain hardware, and also constant time
20:45:17 <str4d> 2) they get bundled into the relevant update and install files
20:45:21 <zzz> 'knock-on effect' = bad things?
20:45:28 <str4d> 2a) increasing the update filesize a lot
20:45:44 <str4d> 3) if it is broken on any particular system, what happens?
20:46:03 <str4d> We were planning on 1) anyway
20:46:26 <zzz> we only check in the binaries if they will be immediately propped for .26.
20:46:28 <str4d> Likewise on 2), but the 6.0 binaries would be replaced by the 6.1 ones so that's no big deal
20:46:37 <str4d> The one that concerns me is 3)
20:46:43 <zzz> only binaries for release will be checked in
20:47:00 <str4d> 3a) is there any existing code to check for a failure state?
20:47:04 <zzz> 3) is a generic risk for any change
20:47:19 <zzz> failures in gmp are generally JVM crash
20:47:26 <str4d> 3b) Is there a way to fall back to an older working libjbigi?
20:47:44 <str4d> (either automatic or manual)
20:48:00 <str4d> Could we e.g. rename the old libjbigi so if there is a problem, we can tell users "go rename this file"
20:48:22 <zzz> str4d, you're exploring whether we should ever change jbigi at all? these are generic impacts for changing gmp at all
20:49:14 <str4d> zzz, your concern is not knowing the precise origin of these binaries. My assumption then is that we are concerned that if there is a problem, it becomes much harder to track down the source.
20:49:27 <str4d> So I'm thinking in terms of mitigation strategies
20:50:00 <zzz> we could not include jbigi.jar in the 26 update, so only new installs would get it. That would be a slower roll.
20:50:25 <zzz> new installs + launchpad/deb
20:50:57 <zzz> the generic fix is to remove libjbigi.so and jbigi.jar, then you do without
20:51:01 <str4d> That might be a good idea anyway
20:51:30 <str4d> Roll out to new installs, and if we don't hear any problems, roll out in updates in the next release.
20:51:43 <zzz> I guess tuna's point is that nothing is reproducible anyway. It's all borrowed systems and long-gone VMs
20:52:23 <zzz> eche|on, is the system and msvc info from the box hottuna used for the win builds available?
20:53:10 <zzz> tuna didn't volunteer for any research at all but didn't he borrow sadie's laptop too? or is it all useless as upgrades may have happend in the meantime?
20:53:24 <eche|on> he had access to the win 10 machine on my kvm host. I cna login and check
20:53:33 <str4d> Mmm, which is why I'd like to do the 6.1 builds in Buildbot with buildservers we can track.
20:53:57 <hottuna> zzz: i borrowed two separate friends' osx machines
20:53:58 <eche|on> I did not change the vm at all
20:54:33 <zzz> nobody has even volunteered to take a free mac we pay for, because nobody wants to be the 'mac guy'
20:54:51 <zzz> so it's really a lack of time and people, not money
20:55:17 <hottuna> zzz: I just don't want gadgets I have to lug around.
20:56:01 <zzz> here's hottuna's complete build notes:
20:56:03 <zzz> Build notes jbigi:
20:56:03 <zzz> ------------------
20:56:03 <zzz> Windows: Cross-compile, linux hosts. Compiler: GCC
20:56:03 <zzz> Linux: Native build. Compiler: GCC
20:56:03 <zzz> FreeBSD: Native build, VM. Compiler: GCC
20:56:03 <zzz> OSX: Native build. Compiler: GCC
20:56:03 <zzz> Build notes jcpuid:
20:56:03 <zzz> -------------------
20:56:03 <zzz> Windows: Native build. Compiler: MSVC
20:56:03 <zzz> Linux: Native build. Compiler: GCC
20:56:03 <zzz> FreeBSD: Native build. Compiler: GCC
20:56:03 <zzz> OSX: Native build. Compiler: GCC
20:56:17 <zzz> are these sufficient or do we start over?
20:57:14 <str4d> Given that we are going to migrate to 6.1 by the end of the year, and these binaries have had reasonable testing, I'm inclined to say yes.
20:57:41 <zzz> any objections?
20:57:45 <eche|on> it is at least a start, but in terms of "Tor reproduceable builds" it is nothing. what kind of standards do we want?
20:58:03 <hottuna> no
20:58:34 <eche|on> I would like to include them in new installs with the "temp" flag. I know it is hard work.
20:59:14 <zzz> basically the current testing has dropped to zero. The only way to get more testing is to get them in trunk, and a release.
20:59:17 <susbarbatus> Apologies for hooking into this; I have multiple macs, and no problem of being a mac or bsd guy. If someone can tell me what is required after the meeting or so, I can assess if it would be something that I could contribute if I’m knowledgable enough / learnable.
20:59:29 <zzz> great susbarbatus 
20:59:44 <str4d> susbarbatus, that would be fantastic
20:59:47 <zzz> ok so let's ask hottuna to check them in
20:59:53 <eche|on> zzz: yeah, we never said release is 100% secure and complete^^
21:00:05 <zzz> hottuna, the branch is i2p.i2p.str4d.gmp6 (NOT i2p.i2p.zzz.gmp6)
21:00:17 <hottuna> ok
21:00:38 <zzz> hottuna, don't forget to mtn drop the ones that need to be removed. When done, the directory should exactly match what's in your v13 zip
21:00:50 <zzz> anything else on 3b) ?
21:00:55 <hottuna> do you want the old jcpuid/binaries for platforms we didnt build for to be removed?
21:01:09 <str4d> susbarbatus, what I would want to get set up is a buildserver, if you can commit to having a mac always running and being available for questions/assistance when something fails. In general it wouldn't require much participation on your part, because the buildserver would be controlled automatically :)
21:01:28 <zzz> I believe the propsal hottuna was that v13 was _exactly_ what was to be released, nothing more, nothing less.
21:01:38 <zzz> if you want we can review that again after the meeting
21:01:38 <str4d> Or if not always running, at least easily started in the buildserver configuration
21:01:51 <hottuna> zzz: splendid
21:01:54 <str4d> (the buildmaster will handle buildservers that aren't always online)
21:02:12 <zzz> let's table the buildserver talk and move on to 4)
21:02:22 <zzz> 4) HOPE planning http://zzz.i2p/topics/1968
21:02:23 <susbarbatus> str4d: that’s no problem. I can hook up my ~2012 mac mini for that. It’s slow but it won’t be doing anything else.
21:02:24 <str4d> ACK
21:02:33 <str4d> ^5 susbarbatus :)
21:02:52 <eche|on> hope - I got a ticket to spent
21:02:57 <zzz> I met with Lance this week. the proposal is still to have him supply a small conf. room all day, either the day before or after HOPE
21:03:04 <zzz> i.e. July 21st or 25th
21:03:22 <zzz> I impressed upon him that we need a date and commitment shortly, so we can buy plane tickets
21:03:46 <zzz> this would not be open to public. invite only, 5-6 people, just a hangout for roadmap meetings etc
21:03:51 <str4d> At this stage I can't commit to being there, even though there is a small chance I might actually be in the US by then
21:04:00 <zzz> plus we present to him what we're doing and vice versa
21:04:30 <zzz> right now I have me and sadie as definites, with comradenosebleed and lazygravy as maybes. Who else?
21:04:49 <zzz> and what's the hard date when you need to get travel arrangements set?
21:05:33 <zzz> if it's only me and sadie maybe we can call the whole thing off, but let's see
21:05:39 <zzz> anybody?
21:06:04 <zzz> hottuna coming?
21:06:07 <str4d> (all depends on when my thesis defence is convened, no idea when that will be yet)
21:06:09 <str4d> (and also on other visa-related things)
21:06:17 <str4d> If my thesis defence is before then, I would like to be there (even if just flying through)
21:06:17 <eche|on> I am interested, but not able to pay the fligth and hotel. esp. if we meet later in can
21:06:17 <str4d> So ask me again in a month or so
21:06:45 <zzz> ok, I'll keep the heat on lance to nail it down, and hope the people materialize
21:06:50 <zzz> last call on 4)
21:07:00 <hottuna> zzz: it's really awkward for me timing-wise. have I have to be in the EU on Jul16 for a wedding.
21:07:15 <hottuna> I don't think I dare to commit now,.
21:07:20 <zzz> great, go thru nyc on the way back :)
21:07:26 <hottuna> (or at all if it has to be done now)
21:07:33 <hottuna> hmmph..
21:07:44 <hottuna> not a terrible idea
21:07:47 <zzz> 5) Brief review of monthly meetings and project management after 3 months
21:07:59 <str4d> So put me down as a hopefully for the meetup, and unlikely for HOPE (since I can't commit to needing a ticket, but will use up a spare one if I happen to be there)
21:08:26 <zzz> ok, from my perspective this is not working at all, there's almost no action items being completed, so can things be fixed or should we stop monthly meetings?
21:08:40 <str4d> I think things can be fixed
21:08:42 <zzz> if nobody is doing anything, there's nothing to be managed. It's not quite that bad but it's close
21:09:11 <str4d> At the very least, I think the monthly meetings are useful
21:09:30 <zzz> the goal was also to transition proj. mgmt to sadie but she isn't even showing up for the meetings so that's not on track either
21:09:32 <hottuna> I would agree about that
21:09:44 <str4d> She thought it was an hour earlier
21:09:49 <str4d> She's at another meeting now
21:10:19 <str4d> (she turned up an hour early and no one was talking here)
21:10:41 <zzz> sure, everybody loves meetings when they don't have to run them. But I look like a fool asking every month whether something somebody promised 3 months ago has happened. I'm tired of it.
21:10:49 <str4d> I've discussed this with sadie, and we now have weekly meetings set up for keeping on track with items we are both working on
21:11:19 <str4d> zzz, then don't make the focus of the meeting "did you do this thing"
21:11:36 <zzz> perhaps this is too dire but with the lack of progress and kytv vanishing I think we're in deep trouble
21:11:40 <hottuna> zzz: when is the transition to sadie supposed to happen?
21:11:40 <str4d> I think the monthly meetings should be more for priority re-evaluations and reorganisations
21:11:58 <zzz> ok so how do we keep people on track for doing what they promised to do?
21:12:13 <str4d> while the "did you get this thing done" needs a) more personal accountability and b) more one-on-one input
21:12:30 <hottuna> zzz: it's not great by any means, but deep trouble is probably overstating it.
21:13:02 <str4d> zzz, in my case, I've set up weekly meetings with sadie to help keep me on track, and given her access to my I2P todo list so she can help prioritise
21:13:07 <susbarbatus> str4d: I think the point is more, that if everyone was keeping promises/commitment then zzz wouldn’t have to ask the “did you do this” question ;).
21:13:12 <str4d> (we've only had one meeting thus far, so I still need to see how this works)
21:13:17 <str4d> susbarbatus, yep
21:13:50 <str4d> We need to be flexible enough to handle the fact that people do this for fun/volunteering outside their regular work
21:14:13 <zzz> right. My system is currently that when you finish something, you report that on the zzz.i2p thread for the meeting, so we _dont_ have to take up meeting time for it
21:14:15 <str4d> But we also need to emphasise that if someone isn't getting stuff done, they aren't being helpful
21:14:28 <zzz> it's only when people don't finish and dont report that we have to waste time here
21:14:42 <str4d> and it's better to pass an item on to someone else than block indefinitely
21:14:54 <str4d> (says the guy who is currently blocking indefinitely on I2P Android :P )
21:15:19 <zzz> so str4d and sadie have set up a parallel, non-public project management system as an experiment. that's interesting, but of course it isn't clear how it relates to what I'm doing, or whether I should keep doing it
21:15:55 <str4d> zzz, it's one part of the broader picture
21:16:28 <str4d> As I said above, I think that trying to do the "why didn't you do this" in a monthly meeting isn't as useful as we thought it might be
21:16:35 <zzz> so the project management via my forum and shaming at monthly meetings, I'm prepared to declare a failure
21:16:50 <str4d> because if they haven't done anything for the first three weeks, it's not likely they will get it done the last week
21:17:21 <str4d> hence why I think more regular quick checkups for people who have pending items is better, which is what I'm trying out with sadie
21:17:34 <zzz> at this point I don't think I'm ever getting the draft back from comradenosebleed, or a CoC, or use cases on the web, or an android release, at least not by any particular date no matter how far out
21:18:10 <zzz> so I propose stopping the monthly review of action items. As usual, people will do or not what they want in open source, and it's very very difficult to talk anybody into doing anything around here.
21:18:36 <zzz> people will do what they want, and whatever carrot and sticks I have aren't effective
21:19:50 <str4d> I vote that we keep the monthly meetings though, and use them to keep adjusting our priorities based on what *does* get done and what has happened over the past month (e.g. what we just did re: .26 after kytv)
21:20:56 <susbarbatus> Well, how is that bounty system working out at the moment? E.g. it’s a nice summarized public list with paid incensive. People still looking at that?
21:20:59 <susbarbatus> What I want to mention; what about micropayments far tasks.
21:21:03 <str4d> meanwhile if someone agrees to do something, they also should agree to keep sadie informed about progress, or at least to give sadie a communication channel to chide them :P
21:21:21 <zzz> ok so I propose stepping down as project manager, to replaced by some system and person TBD. We'll have monthly meetings but without review of action items
21:21:54 <zzz> next meeting will be Tues. May 3
21:21:58 <zzz> anything else on 5)
21:22:10 <zzz> anything else for this meeting?
21:22:35 <str4d> Not from me
21:22:53 <zzz> thanks everybody, long meeting today
21:22:58 * zzz *bafs* the meeting closed