[Libreoffice] Workflow proposal

[Jan Holesovsky]

Hi Bjorn,

On 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:

> > So - as long as you don't force people to do this [ie. don't force
> > this as a rule, but instead let them decide if they are willing to
> > wait for the merge of the branch into the master (working mostly on
> > the branch before the release), or whether they prefer to cherry-pick
> > whatever direction], I am fine.
> 
> I cant force anybody whom I dont hand the paycheck (an even then that
> would have limits). ;)

Oh - of course you / we can :-)  If the TSC agrees that something is
worth forcing, then a git hook [even on the server] can be created that
disallows / forces this or that.

> It is more about having a general recommendation on how to work. You are
> always free to do it different, but you should not blame anyone if
> things go wrong then. If there is no clear recommendation, you will
> just end up with people missing some commits on either branch and doing
> emergency cherrypicks, not helping clarity either.

Great - so I am sure we agree here :-)

> The more people are
> working on the release branch directly, even for critical fixes, the
> more people will be tempted to do the same for noncritical stuff,
> creating additional review work.

As long as the noncritical stuff are still fixes, not feature work, I am
fine.  I haven't heard complaints that there was an unbearable amount of
stuff to review - but if there was, reviewers, please tell me.

> Also: 3.3.3 codefreezed today with another ~35 most likely rather
> important commits. Are those merged back to master (or manually
> checked)? Are we sure all of them are obsolete for both master and 3-4?
> With patches and commits flying all directions between the currently
> open branches master, 3-4, 3-4-0 and 3-3 things are not exactly lucid.

That's actually a very good question.  Before the libreoffice-3-4 branch
was frozen (one review per commit), we have been merging libreoffice-3-3
into libreoffice-3-4.  Not to miss anything, we can either merge
libreoffice-3-3 just to master, or again to libreoffice-3-4 first, and
then the result to master.

I'd go for the former (libreoffice-3-3 directly to master), and let
anyone who needs something from libreoffice-3-3 in libreoffice-3-4
cherry-pick it there (with the usual 1 review).  When I see the other
comments, it seems to me that others are inclined to something close to
this too :-)  To sum up my proposal:

- master
  - no review, anything can be committed / merged into it
    - as long as the author did her / his best to make sure it
      builds / does not break the tests)

- libreoffice-A-X
  - branch created with the first beta
  - only fixes go in, no features
    - exception for the late features: 2 additional reviews, from people
      with different affiliation than the original author
  - no review until the last beta, libreoffice-A-(X-1) can be merged
    into it when in the "no review" mode
    - such a merge depends on TSC recommendation
  - 1 review after the last beta, no merging into the branch any more
    - any source of the patch goes - be it a patch sent to the mailing
      list, pasted via pastebin, a cherry-pick from master, or
      cherry-pick from any other branch
    - the reviewer pushes to the branch [unless the reviewer and author
      agree on something else ;-)] with the appropriate Signed-off-by:
      tag [use the "-s" option of git commit or git cherry-pick ;-)]
  - regularly [Q: once a week? or when a tag appears?], all
    libreoffice-A-* merged into master
    - of course a no-op when there are no changes in a particular
      release branch

- libreoffice-A-X-Y
  - branch created with the "semifinal" RC (see the release plan)
  - 2 additional reviews [Q: wouldn't actually just 1 additional be
    enough?]
  - only cherry-picking from libreoffice-3-X, the 2nd reviewer pushes
  - no merges back to anything

I believe this fits most of the needs - people can work either on
master, and let others cherry-pick, or work on the release branch, being
sure that the fix will appear in master in up to one week / when a tag
appears, so that the timeframe for duplication is minimal.

How does that sound?

Regards,
Kendy