Document GitLab as the only way to contribute to Samba?
kseeger at samba.org
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 samba.org>
>> 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
>>>> If you are interested in reviewing patches submitted to Samba, please
>>>> ensure you have a gitlab.com account and are watching our public gitlab
>>> 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
>>> 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
>> 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 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 https://samba.org/~kseeger/
Release Manager Samba Team https://samba.org
Team Lead Samba SerNet https://sernet.de
More information about the samba-technical