[haiku-development] Re: Release Naming and Plan
- From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
- To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
- Date: Tue, 1 Jul 2014 18:22:19 +0200
Hi,
On Tue, Jul 1, 2014 at 5:33 PM, Augustin Cavalier <waddlesplash@xxxxxxxxx>
wrote:
> Tenative schedule:
>
- 7/1-7/31: Casual testing (focus on the package manager and related
> technologies), development focus on the user experience (HaikuDepot, etc.)
> -- pretty much normal development, but don't commit anything too risky
> (e.g. tracker_layout, EFI, etc.)
> - 8/1-8/10: All development efforts towards features stop except for
> critical ones (if there are any left), heavy testing phase begins
> - 8/11: Branch release, string freeze
> - 8/11-8/13: Changes on the release branch (package repositories,
> "KDEBUG_LEVEL=0", build tweaks for release, etc.), get website pages ready
> to go
> - 8/14: Build images, upload, get annoucement ready
> - 8/15: Release!
>
> This basically corresponds to my schedule (all July full-time, August
> part-time except for the week of the 11th).
Without trying to discourage anyone, these proposals tend to fail. I know,
mine did. I found that there are people who prefer releasing over
polishing, and there are those that consider the current status of the
trunk to not being ready, be it hardware support/driver bugs or the
polishing of the package manager.
I would suggest trying a different approach that bridges both worlds: let's
set up a team that over the course of one and a half to two and a half
months will act as the release engineering team. This team will start to
shape up the current tree to fix or workaround what we currently call
regressions. The team should have weekly IRC meetings to give a status
update on the work that has been done, and to identify new issues. The team
should consist of members in several disciplines: driver/hardware engineer,
package system engineer, as well as at least one dev for the rest of Haiku
(which does not seem to be a priority for the next release). Furthermore
there should be a buildmeister (for the packages and the test builds), a
community test manager, a documentation and web person, and a release
manager. For each of the positions at least one person will have to be
available
The approach has the advantage that it gives proponents of releasing a
clear structure of focussing on getting it done, while giving the opponents
some sense of relief that their worries are being handled. It is also a
test to see whether our development community that is traditionally very
bad on focussing, can find a way to get into the groove.
Just putting out a schedule, even if agreed upon, is not enough to motivate
people to focus and to get things done.
N>
Other related posts:
