Il giorno lun, 16/10/2006 alle 21.45 -0700, Andreas Raab ha scritto:
> Hi Giovanni -

Hi Andreas,

thanks for your detailed reply. My comments are after the various
sections of your message.

> I fully agree with the meta goals of your proposal, namely to enable 
> people to do their own development and to limit the amount of time spend 
> on each individual part of the release.
> 
> That said, I'm in almost complete disagreement with the rest of your 
> proposal ;-) The fundamental flaw in it is that you are trying to commit 
> other people's time. Starting from "the board appoints a release team" 
> (phase 0) over "the teams announce the development plans" (phase 1) and 
> "code will get dropped" (phase 2) up until "the VMMaker team will want 
> to..." (the example) you're happy committing other people's time. In my 
> experience this has *always* been a fatal error in a volunteer open 
> source project.

Well, that goes against what I had in mind. My point was allowing the
various team and developer to declare how much time they can commit in
the coming months, and then plan accordingly. I should have expressed
this explicitly. Also, most of the features would have already be
developed independently from this cycle, and only integration and minor
bug fixing should be required, unless there' a guarentee that missing
feature will be completed.

>From this point of view my example was too optimistic.

> The *only* time you can commit is your own. And given that, how much of 
> your proposal works if the only time that you can count on is your own? 
> Even if we want to change the release process we cannot change some 
> fundamentals about the environment we're in. And one of those 
> fundamentals is that (on a scale where it matters) you can't tell people 
> what to do. They're doing it voluntarily, they're doing it for their own 
> reasons and trying to change that simply won't work.  To give a more 
> concrete example, the maintenance work I do for FFI, Graphics, Balloon, 
> and Compression packages is purely a volunteer effort. If you ask me 
> about my "development plans" for the next six months, all I can say is 
> "uhm ... ". Most importantly, because I have a fulltime job in a startup 
> I for example couldn't possibly commit to a six months active 
> development plan. It's simply not doable and even if it were I'd reject 
> it on the grounds that unless you pay me for it I'm not going to treat 
> this serious enough to make six month plans ;-)

In your case, according to the process I'm proposing, you would just
declare that you can't commit any predetermined time for the next six
months.
Now, what if a couple of months after your declaration you have some
time to work on, say, Graphics, and you're able to produce new releases
of that package? If when this happens 3.10 is still in alpha, your new
releases could be included without many problems (excluding integration
problems, that is); if in beta or gamma, then your changes should be
moved to the next version. But this would not forbid you to work on it;
it would just postpone its integration.

> To emphasize that point even more I'll give you two recent examples: 
> First, we have been talking for *years* about changing the source 
> pointer in the methods. That it happens *now* is (from my point of view) 
> exclusively due to the fact that we got a new sources file in 3.9 and 
> lost the entire previous history for the single reason of the source 
> limitations. Could anyone really have planned for that? I don't think 
> so. Second, the SSL implementation we got recently. A while ago we 
> started looking at SSL ourselves and decided to go with OpenSSL - we 
> talked about Crypto team and their work but honestly, I would have 
> called anyone a nut who would have told me that this stuff will be ready 
> by now (I probably would have just laughed them out of the room). At 
> least for me, this project came out of the blue, completely unforeseen 
> and again nothing you could have possibly planned for.

And I would not have planned for it, too. On the other hand,
_integration_ of such efforts in the main image needs a little planning.

> Which brings me to the proposal I made earlier. The main goal of that 
> proposal is really to get away from the upfront feature planning process 
> and deal with the chaotic reality of open source development by 
> *embracing* it. So instead of feature list of things that we SHOULD do, 
> I'd like us to discuss things we HAVE done. Instead of wishful thinking 
> I'd like us to talk about all the cool stuff that is actually happening!
>
> I think that this may be the only way to make sure we can survive the 
> release process in a volunteer community like ours and it's surprisingly 
> similar to what we did at SqC - the main difference is that SqC (instead 
> of the community) picked which of the contributions got adopted and 
> which ones didn't. At SqC (or any other commercial entity that I have 
> been involved in) we have always been aware of error 33 and therefore 
> never relied on the open source effort to produce specific results in a 
> specific time frame. That's what companies do, that's why they take 
> money to do it. However, anything that happened was always welcome and 
> often a surprise. And I can say for sure that during those times nobody 
> got burned out by the process.  And I think that process can be recreated.

Ok, then would it be possible to integrate my proposal with yours?

	Giovanni