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

[Tyler Hicks]

On 11/01/2017 02:41 PM, Christian Boltz wrote:
> Hello,
> 
> thanks for doing the migration!
> 
> 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.

>  Protected branches can also be configured to completely deny pushing to 
> a branch, but that would be too much for us IMHO, and would especially 
> make backporting more paperwork (create a branch on top of apparmor-2.x, 
> commit your changes, then merge it).
> 
> According to the documentation, you should be able to choose a group for 
> "Allowed to merge" and "Allowed to push" for each branch.
> 
> 
> Another question is if we want to continue sending patches to the 
> mailinglist, or if we'll switch over to using branches (prefixed with the 
> username, for example "cboltz-utils-foo") and then send merge requests. 

What's the reason for the username prefix?

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

Tyler

> Oh, and there's still the question if we can get commit notification 
> mails - does someone have an idea?
> (For now, I subscribed to the RSS feed - but it contains only the commit 
> message, not the diff.)
> 
> 
> Regards,
> 
> Christian Boltz
> 
> 
> 


-------------- 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/09081e00/attachment.sig>