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

[Yong Bakos]

On Jun 13, 2016, at 2:27 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> 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.

While I'm not a git expert, I am experienced[1], and I do humbly assert
that this will not pose a big deal for maintainers.


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

Reviewed-by: Yong Bakos <ybakos at humanoriented.com>

Thank you,
yong

[1] About ten years of doing things wrong, and sometimes doing things
     right, on mid-size projects.

> 
> Thanks,
> pq

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160613/0c1a7cee/attachment.sig>