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!
