[apparmor] [administrivia] git conversion complete; gitlab projects set up

[Tyler Hicks]

On 11/01/2017 05:18 PM, Steve Beattie wrote:
> On Wed, Nov 01, 2017 at 03:46:17PM -0500, Tyler Hicks wrote:
>>> Am Mittwoch, 1. November 2017, 08:27:12 CET schrieb Steve Beattie:
>>>> There more work to do to flesh out the above and standardize on some
>>>> practices around git, but this should let us make progress.
>>>
>>> One thing we use for the openSUSE infrastructure salt code is the 
>>> "Protected Branches" feature:
>>>     https://docs.gitlab.com/ce/user/project/protected_branches.html
>>>
>>> Protected branches prevent force pushing and deleting a branch, which 
>>> IMHO makes sense for master and the apparmor-* maintenance branches.
>>> (Ideally we'll never notice that we have that sort of protection, but it 
>>> helps to prevent accidents.)
>>
>> This sounds like a very good thing to enable.
> 
> Agreed, I'll set this up for the apparmor and apparmor-profiles repos.
> 
>>> That's something time will tell, and it probably also depends on the 
>>> size of the patch. (I'll assume everybody has notifications for new merge 
>>> requests enabled in the gitlab config, right? ;-)
>>
>> I recently contributed a fairly complex patch set to a GitHub project
>> and will assume that it is a similar experience in GitLab in order to
>> give my opinion here.
>>
>> I really enjoyed the web-based merge request workflow and think it can
>> be an improvement over the mailing list patchset based flow. However,
>> I'd strongly recommend that we require contributors to:
>>
>> 1) Create a merge request
>> 2) Receive feedback from maintainers
>> 3) If changes are required, fold changes necessary to address feedback
>> into the existing patches, rebase, and force push to their merge request
>> branch.
>>
>> #3 is necessary to avoid a bunch of fixup patches that shouldn't be
>> standalone. It also makes for an bisect-able tree since there's no
>> broken commits being merged (with separate fixup commits).
>>
>>> I also wonder how to handle the Acked-by messages in case we use merge 
>>> requests - while it's possible with git rebase + using the "reword" 
>>> keyword, it means we'll have to force-push to those branches before 
>>> merging them.
>>
>> What the maintainer did for the GitHub contribution that I mentioned
>> above was to merge my pull request into a local branch, interactive
>> rebase to add his Signed-off-by, and then push the resulting branch to
>> to the master branch on GitHub.
> 
> Do you have a pointer to the merge request/commit so that we can see
> what that ended up looking like in git?

PR: https://github.com/seccomp/libseccomp/pull/92
My branch for the PR:
https://github.com/tyhicks/libseccomp/commits/improved-logging
Upstream commit log after merging:
https://github.com/seccomp/libseccomp/commits/0cc7203760c4776c67602a531bd633aba63a7851

Tyler

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20171101/4beef554/attachment-0001.sig>