[PATCH] RFC: CONTRIBUTING: Embrace gitlab

[Sean Paul]

On Wed, Sep 12, 2018 at 1:34 PM Lucas De Marchi
<lucas.demarchi at intel.com> wrote:
>
> On 09/12/2018 09:46 AM, Daniel Vetter wrote:
> > So Rodrigo just broke the gitlab ci on libdrm, I figured perfect time
> > to start this discussion.
> >
> > There's imo 2 reasons to do this:
> >
> > - No more "oops, I broke make check". If we use gitlab merge requests
> >    gitlab CI will test everything, and we can set 2 checkboxes that
> >    disallow direct pushes (i.e. require merge requests), and that all
> >    merge requests must pass CI first.
> >
> > - maintainer-tools is a small project with a small team and little
> >    activity. Much easier to figure out the details here than in one of
> >    our big projects. And there's lots to figure out, which we need to
> >    be able to explain (and have documented) for our 50+ team, if we
> >    ever want to use gitlab: commandline tools, emacs modes, best
> >    practices for setup, ...
>
> talking about figuring out the details:
>
> - What is the merge strategy to be adopted? 1) A merge commit per
> merge-request 2) a linear branch with commits being rebased; 3)
> semi-linear approach (still a rebase, but with a forced merge commit).
>
> - What should we do regarding the a-b, r-b? Is gitlab going to add those
> automatically?
>
> I would not check the 2 boxes to disallow direct pushes until those are
> figured out.

Given the size of this repo and the number of contributors, I'm not
convinced either of these should be blockers. We should avoid merge
commits since the volume is low enough that having to rebase should
be quite rare. Reviews and acks will be recorded in the merge request,
which is easily accessed from the UI.

Sean

>
> Lucas De Marchi
>
> >
> > To avoid this being an entirely hypothetical discussion, I've gone
> > ahead and created a merge request for this:
> >
> > https://gitlab.freedesktop.org/drm/maintainer-tools/merge_requests/3
> >
> > For keeping up with activity: Go to the main repo, click the alarm
> > icon (which probably says "Global" now), and change the setting to
> > "Watch". That should keep you updated on all issues and merge
> > requests, like with a mailing list.
> >
> > v2: Add link to merge request.
> >
> > Cc: Jani Nikula <jani.nikula at intel.com>
> > Cc: Sean Paul <sean at poorly.run>
> > Cc: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > ---
> >   CONTRIBUTING.rst | 18 ++++++++++++++----
> >   1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
> > index c7846e318b7e..636d94e3c0af 100644
> > --- a/CONTRIBUTING.rst
> > +++ b/CONTRIBUTING.rst
> > @@ -1,11 +1,21 @@
> >   CONTRIBUTING
> >   ============
> >
> > -Submit patches, bug reports, and questions for any of the maintainer tools and
> > -documentation to the dim-tools at lists.freedesktop.org mailing list.
> > +Patches should be sent via `GitLab merge requests
> > +<https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html>`_.
> > +maintainer-tools are hosted on `freedesktop.org's GitLab
> > +<https://gitlab.freedesktop.org/drm/maintainer-tools>`_: in order to submit
> > +code, you should create an account on this GitLab instance, fork the core Weston
> > +repository, push your changes to a branch in your new repository, and then
> > +submit these patches for review through a merge request.
> >
> > -Please make sure your patches pass the build and self tests by running::
> > +Gitlab CI will automatically run all tests. You can test your patches locally by
> > +running::
> >
> >     $ make check
> >
> > -Push the patches once you have an ack from maintainers (Jani/Daniel).
> > +All merge requests need an ack from at least one of the committers before it can
> > +be pushed. Don't push to master directly.
> > +
> > +Bug reports, suggestions for improvements and questions for any of the
> > +maintainer tools and documentation should be filed as new issues.
> >