Document GitLab as the only way to contribute to Samba?

Karolin Seeger kseeger at
Wed Sep 11 06:35:03 UTC 2019


Am 11.09.19 um 06:24 schrieb Martin Schwenke via samba-technical:
> On Tue, 10 Sep 2019 20:17:28 -0700, Jeremy Allison <jra at>
> wrote:
>> 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.
> OK.
>> 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
>   contributors.
>   See the samba-technical process <url> for more details.
> I really think we should not push mailing list contributors to GitLab.

I like this approach, thanks Martin! Contribution via samba-technical
should still be possible (enough reasons have been mentioned before).

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


Karolin Seeger
Release Manager Samba Team
Team Lead Samba SerNet

More information about the samba-technical mailing list