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?

-- 
Steve Beattie
<[email protected]>
http://NxNW.org/~steve/

Attachment: signature.asc
Description: PGP signature

-- 
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/apparmor

Reply via email to