Re: github... need suggestions from you.

[Bryan Hundven <bryanhundven at gmail dot com>]

Andreas,

On Tue, Dec 9, 2014 at 1:56 AM, Andreas Bießmann <andreas@biessmann.de> wrote:
> Dear Bryan,
>
> On 2014-12-09 09:24, Bryan Hundven wrote:
>>
>> List,
>>
>> Prior to github, you'd 'git send-email' a change, it would be peer
>> reviewed here, and once approved, it was applied.
>>
>> Post github, you fork the repo, make a branch, commit your changes,
>> and approvals are done prior to merging the change.
>
>
> I personally dislike this change. I'll not get an github account just for
> adding changes to ct-ng.
> Maybe I'm a bit out-of-date, but I really like the 'git send-email' feature
> and can't get familiar with latest evolutions in opensource development
> tools and work-flows. It seems others can't either. U-Boot tried to
> implement gerrit [1] which would also be a drastic change in how to work
> together. Finally this was stopped in favour of the old fashioned way.
>
> All I'd like to say is: Bryan, if you think going to github is a good idea,
> please do so. But please also accept that at least some still want to send
> their changes via mail. If going to github also means we kill the list, the
> mail would finally end at your address.
>
> best regards
>
> Andreas Bießmann
>
> [1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/173795

Lets look at some simple stats:

Disclaimers:
  * emails not added to the stats for obvious reasons!
  * a few user names are duplicated because of bad commits with
     unbalanced quotations in the users name. I've done it a few times(6)... and
     gesh.. Yann did it 2511 times! :P :)
  * I have a no-nonsense, "matter of fact" attitude, and if you read
too deep into what I'm
    saying, I may seem snarky and offending. If you're offended, then focus on
    the code and not my attitude. If you get mad at me for my attitude, I will
    ignore you and go back to code. The focus: Code
  * I don't like politics, it's the fast-path to my bad side. This is
a community, not a
    congress.

$ git shortlog -sn

  2511 Yann E. MORIN"
    50 Bryan Hundven
    48 Benoît Thébaudeau"
    40 Yann E. MORIN
    32 Titus von Boxberg
    26 Benoît THÉBAUDEAU"
    15 Johannes Stezenbach
    15 Zhenqiang Chen
    14 David Holsgrove
    11 Michael Hope
    11 Titus von Boxberg"
    10 Daniel Zimmermann
     8 Anthony Foiani
     8 Arnaud Lacombe
     8 Joachim Nilsson
     8 Thomas Petazzoni
     7 Cody P Schafer
     7 Esben Haabendal
     7 Yann Diorcet
     6 Bryan Hundven"
     6 Martin Lund
     6 Richard Strand
     5 Bart van der Meulen
     5 Bart vdr. Meulen
     5 Cody Schafer
     5 Florian Fainelli
     5 Ray Donnelly
     4 Fabian Freyer
     4 Martin Lund"
     4 Remy Bohmer
     4 danielrubiob
     3 Bart vdr Meulen
     3 Daniel Price
     3 Frederic Roussel
     3 Frederic Roussel"
     3 Jang, Bongseo
     3 Robert P. J. DAY"
     3 Samuel Martin"
     3 Thomas De Schampheleire
     2 Bernhard Walle
     2 Ingmar Schraub
     2 Jerzy Grzegorek"
     2 Niels Penneman
     2 Samuel Martin
     2 Trevor Woerner
     2 Zhuang Yuyao
     1 Alexandre Belloni
     1 Andreas Bießmann
     1 Andrzej Bieniek"
     1 Andy Gibbs"
     1 Anton Leontiev
     1 Antony Pavlov
     1 Arnaud Vrac
     1 Austin Morton
     1 Blair Burtan
     1 Bob Dunlop
     1 Chih-Min Chao
     1 Daniel Dittmann
     1 Daniel Rubio Bonilla
     1 Daniel Schultze
     1 Darcy Watkins
     1 Doug Kehn
     1 Erik Inge Bolsø
     1 Giammarco Zacheo
     1 Heiko Zuerker
     1 Ilya A. Volynets-Evenbakh"
     1 Jason T. Masker
     1 Javier Viguera
     1 Jean-Marie Lemetayer
     1 Jim F
     1 Jon Ringle
     1 Jonathan Liu
     1 Jongsung Kim
     1 Kalle Kankare
     1 Kévin PETIT
     1 Martin Guy
     1 Matthieu Crapet
     1 Nate Case
     1 Oron Peled
     1 Oron Peled"
     1 Richard Braun
     1 Simon Pasch
     1 Solomon Peachy
     1 Willy Tarreau
     1 Yann Diorcet (diorcet yann
     1 Zoltan Devai
     1 blueness
     1 convert-repo
     1 goodmenlinux@gmail.com
     1 harold
     1 nyet

Not trying to pull rank or anything, but... what you're saying is that
all the people that have privately emailed me to thank me for moving
to github (which have more historical commits then you have) should be
negated by one person's desire to not use github?

Trust me, if more people tell me to not move to github, then I will
take it into account!
So far, I have 1 for "No".

I have both repositories (github.com and crosstool-ng.org) up, people
are opening pull requests on github and sending patches via the
mailing list, and I'm still applying both. So, really... Nothing has
really changed. I'm currently not forcing either situation. So...
Relax! :) :) :)

The advantage to using github, solely, is to remove the burden of
maintaining the infrastructure needed to host the repository, manage
the patches to be applied/merged, the website, all while picking up
the ability to track issues/bugs (that we currently do not have). I
have other ideas and uses for the actual server everything is running
on, so it is not going away any time soon.

****

Now, to take a step back and compare the sample use-case of u-boot and
gerrit that you brought up.

I read the whole thread, and if you notice, it also wasn't a forced switch!

Vadim setup a "SAMPLE" gerrit instance to test if it helped or
hindered the development process for u-boot. Which it obviously did
not fit their development process. U-boot's development process is
much different the crosstool-NG's.

Crosstool-NG has a mainline development process. Historically, after a
release was cut, a branch was made to maintain that branched version
(as per the goals of crosstool-NG). That has sort of fallen off since
we converted from mercurial to git, but I plan on picking that piece
back up.
Also... No one has sent any patches for previous releases, so maybe
it's not relative anymore... different topic of discussion. It's made
up mostly of shell scripts and makefiles that in-turn build other
tools into a toolchain. So I don't see this as "Software development"
as much as I see it as "Scripting". But, we don't have any crazy
branching in our development workflow.

U-Boot has a mainline branch, but topics of development are done in
"Topic Branches", and then merged into the mainline branch as they are
approved. Then either those topic branches are removed, or rebased to
master and continued. Their code base is largely C and Assembly, with
a mix of other stuff to build and automate u-boot. It is widely more
complex then crosstool-NG, and the development workflow is totally
different.

It's not surprising that gerrit did not work for them, since of all
the non-android projects that have tried to use gerrit have reverted
away from it.

Gerrit does not work well with non-android projects. Gerrit becomes a
gatekeeper for the development process, instead of just using git. You
are required to install the gerrit command line tools, if you don't
want to use the web interface. Getting everyone to change their
workflow is not intuitive.

Github != Gerrit

Github does not get in the way of the development process. It's Just
Git! (with some services around it, and some social stuff, which I
don't care too much about)

Github does not integrate with your google account. I personally am
looking to move away from using my google account for my developmet
tasks, but that's not part of this conversation.

The only thing github does for us is set access control on who can
commit directly to the repository, which I hope increases in time, as
I don't want the project to depend on ONE person to keep the project
going. It also does something we don't have which is to keep track of
issues.

Again, it shouldn't get in the way. You don't need any command tools,
besides git. I've used github for quite some time, and I rarely need
to use the web interface. I can handle most tasks from my email client
(as I said, is changing for my development work) and my git client.
You as a developer (non-maintainer) shouldn't need the web interface
for anything but opening a pull request (which is just clicking one
button) and making a new tree (which you probably won't do much if you
just work in crosstool-NG). You can do all of your branching and
everything else just as you normally would with your own git
repository.

I'm currently researching how we can integrate github and the mailing
list. I don't want the mailing list to go away, and I'd like the
ability for pull requests and changes to go back and forth to github
from the mailing list and visa-versa. There is this whole service
backend for github, and I'm sure there is a way to make this work!
Research == Time.

***

Now, I get that the review style changes a lot! It doesn't work the
same way we have normally done changes on crosstool-ng and it is a
MAJOR change! I am personally struggling with that change myself. So
don't take what I'm writing personally! :)
If you do, then I'm not going to take your issues personally, and will
just ignore you and get back to code.

I'm also learning to be a maintainer, by way of being thrown at the
wolves. Hello! :D

This email went out to the community to get *constructive* feedback. I
am not interested in hearing:

   "This sucks. Don't do it!" << I will ignore this stuff (from here on out).

Let's work on the constructive part, and I'm sure that if we work
together, we can come up with compromises.

Granted, if you still don't want to work with the community to come up
with a compromise, you can always just fork the project and call it
CrossAndreas-NG, and do what you want. YEAY GPL! :)

***

I've been sectioning off this email with asterisks; Just guessing that
you noticed :)
In this section I'm going to re-word what I originally wrote this
email about, and I'm looking for *constructive* feedback.

We need to come together and figure out a workflow that we can all
live with. Yes, github does things a little different. But what it
does mostly is take a lot of server maintenance cruft off my back.
Here is the github services api:
https://github.com/github/github-services
I'm sure there is stuff in there that we can use to make this work
with our mailing list. Lets work together on this!

Or... you can respond with "No". I will add it to the tally of "No"'s
(currently 1), and if it is more then the number of contributors in
the last year, I will reconsider. It's all based on the communities
decision. Not only mine and not only yours.

Cheers,

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq