Document GitLab as the only way to contribute to Samba?

[Michael Adam]

On 2019-06-28 at 22:52 +1200, Andrew Bartlett via samba-technical wrote:
> On Fri, 2019-06-28 at 12:46 +0200, Michael Adam wrote:
> > On 2019-06-21 at 13:05 +1200, Andrew Bartlett via samba-technical wrote:
> > > [...]
> > > So, I would like to propose this.  That given the practice of the Samba
> > > Team and almost all contributors is to contribute via a merge request
> > > against https://gitlab.com/samba-team/samba that we document this, and
> > > only this, as how to contribute to new patches to Samba.
> > > 
> > > [...]
> > > 
> > > Essentially it would mean a better version of this being prominently
> > > placed:
> > > 
> > > https://wiki.samba.org/index.php/Samba_CI_on_gitlab#Creating_a_merge_request
> > 
> > There is one thing I find confusing about the above page and that
> > needs to be cleared: It creates the impression that the only way
> > to file a merge request for samba via gitlab is to get access to
> > the CI repository https://gitlab.com/samba-team/devel/samba
> > and push to a personal subdir+branch there and create a MR from there.
> > 
> > In contrast, if I get it right, I think the *normal* way to file a MR,
> > would be to create your own personal fork of https://gitlab.com/samba-team/samba
> > on gitlab, push your branch there, and create a MR from there.
> > Upon filing the MR, the CI is triggered on the proposed patchset.
> > 
> > My understanding is that the CI repo is intended to give access
> > to the CI with*out* requiring to file a MR to the main repo.
> 
> Sadly no.  Any repo can do the CI, and a personal fork can file a merge
> request.  That is the normal way to use GitLab.
> 
> Unfortunately Samba is special, and some of our tests need larger
> runners while others need ext4 file systems.  Both of these force us to
> maintain our own runners.
> 
> However CI runners are attached to the *source* of the merge request,
> not the target, so need to come from (this specific) samba-team repo.

Ugh. That's really strange. Is this a gitlab design choice?
Because if it is, it's finally a thing (and quite a major one),
where gitlab is way worse than github. ;-)

Over the past few years, I've been working a lot on projects that
are using github, and there, the repository that you file a PR
(pull request) against defines what CIs and what test suites are
run against the PR. (And each project can define extra, custom
CIs to run via web-hooks, etc.) Honestly, having the source of the
MR define what CI to use and what tests to run doesn't seem to
make any sense to me at all.. :-(

I hope I misunderstood.
Maybe you can elaborate a bit more.

> Some magic ensures we still do a lot of CI on user private
> repositories, so eg a docs fix or new debug message is pretty safe from
> a personal fork, but a full check requires that repo. 
> 
> I bit of a wrinkle I know, but the best we can mange so far. 
> 
> I hope this clarifies, or at least provides some amusement!

Both. ;-)

Cheers - Michael

> Andrew Bartlett 
> -- 
> Andrew Bartlett                       http://samba.org/~abartlet/
> Authentication Developer, Samba Team  http://samba.org
> Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba
> 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20190628/336aaa64/signature.sig>