New release schedule proposal

[Antonio Terceiro]

On Fri, Aug 09, 2013 at 11:54:54AM -0600, Daniel Tygel wrote:
> Hi Rodrigo and others,
> 
>     I liked very much the new release schedule, congratulations for the work!
> 
>     Below follow some comments and suggestions:
> 
> Em 09-08-2013 11:41, Rodrigo Souto escreveu:
> 
>     ---++ Proposal
> 
>     1. Fixed new features release time of 3 months. Changes in this time
>     should not be negotiable (after defined here) in order to maintain
>     stability.
> 
>     2. Inclusion of RC1 and RC2 versions in the official schedule.
> 
>     ---++ Definitions
> 
>        * RC1: First release candidate version
>           * No new feature will be accepted after this version
>           * Package released in the test repository
>           * Conclusion of release notes
>        * RC2: Second release candidate version
>           * May be released only if necessary
>           * Package released in the test repository
>           * Contain fixes for the features on RC1
> 
>     ---++ Schedule
> 
> 
> I propose that we talk about these 2 months and 2 weeks before the release
> start. Here are some proposals:
> 
> . Day 0 to 2 weeks: Proposal, by all developpers in the community, of
> ActionItems that will be included in the next release. These proposals must
> have all information, specially who will be responsible developper, and a well
> described definition of what will be done, adequately categorized in the
> features categories.
> . One moment between 2 and 3 weeks: Virtual meeting of the community, with
> those interested, with the objective to eventually merge proposals, or discuss
> their implementation. This meeting would be 1 to 2 hours long, and would have
> as outcome the final definition of the sets of Action Items that will be
> included in the next release, with the responsible developers and the eventual
> modifications discussed in this meeting.
> . From this "community meeting" to the release: no new action item can be
> included in the set, except if it's an simple fix for some bug.

I have two problems with this idea:

- it adds explicit coordination points that depends on participation of
  everyone interested, who might be very incompatible schedules. Try
  scheduling a meeting between 4 people that do not already work together.
  When "everyone interested" expands to more people, this will become
  even more intractable.

  If we insist in this, someone who misses the meeting won't be able to
  argue for inclusion of their code. Free software development cannot
  depend on people being available at specific times for meetings ...
  the coordination has to happen asynchronously using the appropriate
  means for that: code submissions and review. Of course you can have
  meetings for specific purposes with interested parties, but requiring
  everyone to attend a "community meeting" to have their code included
  is equivocated.

- it assumes counting on code that may not be written yet, what adds a
  level of uncertainty to the process.

  "OK, we decided that feature X will be developed by developer D and
  will be included in the next release. What if D₁ falls sick and
  doesn't finish in time? What if D₁ finds out that the implementation
  is a lot more difficult than expected? Well, now we already planned
  the release with this feature, and feature Y that is being developed
  by D₂ would only make sense if X is already in ... oh well".

Why don't we do the opposite: instead of deciding about code that
_would_ be written, we decide about what was already written: if it was
submitted and approved during the period where it's OK to add new
features, and it does not mess with unrelated features, it's in. It it
missed the date, it has to wait for the next release.

Everybody knows when they need to have their code ready for inclusion in
the next release and can plan accordingly. If they miss a release, they
know when is the next.

If there are dependencies between features, only the people involved
with that features need to coordinate, instead of having to involve
everyone.

We can even increase the length of period where only bug fixes are
accepted, having a 1½ month merge window and 1½ month of bug fixes only.
Whoever adds code who turns out to be broken has to fix it between RC1
and final release.


-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-dev/attachments/20130810/81d7fbf6/attachment.pgp>