* Thorsten Wißmann <edu _at_ thorsten _minus_ wissmann _dot_ 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 _minus_ compiler _dot_ org (Mail/XMPP) GPG 0xFD55A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/
Attachment:
pgppADnRA7LGv.pgp
Description: PGP signature