[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bringing herbstluftwm to Github?



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

> Rationale:
> 
> Some search engines like duckduckgo display github repos on top in
> some box. There are now some unoffical repos[1] floating around and
> all this might be confusing for people - actually I remember people
> linking some github repo and asking if that's the right one.

Good (and sad?) argument.

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

> - If someone wants to contribute, they can easily look at the issue
>   list instead of digging through the mailinglist and checking what's
>   not done yet by hand.

Right.

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

> - Many issues are forgotten after some time, or not in BUGS at all, or
>   in BUGS but fixed, or in my personal collected wishlist but not in
>   BUGS, so not easily visible for anyone.

Yes, (not) maintaining the BUGS file is horrible.

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

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

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

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.

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]

Cheers,
Thorsten

Attachment: pgp_VWPhOxMPr.pgp
Description: PGP signature