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

[Pekka Paalanen]

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.

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.


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/20160610/cbce6b3c/attachment.sig>