[haiku-development] Re: Haiku R1A4 Postmortem
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 10 Dec 2012 10:32:51 +0100
Am 10.12.2012 um 10:11 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> On December 10, 2012 at 9:32 AM "Stephan Aßmus" <superstippi@xxxxxx> wrote:
>> To me, Ingo's Landon's and Axel's arguments sound directed at an ideal
>> situation. They seem
>> less targeted at the actual Haiku situation. The arguments incorporate
>> theoretical problems
>> that we didn't actually face during release preparation (like developers
>> trying to get
>> half-finished work into the release), and they neglect work power problems
>> that we do have.
>
> AFAICT we aren't even that far into the discussion yet. The problems of
> putting
> things into the release that do not belong is certainly a real problem. I know
> that I would have pushed some commits of mine into the release back when Ingo
> was RM. I also think that way too many commits were made into the alpha4
> branch.
We have the luxury that several people are confident with kernel stuff. In
other projects it's often reversed. Even with non kernel stuff, we mostly have
at least one more developer who could review changes in any given component.
[...]
> Anyway, from my POV I see the following problems:
> * We branch to early, when there are too many open issues left.
> * The branch was open way too long, causing too much work looking at commits.
> * This also steals time for other important things like trying to get people
> to
> test release candidates beforehand.
>
> I would suggest the following procedure:
> * The release branch should be short lived, and we should aim for as little
> commits to it as possible.
> * This means we'll need a stabilizing time for trunk in which time people
> concentrate on fixing issues, and do not commit questionable stuff. By which I
> do not only mean things with questionable quality, but also debatable things
> like a yellow Terminal cursor.
> * Since it's not a good idea to delay things in trunk, I would only reserve a
> week for this phase. Therefore it's important to choose a good starting point.
> * There shouldn't be more than like 5 tickets open for the release when the
> branch is opened. The tickets should be discussed before the release branch is
> created.
> * The RM does not look at unreviewed commits (ie. commits that another person
> than the developer said okay to). Once reviewed, the RM tells the developers
> of
> the commits he wants in the release to commit them to the branch. Things like
> Gerrit may help with this process; maybe the mailing list is sufficient,
> though.
> * If people don't help with the release, the release will be delayed, but no
> additional features will be added; there is no additional burden in
> maintaining
> the branch.
> * The RM therefore mostly does testing, and keeps the overall things in sight.
>
> Consequences:
> * The RM does not have to be a developer.
> * If people don't help out, the release will be late.
>
> I'd be willing to volunteer as RM for our next release to try that out for
> real
> if we can agree on those or similar terms.
Sounds fine to me. I see maybe one flaw: If there is a policy that component
owners must review commits, then we have people feeling responsible for doing
the reviews. You address this point by saying "if people don't help out". I
would like to try a bit harder to avoid people not helping out, by assigning a
default responsibility for who should review what. People with default
responsibility can also delegate, but that is better than no one feeling
responsible in the first place, other than some generic responsibility to "help
out".
Best regards,
-Stephan
Other related posts:
