The GitHub experiment (was: Re: [PR PATCH] [Updated] Readme GitHub)

Andrew Bartlett abartlet at
Fri Sep 18 19:29:44 UTC 2015

On Fri, 2015-09-18 at 12:37 -0500, Scott Lovenberg wrote:
> On Fri, Sep 18, 2015 at 8:14 AM, Volker Lendecke
> <Volker.Lendecke at> wrote:
> > Hi!
> > 
> > As far as I can see, this still has long lines. Please fix
> > that.
> > 
> > Thanks,
> > 
> > Volker
> > 
> Hi Volker,
> Did you look all the way to the end of the diff?  The longest in the
> second patch is exactly 80 (plus 1 char for the '+' in the diff).
> For some silly reason it looks like GitHub or the mailing list script
> stacked the first revision diff on top of the second revision diff
> instead of sending the second revision as a single diff.
> Andrew, this could be problematic for larger patch sets that get
> NACKed, revved and pushed to the feature branch that has the original
> pull request still open. Perhaps we'll have to have a separate pull
> request for each revision of a patch set?  Unfortunately that
> fragments the discussion/history of a patch set, but I could see this
> behavior to be much more confusing.

Thanks Scott, Volker.

In regards to this patch, the issue is that you need to download the
branch to your PC, rebase it with git rebase -i, and squash the two
patches.  Then when you re-push, there will just be one patch.

The main downside to watch out for is that ANY push to that branch will
trigger mail to the list, so only push when you think it is correct,
not just 'push to save' (use a different branch for that, not connected
to a pull request). 

That process (of clean patches) is a key part of the Samba development
pattern, and we should probably document that better, both in this
readme and on the wiki.

In the broader scope, as well as simply implementing what the team
agreed at SambaXP, I should have disclosed earlier this:

I see this effort as an experiment.  In the reading that I did on using
GitHub, I saw two (perhaps not opposing) views:  
 - being present on GitHub increases the breadth of contributors, and
the contribution rate
 - being present on GitHub decreases the quality of contributions.

Or, to put it as a hypothesis to be falsified, that "Accepting
contributions via GitHub will make no significant improvement in the
number of acceptable patch submissions"

My rush to get this all working last week was because I'm speaking in
Feb 2016 at in Geelong on "Samba + GitHub == Freedom???".

I'm hoping a few months of data will show there the opposite of the
above, that while GitHub is not a Free Software platform, that it
improves our breadth of contributors, bringing them into the fold by
making their first contribution easier.  That increase in developers
hopefully also increases the quantity of quality submissions, and so
improves Samba as free software.

None of that stops us tweaking the process or scripts along the way,
and I'm sure it will be an interesting few months!


Andrew Bartlett

Andrew Bartlett             
Authentication Developer, Samba Team
Samba Developer, Catalyst IT

More information about the samba-technical mailing list