[PATCH weston v2 0/2] Separate Weston from libweston

[Pekka Paalanen]

On Fri, 10 Jun 2016 09:29:31 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Fri, Jun 10, 2016 at 11:04:03AM +0300, Pekka Paalanen wrote:
> > On Thu, 9 Jun 2016 16:53:12 -0700
> > Bryce Harrington <bryce at osg.samsung.com> wrote:
> >   
> > > On Thu, Jun 09, 2016 at 03:20:35PM +0300, Pekka Paalanen wrote:  
> > > > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > > > 
> > > > After these two patches, we have weston-the-compositor sources in compositor/,
> > > > and libweston sources in libweston/.
> > > > 
> > > > Since these patches have been generated with git format-patch -M and so
> > > > probably cannot be applied from email, I made the branch available at:
> > > > https://git.collabora.com/cgit/user/pq/weston.git/log/?h=migrate2
> > > > 
> > > > v2: move screen-share.c and note weston-launch.    
> > > 
> > > This seems fine, although there's a number of pending patches for weston
> > > that this will obviously break.  Since the rename can be done
> > > mechanically for the most part, what would you think if we make an
> > > effort to get all the weston patches prior to, say, June 1st, reviewed
> > > and either landed or sent back with requests to update them to the new
> > > layout?  I seem to recall a number of the pending patches we felt might
> > > be landable post-release, so might be nice to clear the slate of those.  
> > 
> > Hi Bryce,
> > 
> > July 1st?
> > 
> > It is a nice idea to clean up the patch queue before landing the
> > moves, but I don't think it is realistic. New patches will undoubtedly
> > come in.  
> 
> That's why I suggested June 1st, so the list is finite.  That's mostly
> stuff that came in prior to the release, much of which we've looked at
> at least lightly once or twice.

Oh, ok, I misunderstood. So you're essentially proposing to make the
cut-off at June 1st received patches which is much earlier than what I
intended (the time of merging the move).

I still do not think we really need to categorically send patches back
to be rebased only because they were written before the move is merged.
We maintainers can easily enough (right?) deal with them in the manner
I described below.

Only the most hairy cases might need to be sent back for rebasing,
which would be business as usual.

> > Besides, it is not as bad as you might think.
> > 
> > When we review and land patches that have been written before the move,
> > but the move is already merged, we can do this:
> > - create a tmp branch just before the move
> > - apply the patches to the tmp branch
> > - git rebase origin/master
> > - fix up
> > - push to master
> > 
> > Doing it like this, git will do most of the heavy lifting
> > automatically: since files are moved without any changes, git will just
> > rewrite the change to target the new file name.
> > 
> > (That is the excercise I already have to do sometimes, when trying to
> > apply patches that no longer apply to master - rebase has a much higher
> > chance of automatically fixing conflicts, and I want to see patches in
> > my git tree when I review them already anyway.)
> > 
> > What we do have to do manually is fix up any new files added, since git
> > does not know they should be moved along other files. Also conflicts in
> > Makefile.am file lists are likely if they are changed.
> > 
> > I believe the mechanical costs are roughly the same which ever way
> > we do it. Landing the move ASAP will avoid the stress to review and/or
> > land the patch queue quickly, and new patches will be with the new
> > layout already. The time of landing is a flag day anyway, so I'd like
> > to get it done sooner than later. That way the number of patches with
> > the old layout does not increase anymore, and we can chew them all out
> > without any rush.
> > 
> > 
> > I tested the rebase by taking
> > https://git.collabora.com/cgit/user/pq/weston.git/log/?h=ivi-remote-surface-RFC-1
> > and rebasing it onto
> > https://git.collabora.com/cgit/user/pq/weston.git/log/?h=migrate2
> > 
> > I got two conflicts from the whole rebase. One was Makefile.am in the
> > first patch, and the other was header inclusion in the last patch. These
> > two would have conflicted anyway, no matter which way we did it, also
> > when rebasing the other way. Newly added files indeed are left to be
> > manually moved to the right directory, the plugin-registry files went
> > under src/ so need to be moved to libweston/. That we need to do
> > manually in any case.
> > 
> > I can personally take care of any patches that need the manual moving
> > of new files, but otherwise I would hope the extra effort is not
> > significant for you.  
> 
> Oh, okay if you're going to take care of the patches I'll withdraw my
> concern.  I was mainly just worried we were going to create a lot of
> unnecessary manual work for the contributors, but if you have a scheme
> worked out to handle it yourself then that problem goes away.

I can promise to handle the rebases for landing patches that add new
files into src/. I would hope you and everyone else can take care of
patches that don't add new files like you would usually do.

If you need more detailed instructions on how to make the tmp-branch
trick in few simple commands, I can of course provide that.

Now, Acked-by? Reviewed-by?

I'd really like several people giving their A-b or R-b before landing
this, since it is a major change, even if relatively simple.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160613/bdeb204d/attachment.sig>