Re: [Tails-dev] When to release a major release?

Delete this message

Reply to this message
Autor: intrigeri
Data:  
Dla: The Tails public development discussion list
Temat: Re: [Tails-dev] When to release a major release?
Hi,

anonym wrote (23 Apr 2012 14:41:41 GMT) :
> 04/20/2012 03:07 PM, intrigeri:


>> 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.


To make myself as clear as possible: I'm not asking for a *long*-term
planning of Tails 0.12. I can live with not deciding now exactly when
we shall release it. You proposed to release it "quickly", and to work
on new features at some unspecified time that makes this quick release
possible. Given other parameters, I can't see how we can do this, so
I did ask for some planning. Planning something that's supposed to
happen *quickly* is *short*-term planning, not long-term.

All in all, I don't think my asking for clarification on this proposal
was related, in any way, to time based vs. opportunistic release
schedule strategies.


Anyway, I find it interesting to discuss these strategies, and it's
been started, so let's go: I'm a fan of time-based release cycles, and
I have de facto pushed Tails towards this kind of strategy. I think
I can live with us doing otherwise, though. Let's discuss it.

You provided a few valid cons of time-based cycles. ACK.
Here are some pros from the top of my head:

  * Time-based cycles avoid constant project management and
    synchronization overhead as in "how far are you from getting
    feature A ready? shall I hurry to get feature B ready roughly at
    the same time? and how about feature B that is worked on by
    developer Y?". Given how bad we are at getting project management
    tasks shared and done in a collective manner, I'd rather see us
    rely on fixed schedules than on whatever invisible, seemingly
    spontaneous and magical, synchronization processes that happen
    behind the scenes.


  * The Firefox release cycle (6-weeks in between every ESR or rapid
    release) alone would be worth synchronizing on.
    This discussion takes me by surprise, and I was starting to ponder
    proposing we ship a new Tails major release every two Firefox
    releases (that is, every 3 months), and put a point-release out in
    between to acknowledge the new Firefox ESR. Granted, the upcoming
    incremental upgrades feature, combined with automated tests, will
    make this less important a need, and allow us to ship same-day
    upgrades of iceweasel regardless of our major releases schedule.
    We're not there yet, though.


  * Everyone knows in advance the deadline they have to get the
    $FEATURE they're working on ready enough to be part of the next
    Tails major release.
    As opposed to the opportunistic freeze's "aaaah, deadline was just
    set to $NOW + 2 or 3weeks, I have to either quickly find time to
    finish $FEATURE, or to propose delaying the release (which
    requires time prediction, by the way) although other features are
    ready, or to give up shipping $FEATURE this time".


  * Everyone knows in advance when to schedule time for the release
    process (that took us one month this time), from alpha testing
    to post-release user support, press work etc.


  * Documentation writers know in advance when they have to schedule
    time to document new features. Translators know in advance when
    they have to schedule time to translate new programs new
    documentation. I think this has worked very well for the 0.11
    release cycle, thanks to the time-based release schedule, but we
    should explicitly ask documentation writers and translators how
    they felt about it.


  * The last few above points mostly boil down to: most current Tails
    contributors have limited time to work on Tails. I think being
    able to schedule time for Tails in advance, based on some schedule
    one can relies upon, helps being part of the process even with
    limited overall time.


More importantly, time-based cycles keep us in sync', in a common
movement, and often focused on similar work, at a given $TIME, and
this feeling of working together is what I like the most in it :)

> 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.


Just curious, do you feel we have already felt into such a trap?
If so, during which release cycle?

> Time prediction is difficult, so why not try to minimize how much we
> have to rely on it?


I don't think time-based cycles have that much to do with time
prediction. What's ready in time goes in, what's not ready takes the
next train, a bit sad, but without fearing it might be too long in
the future.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc