Bringing herbstluftwm to Github?

[Florian Bruhin]

* Thorsten Wißmann <edu at thorsten-wissmann.de> [2014-10-07 11:54:50 +0200]:
> Hi,
> 
> On Tue, Sep 30, 2014 at 10:26:01PM +0200, Florian Bruhin wrote:
> > some probably controversal proposal from me: What about creating an
> > "official" herbstluftwm project on github? Pushing code could be
> > managed via git hooks, so Thorsten could still push to the FAU repo
> > which then gets auto pushed to github.
> 
> Would be an idea. I just tried it and you can find it on
> 
> https://github.com/herbstluftwm/herbstluftwm

Thanks! :)

> > The issue tracker and pull requests could be disabled, but I'd even
> > vouch for enabling them. Why?
> > 
> > - Issue trackers is how people expect to be able to report issues
> >   nowadays. I remember people asking where to report stuff.
> 
> So that would solve the problem of an bugtracker?

Indeed - there's only one issue I can see: If Github for some reason
dies (or goes pay-only) we lose the issue list. But I don't expect
that to happen soon, and it could be backed up via the API (working on
that, for qutebrowser as well).

> > - Many people already have an account on Github, so it's very painless
> >   for them to create issues and contribute.
> 
> OK, but IMO good bugtrackers do not require an account. But important
> is: it is no pain for us (me, you?) to maintain a bugtracker.

That's true - but also yields spam problems. Okay, maybe with a check
and/or captcha that could be solved.

Either way, I'd say people can still report bugs via the
mailinglist/IRC and we'll either fix it right away or open an issue in
the tracker so it doesn't get forgotten - do you agree? That's
currently the workflow I have with qutebrowser, and I think it's
working pretty well.

> > - It's much easier to add comments and more information to long-living
> >   issues this way, and have everything at one place.
> 
> I thought, the "long-living" argument says: "do everything in the git
> and on the ML which is archived".

I think we're talking about two different things here - one is
"the data won't ever get lost" and the other is "it's easy to find
information on an issue which is a year old but I know is still
there" or "I want to see what issues there still are".

For #1, backing up via the API (as said above) is the paranoid
solution, thinking "github is too big to fail" is the pragmatic one.

For #2, a bug tracker definitely makes that easier.

> > - My personal opinion aside (I actually see why you prefer patches per
> >   email for single commits now) - pull requests are how people
> >   instictively try to contribute to projects. Just lately I've seen
> >   someone say "why can't we contribute to Python? There's no Github
> >   repo!" in #python.
> 
> But the remaining question is: what to do with pull requests that are
> unmergable (because of code quality)? Say to them they should fix it and
> send the pull-request with the rebased commits again?

With the github pull requests (tm), a pull request is just a pointer.
This means the pull request is just
"merge The-Compiler/herbstluftwm/frame_objects into
herbstluftwm/herbstluftwm/master". Until you hit the merge-button (or
fetch/merge in the commandline), I can still push new commits to my
own branch.

An example:

https://github.com/The-Compiler/qutebrowser/pull/1

The contributor (claudehohl) did some commits and opened the request.
I then did some comments, claudehohl pushed some other commits until I
decided it's okay and merged it.

I'm not sure what happens when claudehohl would've rebased his branch,
but I guess this would've worked the same way.

> > I believe the aim should be to make contributing as easy and native
> > for people as possible, even if that means some more work for the
> > maintainer. After all the time "gained" by a contribution is much
> > bigger than the one lost by using a different git workflow.
> > 
> > We can still say patches to the ML are the prefered way of
> > contributing, but I believe it'd attract more people to report their
> > issues, and probably also more people to contribute. And if someone
> > doesn't want to learn about git-format-patch/git-send-email, etc., I
> > think this shouldn't be the thing holding them back from contributing.
> 
> Well if someone does not want to learn "git format-patch origin/master"
> then maybe I don't want to teach him how to use git-rebase to fix the
> broken commits in his pull request.

You got a point there.

> In my opinion we can just try it and say the preferred way is the ML.
> And if I get annoyed by some issue I'll complain here to find the
> concrete solution for issue.

That sounds good.

> Note that all the arguments in your mail also imply: "Create a
> herbstluftwm facebook page & group" (everyone has an account, easier
> than sending mails, get known by more people to make them contribute to
> the project...) [Facebook = Internet within the Internet, Github =
> Git-Network+ML within the Internet]

Almost. I don't want to start a rant against facebook, but:

- With Github you still own your data and it's easy to get it out (or
  in case of the repo, you have your own copy either way).

- Facebook is not what people use for collaborating on geeky
  projects usually :P

- I even dare to say more hlwm users have a Github account than a
  Facebook one - just another intended audience :D

Florian

-- 
http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP)
             GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://listi.jpberlin.de/pipermail/hlwm/attachments/20141007/d9dc8ce4/attachment.sig>