Document GitLab as the only way to contribute to Samba?

Martin Schwenke martin at
Wed Sep 11 04:24:09 UTC 2019

On Tue, 10 Sep 2019 20:17:28 -0700, Jeremy Allison <jra at>

> On Wed, Sep 11, 2019 at 11:34:18AM +1000, Martin Schwenke via samba-technical wrote:
> > On Fri, 06 Sep 2019 16:54:17 +1200, Andrew Bartlett via samba-technical  
> > > I would document it as (roughly):
> > > 
> > > - GitLab is the strongly perferred method to contribute to Samba. 
> > > - Patches mailed to the mailing list may still be considered, but
> > > require additional work on the part of Samba Team members so are
> > > discouraged. 
> > > 
> > > If you are interested in reviewing patches submitted to Samba, please
> > > ensure you have a account and are watching our public gitlab
> > > repository.   
> > 
> > Sorry, but NACK.
> > 
> > Samba is a Free Software project.  While that is true we must not
> > mandate a proprietary platform as the only way of contributing.  Nor
> > should we discourage contributions that are not made via a proprietary
> > platform.
> > 
> > There are many reasons why a new contributor may be unable to use
> > GitLab, including:
> > 
> > * They may not agree with the terms of service
> > 
> > * They may not wish to take the time to setup an account and be added
> >   to the required project
> > 
> > * They may find the user interface unusable
> > 
> > * They may not have (reliable) web access
> > 
> > They may still be able to make very worthwhile contributions.
> > 
> > Ironically, Git - and, therefore, GitLab - exists because the founder of
> > the Samba project did not think it reasonable for a proprietary product
> > to be mandated for development on another project.
> > 
> > More pragmatically, GitLab may go away, so we should keep our options
> > not only open but also active.
> > 
> > We should continue to encourage this mailing list as an option for
> > contributing to Samba.  If a reviewer prefers seeing a GitLab CI
> > pipeline pass before they look at code then, if a mailing list
> > contribution sounds interesting, they can save the patch, run "git am"
> > and push the resulting branch to GitLab GI in less than a minute or 2.
> > They can then reply to the contributor saying "looks interesting,
> > waiting for GitLab CI pipeline <url> to complete".  This mailing list
> > isn't so busy that hand-processing a few contributions will swamp any
> > reviewer's time.
> > 
> > Sorry, mate!  This is a hill I'm willing to die on...  
> So if you feel so strongly about this (and I'm sympathetic
> to the web UI being just "someone else's computer" issues :-),
> is it the wording of:
> "Patches mailed to the mailing list may still be considered, but
> require additional work on the part of Samba Team members so are
> discouraged."
> you really object to ?

Yes.  That wording says that if you post to the mailing list then you
might be wasting your time.

The subject line is the original attempt to make GitLab "the only way
to contribute to Samba" and I also object to that.

> The mailing list isn't going anywhere, as it's the primary technical
> discussion list.


> How about we re-word this such that we encourage contributors
> to use gitlab if they prefer or are used to this interface (as
> many new developers are), but still encourage patches on
> any medium - including the mailing list ?

Sounds like a plan.  Thanks for suggesting it!

> We're not so developer-rich that we can afford to turn away
> help given by any means :-).
> I think the "require(s) additional work on the part of Samba
> Team members so is discouraged." is a statement of fact on
> Andrew's behalf. It may not be the case for all Team developers
> of course.

Very true.  I like GitLab's automatic CI pipelines but I find that
everything else takes more time using GitLab.  I do not poll the web
interface for merge requests but depend on notifications that come into
the same mail folder as samba-technical.

> Can you suggest alternative wording that would work for you ?
> We do want people who are used to gitlab to feel comfortable
> using it to contribute, semi-proprietary though it is:
> But we obviously still want to encourage pure Free Software methods
> of collaboration.
> Would that work for you Martin ?

Definitely.  How about the following?

There are 2 main ways of contributing to Samba:

* GitLab

  GitLab is an integrated web site for collaborating on code.  This
  includes continuous integration testing, merge requests and tracking
  of versions of patch sets.  The GitLab workflow is preferred by some
  [many? is it time for a poll?] Samba team members.

  See Samba's GitLab process <url> for more details.

* samba-technical mailing list

  This mailing list requires minimal up-front investment from drive-by

  See the samba-technical process <url> for more details.

I really think we should not push mailing list contributors to GitLab.
I cringe when I see this done.  As I have said, we can reply saying
that we're running a pipeline and point them to it.  We can then even
open a merge and point them at that too.  If they like what they see
then they might look at the GitLab process and make their next
contribution that way.  The only problem is if they don't have a GitLab
account then we do need to follow up on the list because they won't see
notifications.  It would be awesome if GitLab allowed you to add email
addresses of additional people to notify of updates.


peace & happiness,

More information about the samba-technical mailing list