Re: github... need suggestions from you.

["Andreas Bießmann" <andreas@biessmann.de>]

Dear Bryan,

On 2014-12-09 13:15, Bryan Hundven wrote:
> 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

<snip shortlog showing me has just 1 commit>

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

No, that was not my intention. As I said in my first mail please do so, 
but
_also_ accept others to still send patches by mail.

> 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! :) :) :)

No problem. Your statement was that 'prior github was "git send-email"',
but 'post github there will be the need for pull requests'. Saying this,
one could assume that some day no emailed patches will be accepted.

You've proven above that I'm not really a tool-chain developer, that's 
true.
But I'm a tool-chain user and have to build a new one from time to time.
Fortunately ct-ng is somewhat stable and meet my needs, but sometimes 
(at
least once) I also find a Bug and like to give the fix back to the 
community.
For me it is way faster to build the fix and send the mail than get an
github account, do the fork, push my branch and send the PR.

Your shortlog above has shown a noticeably list of authors having just
a few commits. I think they are also more ct-ng users than core 
developers.
I assume that for those users the mail way is more efficient than the
proposed way. But this remains to be proven ...

And again, as long as the mail way is still available I see really no
problem.

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

That is reasonable ...

> I
> have other ideas and uses for the actual server everything is running
> on, so it is not going away any time soon.

May statement is, please keep it (the mail way to send patches) even 
longer ;)

> ****
> 
> 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!

You are right. I took that example cause of the need for different 
workflow.
Some where excited about the new approach while some other could not get 
familiar
with the workflow required by this change.

Here we have the suggested new workflow by sending pull requests for 
some
self-maintained repository at github vs. patches via mail to the list. 
In an
abstract way this is comparable.
But you are right, if the majority of the core developers supporting the
suggested workflow it must be implemented. That was not clear to me, 
cause
there where no single response to your mail before.

<snip detailed explanation why gerrit will not work for non android 
projects>

> Github != Gerrit

You are right. I brought that up cause of the change in workflow as 
mentioned
above.

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

But it misses a mailing list ... and therefore forces to use pull 
requests.

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

I think point 1 could be achieved in another way too ... but having an
issue tracker integrated in the SCM is a really good point.

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

So having a repo outside github will also work? I do not have a github
account and as said in my first mail do not plan to do so.

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

For me this is a new point. Your first mail does not show this position
and I appreciate it.

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

Well, as stated above I'm far away from a core developer of ct-ng. At 
most
I'm a user who provides patches from time to time. Maybe sometime I will 
do
reviews too. Then I have to learn the way the community does this. No 
problem
so far ;)

Again, my statement was 'please do not shut down the ability to send 
patches
via mail ever'.

I will not (and as you showed above I'm far away from having that 
standing here
to do so) force the core developers to use a specific workflow.

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

Hi ;)

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

I think my sentence
'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.'
was constructive, at least this was my intention. And as you have shown: 
The
mail amount from me will not keep you busy continuously ;)

> 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 don't think this will happen ever ;)

> ***
> 
> 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!

I'm sorry, but I don't think I have time to help here. I'm _not_ all
against new stuff, but I'm busy with other stuff. Therefore my 
statement,
please do not complicate the way rare users can support the community.

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

I appreciate your democratic attitude.

As said multiple times before. I'm not at the position to force the 
ct-ng
developers to use that workflow or another. All I'd like to say (and 
what
I intended to say in my first mail) is: Please keep the traditional way
to send patches via mail for those users of ct-ng which have 
improvements
and like to support, at least a bit.

As I understand your detailed explanation patches via mail will still
be accepted. Is that true?

best regards

Andreas Bießmann

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