Re: [Libreoffice] Thoughts on releasing ...

Hi Michael, all,

Michael Meeks wrote (13-12-10 15:05)

> > On 05/12/2010 20:39, Andrea Pescetti wrote:
> > > So a major change with respect to the OpenOffice.org release process
> > > would be that no explicit approval is needed for localized versions.
>
>         Right. I do not believe we can afford to hand out 60 vetos to
> releasing; (or 110 if we go for all langs). Also, I don't think it is
> that acceptable either to have an:
>
>         "only some<N>  'important' languagess get a veto"
>
>         process. And in general, I think rights to say 'no' are most often a
> serious hinderance rather than a help in processes - I would not want to
> be handing them out left&  right myself.


The process as we know it from OOo does not have 60+ vetoes to releasing.
The decision for the release is done by the release team. But once it is 
a 'go', each individual language group has to say: release our language.
Which makes sense because it gives, and respects, responsibility.


>         Instead - I would suggest we use a vigorously time-based release. What
> does that mean ? it means we -know- we will release on a given date. We
> have a fixed schedule, and absent any crash-on-start type issue, we
> release on that date [1]. This gives fair notice to all Developers:
> hackers, translators, QA guys, documentors etc. It also means we have to
> get serious about code freezes, and translation work in good time;
> and/or resign ourselves to a lower quality release.
>
>         *But* - and I can hear you shouting this; what if we have some serious
> problem !? what if my localisation is broken / missing ?
>
>         I think here we need to get to the root of the point-zero release:
> these releases are the first cut of new things - as such they are
> exciting and new, but perhaps contain bugs. If you are highly
> conservative - waiting for X.Y.0.1 is a good idea :-)
>
>         I suggest that we then have a .1 release quite quickly after our
> initial release (to let people catch up), and that we include only
> no-brainer code fixes (for crashes etc.) and translation updates.
> Perhaps we do the .0.1 release after only two weeks or so; and another
> after a month. At which point, hopefully we are in a very good state
> stability / feature wise, and people are looking forward to the next
> release coming soon.
>
>         How does that sound ? I really want to be releasing more frequently,
> rather than less, I think we have the infrastructure to do that - though
> clearly there is no requirement for users to upgrade between minor point
> releases, and we don't need to make a huge noise about them. Big
> Business and Government users (who supposedly hate updating) can simply
> move from the end of the last stable release (ie. the .0.5) to the last
> of the next stable release - or even miss several out if they want
> something really old[2] :-) Incidentally, this model is essentially
> similar to the Linux 'stable' model whereby people can maintain any
> released branch for as long as they want and keep updating it with
> security /translation fixes etc. if they so wish.
>
>         How does that sound to people ?

That sounds good.
Which still not answers the detail: shall each language group confirm 
the release status of the point-zero or 0.1 releases?
I tend to prefer if that is done. But it also raises criteria for the 
download-pages, so that the distinction between 'approved' or not is clear.

I've also seen mails from Petr, Jean-Baptiste and others on the expected 
time needed for QA. Which is a related subject. And there also the 
vision was shared, that many bugs are found while people work, not only 
when people test.
This supports an approach where working with developer-builds is made 
easy and promoted. And of course easy communication about the issues 
found etc etc.

Best,
Cor


> [1] - it is notable that our first release is not like this; no clear
> schedule ahead of time&  so on - apologies; the next can be better.
> [2] - I hate it when these discussions of big business' apparent
> requirements turn into a requirement that everyone else do nothing for
> months, have horribly painful process, and/or not release quickly when
> the solution is quite simple.


--
 - giving openoffice.org its foundation :: The Document Foundation -