Work Flow Inquiry

classic Classic list List threaded Threaded
13 messages Options
John LeMoyne Castle John LeMoyne Castle
Reply | Threaded
Open this post in threaded view
|

Work Flow Inquiry

Hi all,
I did some work on LibreOffice in late 2010.  Returning now I see that the timed release schedule has created several branches that correspond to the various release configurations.  All well and good.  The issue I am experiencing is related to the various issues with standard functionality in the Basic IDE:

https://bugs.freedesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Basic%20IDE
[Search for bugs with component BASIC ann Summary contains Ctrl OR IDE]

The fixes in this area seem to be done and applied only in 3.4 rc2.  From looking in other areas of work on rc2, I think I am seeing the same patching pattern where the rc is ahead of master.  And AFAIK they are all about to roll back to master.  This leaves me with a bit of a quandary: Do I switch to 3.4 rc branch because that's where the action is?  Or do I patch my version of master so I can work there?  Or do I make a request through the list for patching back to origin/master?  Or should I just wait for the merge?  I know that I often make things more difficult than they really are, but I am at a loss as to which is best/recommended way to proceed here and now.  

*** It seems that just about any patch applied to the current release candidate branch should also be applied to master, except where the patch is a workaround in an area that is under active and related development in master. ***

A drawback is more work for those who push the patches.  I am quite willing to resubmit existing rc patches in my area(s) of interest but this is ad hoc and prone to omission and still extra work for those who push patches.  
A benefit is something I read on the list a while back that said "the rc merge back to master essentially becomes a no-op"(less work at merge). Another real benefit is that people who are uncertain enough not to patch the rc can follow along in master, learn and maybe contribute effectively sooner.

As someone who is still new to open-source development, AFAIK the usual work flow is to work in dev master unless specifically trying to fix critical+high importance in the release candidate.  The current divergence leaves the master behind the rc branch in various ways/areas which feels odd to me and appears to create extra work for 'somebody', i.e. everyone.  

Please advise
LeMoyne
Caolán McNamara Caolán McNamara
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

On Sun, 2011-05-29 at 11:09 -0700, John LeMoyne Castle wrote:

> The fixes in this area seem to be done and applied only in 3.4 rc2.  From
> looking in other areas of work on rc2, I think I am seeing the same patching
> pattern where the rc is ahead of master.  And AFAIK they are all about to
> roll back to master.  This leaves me with a bit of a quandary: Do I switch
> to 3.4 rc branch because that's where the action is?  Or do I patch my
> version of master so I can work there?  Or do I make a request through the
> list for patching back to origin/master?  Or should I just wait for the
> merge?  I know that I often make things more difficult than they really are,
> but I am at a loss as to which is best/recommended way to proceed here and
> now.

...

> The current divergence leaves the master behind the rc branch in
> various ways/areas which feels odd to me and appears to create extra
> work for 'somebody', i.e. everyone.

Yes, fixing just the stable branch and leaving it up to petr to merge
the changes into master at some undetermined future stage creates this
problem where there are windows of time where master doesn't have fixes
in it that stable has, and its unknown when exactly they get into it.
Another argument for fixing in master and cherry-picking back to stable.

Personally, I think I'd still recommend working on master if possible
and make changes against that rather than compound the complications.

C.

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

On Mon, 30 May 2011 09:55:37 +0100
Caolán McNamara <[hidden email]> wrote:

> Personally, I think I'd still recommend working on master if possible
> and make changes against that rather than compound the complications.

/me too. But I think I made that point sufficiently clear already in
the ESC call.

Best,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks Michael Meeks
Reply | Threaded
Open this post in threaded view
|

merging 3-4 to master ...

In reply to this post by John LeMoyne Castle
Hi John,

On Sun, 2011-05-29 at 11:09 -0700, John LeMoyne Castle wrote:
> The fixes in this area seem to be done and applied only in 3.4 rc2.  From
> looking in other areas of work on rc2, I think I am seeing the same patching
> pattern where the rc is ahead of master.

        Yes - this is a distressing, festering wart in our lives as of today.

        *But*

        it is not really related to the process; but is particularly festering
because the back merge (which should happen regularly) has been delayed
by ~a month - and we are still waiting for Kendy to do that.

        This is, apparently related to problems merging m106. So - Kendy -
dudie ? can you comment / and/or inject some hope ? ;-)

        As more people start working on master instead of 3.4 this becomes
increasingly urgent. Also - the longer we wait, the worse it gets as
master diverges (I suspect). Is there any way we can parallelise that
work ? what is the status ? how can people jump in to help out ? etc.

        Thanks,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Re: merging 3-4 to master ...

Hi Michael, John,

On 2011-05-30 at 11:35 +0100, Michael Meeks wrote:

> > The fixes in this area seem to be done and applied only in 3.4 rc2.  From
> > looking in other areas of work on rc2, I think I am seeing the same patching
> > pattern where the rc is ahead of master.
>
> Yes - this is a distressing, festering wart in our lives as of today.
>
> *But*
>
> it is not really related to the process; but is particularly festering
> because the back merge (which should happen regularly) has been delayed
> by ~a month - and we are still waiting for Kendy to do that.

Yeah - terribly sorry for that :-(  Clearly, the 3.4.0 took much more of
my time than I wanted, and I was doing the m106 merge only when 'time
permitted'.  The real problem was that 1/2 of the work was done against
libreoffice-3-4 branch just before the beta when we thought it might be
+- easy, and we'd be able to get it into 3.4.0.  To save work, and to
prevent even more pain, the best was to merge the m106 first, and then
merge the rest of the libreoffice-3-4.

> This is, apparently related to problems merging m106. So - Kendy -
> dudie ? can you comment / and/or inject some hope ? ;-)

Indeed - so m106 is done and merged to master (see my other mail, with
subject "dev300-m106 pushed to master").  As you can see there, merging
the current libreoffice-3-4 to the master is my next priority.

> As more people start working on master instead of 3.4 this becomes
> increasingly urgent. Also - the longer we wait, the worse it gets as
> master diverges (I suspect). Is there any way we can parallelise that
> work ? what is the status ? how can people jump in to help out ? etc.

As explained above, the root of the trouble here is the merge of m106.
When finished (ie. now), the best is to merge any libreoffice-3-4 tag as
soon as it is produced.  This can be done nicely in parallel by whomever
volunteers [oh, and I'll be more than happy to pass it over to anyone
out there :-)]; and when we do it based on the libreoffice-3-4 tags, it
also means it would be done on weekly basis - ie. just a small amount of
conflicts, and reasonable flow of the libreoffice-3-4 improvements back
to master.

[Of course - for the ongoing 3.5, please mentally substitute
libreoffice-3-4 with libreoffice-3-5 :-)]

Regards,
Kendy

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

In reply to this post by Bjoern Michaelsen
Hi Bjoern,

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

> > Personally, I think I'd still recommend working on master if possible
> > and make changes against that rather than compound the complications.
>
> /me too. But I think I made that point sufficiently clear already in
> the ESC call.

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.  It only pollutes the history a bit after the
merge, but that's it.

I understood your request that working on master first, and
cherry-picking later would became a rule - which I am opposed to.  I
don't care if my changes appear in master just immediately; waiting is
fine for me, and better than having to build both master and the
branch(es) to see that I broke neither master, nor libreoffice-3-4.

Either way - I hope that now, after the m106 merge, this is not that
much an issue any more.  I have just merged the RC2 tag of
libreoffice-3-4 into master, and I am getting it to compile locally.
The subsequent merges are going to be much easier, and anybody missing
something in master can do them.

Regards,
Kendy

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

Hi Kendy,

On Mon, 30 May 2011 18:07:34 +0200
Jan Holesovsky <[hidden email]> 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). ;)

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. 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.

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.

Best,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Michael Meeks Michael Meeks
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry


On Mon, 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:
> Also: 3.3.3 codefreezed today with another ~35 most likely rather
> important commits. Are those merged back to master (or manually

        I would hope these are all cherry-picked back from a more recent branch
(personally).

        I do agree, that we need a well defined point to say: "enough
back-merging" - perhaps this is 3.x.2 or something ;-)

        ATB,

                Michael.

--
 [hidden email]  <><, Pseudo Engineer, itinerant idiot


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

On Mon, May 30, 2011 at 1:07 PM, Michael Meeks <[hidden email]> wrote:

>
> On Mon, 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:
>> Also: 3.3.3 codefreezed today with another ~35 most likely rather
>> important commits. Are those merged back to master (or manually
>
>        I would hope these are all cherry-picked back from a more recent branch
> (personally).
>
>        I do agree, that we need a well defined point to say: "enough
> back-merging" - perhaps this is 3.x.2 or something ;-)

considering the nice blog explaining the release model
http://blog.documentfoundation.org/2011/05/13/announcing-a-new-beta-release/

it would make some sens to merge 3.X.(0)
and since 3.X is a 'stabilisation version' then do a final merge at
the time from 3.X.1, the first 'production' version.
That would accommodate the main concern: time crunch in the 3.X
stabilization period.

after that, cherry pick, and never ever merge one way or the other.
(iow the 3.X branch diverge from that point on)

wrt 'log readability'. what is really confusing is a mix of cherry
pick _and_ merge.
if you purely cherry pick, commit show up only once in the log of the
branch you are working on
if you are merging they also show up once (but the graph is a bit more complex)
it is when there is a mix of cherry pick and then a merge on top of it
that the history get's confusing, with some of the same things done on
both leg of the graph...

So, I think what is actually more important is to choose one method or
the other for any given 'period', and avoid as much as possible to mix
the two ways of porting changes...

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Work Flow Inquiry

Hi,

On Mon, 30 May 2011 13:42:19 -0500
Norbert Thiebaud <[hidden email]>
wrote:

> after that, cherry pick, and never ever merge one way or the other.
> (iow the 3.X branch diverge from that point on)

What could still be done though is to do throw-away-merges: Merge them
without pushing, just to see that nothing is missing on master. If
something is missing, cherrypick it. Patch frequency is lower after
X.X.0 anyway.

> wrt 'log readability'. what is really confusing is a mix of cherry
> pick _and_ merge.

While you can limit that, you would never get rid of it completely.
Somebody doing a change on master and recognizing it to be critical
will not change branches and do the change on the release branch and
then merge it back to master, esp. given the intentionally open nature
of master and that even before a X.X.0 release there are reviews needed
at some point. You can get the release branch 'clean', but not the
master branch.
 
Best,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Workflow proposal

In reply to this post by Bjoern Michaelsen
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

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Bjoern Michaelsen Bjoern Michaelsen
Reply | Threaded
Open this post in threaded view
|

Re: Workflow proposal

Hi Kendy,

On Tue, 31 May 2011 10:43:22 +0200
Jan Holesovsky <[hidden email]> wrote:

> 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?

looks good, deserves a wiki page! Regardless of:
 http://nabble.documentfoundation.org/merge-issues-td3005672.html
having a rough documentation of how we do stuff is a great thing.

Best,

Bjoern

--
https://launchpad.net/~bjoern-michaelsen


_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Jan Holesovsky Jan Holesovsky
Reply | Threaded
Open this post in threaded view
|

Re: Workflow proposal

Hi Bjoern,

On 2011-05-31 at 14:37 +0200, Bjoern Michaelsen wrote:

> > 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?
>
> looks good, deserves a wiki page!

Now there :-)  Please feel free to edit.

http://wiki.documentfoundation.org/Development/Branches

>  Regardless of:
>  http://nabble.documentfoundation.org/merge-issues-td3005672.html
> having a rough documentation of how we do stuff is a great thing.

Answered that one in the thread.

Thank you,
Kendy

_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice