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

[Bryce Harrington]

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

Thanks,
Bryce