[haiku-development] Re: R1/A3: a thought about the release cycle.
- From: "Adrien Destugues" <adestugu@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 02 Nov 2010 22:17:47 +0100
> On 2010-11-02 at 19:10:20 [+0100], Adrien Destugues <adestugu@xxxxxxxxx>
> > wrote:
> > > Following up on the R1/A3 talks [1],
> > > one of the major hurdles seems to be the lack of a release branch
> > > manager.
> > >
> > > Would it be possible to enforce a very strict merging-to-branch
> > > policy?
>
> In theory yes, in practice this might turn out to be more
> complicated. E.g.
> there are at least a few components (ShowImage, ext2, the Gutenprint
> stuff,
> Locale Kit/ReadOnlyBootPrompt) for which I couldn't say what state
> they are
> in ATM. If any of those still requires significant work to get them
> into an
> acceptable state for the release, we would already have exceptions to
> the
> policy.
ReadOnlyBootPrompt has trouble with line breaking chinese text, but
works fine otherwise. This can only be solved properly by using ICU
layouting engine for linebreaking the text. I hope I'll have some time
to do it, but I can't be sure.
>
> > > This should greatly reduce the workload of the branch manager. As
> > > the
> > > branch
> > > should be seeing less commits, it should make it easier to perform
> > > QA
> > > and spot any regressions.
>
> Yep, generally that's a reasonable approach.
>
> > I believe the 'alpha' selection should not be made on commits, but
> > on
> > tickets in trac. If a commit fixes a ticket attached to the alpha
> > milestone, it goes in the branch. If not, it stays out.
>
> Sounds rather impractical. If someone would fix a small issue for
> which no
> ticket exists, he'd either have to sneak one in or the fix wouldn't
> make it
> to the release branch.
Right. I think it depends on how we handle the branch. Do we need a
coordinator and super-strict rules, or would guidelines and letting
everyone commit things to the branch work ? I think no one would want
to mess with the branch anyway, but individual changeset tracking more
or less prevented a lot of people working on the branch. While doing it
at ticket assignation stage allows everyone to work on it. The rule
would be something like :
* If a ticket exists and is assigned to R1a3, go ahead and commit in
the branch (or do we want an extra quality review here ?)
* If a ticket exists and is assigned to R1, dont commit in the branch
* If no ticket exists, dont commit in the branch yet, state it in the
commit message and the case will be handled on haiku-commits mailing
list.
This way it does filter out most stuff, but we still need to take
decisions for these ticket-less commits. They can be done on vote, or a
branch manager can do it.
--
Adrien.
Other related posts:
