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
