04/20/2012 03:07 PM, intrigeri: > hi, > > intrigeri wrote (11 Apr 2012 09:31:08 GMT) : >> anonym wrote (11 Apr 2012 09:07:26 GMT) : >>>> Alternatively, if we focus on the infrastructure and surroundings >>>> at post-0.11 time, we can set a deadline to mid-June, probably most >>>> of the work will be done by then, and then 0.12 could happen end of >>>> July. Is 0.11 + 3months early enough? I think it is. > >>> Perhaps. A compromise would be to get the more or less trivial ones >>> (i.e. the tails-greeter controls for windows camouflage etc.) out >>> quickly in the first point-release, which I don't expect to suck up >>> much energy (they seem like good procrastination targets to me :)). > >> I can live with this compromise, but the result should not be called >> a point-release IMHO: instead, it would be a tiny 0.12, that would be >> out quickly with only a few new features. > > I'd like us to decide something on this topic ASAP. > > On second thought, I'm getting less and less convinced we can do all > this without letting it drain most energies we must put into > Wheezy -related stuff before June. > > I'd be happy to be reassured and join the optimistic gang, though, so > please help convincing me with a rough dev and release schedule for > this tiny 0.12, that would: > * leave enough time for docs writers and translators to do their job > before the 0.12 release, > * leave enough time to work on Wheezy -related stuff before June.
I have no good prediction on how much the "Wheezy-related stuff" will require of us, so I cannot make a convincing argument. However, I wonder if something has changed in our process that I'm unaware of. At least in my experience we've been quite opportunistic about our major releases previously, and not relied on detailed, long-term planning. When we've felt that "now we have some essentially finished features that warrants a major release", then we have chosen some not-so-distant (2-3 weeks) freeze and release dates and worked with that. Now we plan three months into the future. Is that necessary? Is that efficient? To me such deadlines seem to introduce a lot of inefficiency. To make a deadline realistic, we usually err on the side of overestimation of how much effort is required. Time prediction is difficult, so why not try to minimize how much we have to rely on it? What's the problem of a more relaxed opportunistic release strategy? E.g. say that it so happens that in mid-june Tor 0.2.3 and Vidalia 0.4 have been released, and we have the following features mostly done: * Tor 0.2.3.x integration (e.g. Isolate* configurations) * Vidalia 0.4 integration (e.g. bridge mode) * TailsGreeter: - Winxp camouflage control - Bridge mode control * Unsafe Browser Instead of the late-july deadline we opportunistically set a freeze and release date for a late june release. This way we'd probably save ourselves a point-release, and our users would get the new features a month earlier than planned. What did we lose/what were the drawbacks? Cheers!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
