GitLab conventions

[Ryan Scott]

Thanks! The updated information is now on
https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests, for those
who are curious:

> While the release manager can perform the backport on your behalf, it is
appreciated if you open a merge request with the backported patches
yourself.

One further question: if a patch (that is intended to be backported) first
lands on master, is it considered good practice to leave the corresponding
issue open until the backport happens, similar to Trac's "merge" status? Or
is this practice obsolete in the new label-based workflow?

Ryan S.

On Tue, Apr 2, 2019 at 10:05 AM Ben Gamari <ben at smart-cactus.org> wrote:

> Ryan Scott <ryan.gl.scott at gmail.com> writes:
>
> > Thanks for writing these up! These will be handy references that I'm sure
> > I'll come back to many times.
> >
> > Question: once I've marked my MR as "backport-needed" (and it is merged
> > into master), whose responsibility is it to ensure that it gets merged
> into
> > the latest release branch (e.g., ghc-8.8)? It it the responsibility of
> the
> > person who made the MR originally, or is there a process in place for
> > collecting these backport-needed patches into batches and merging them?
> >
> It is of course appreciated if people backport their own patches.
> However, I do intend on doing a sweep of the backport list and take care
> of anything I find while preparing the stable branch.
>
> I'll see to it that this is better documented.
>
> Cheers,
>
> - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190402/25706aaa/attachment.html>