[Top][All Lists]

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

Re: [Tinycc-devel] Governance (Re: cleanups)

From: avih
Subject: Re: [Tinycc-devel] Governance (Re: cleanups)
Date: Sun, 16 Oct 2016 17:23:58 +0000 (UTC)

I absolutely don't disagree that moderated PRs would be great for the reasons you've mentioned and more, and for whatever that's worth, I "voted" for the move to github.

My point was that due to the really great facilities which github offers (hats off to them), I expect that the communication focus would shift "naturally" to github, since discussions over PRs are likely to happen there, as well as bug reports, features suggestions, etc, and because they really make it easy to participate and communicate over code. And so, people go where they feel comfortable.

And once the communication at github goes beyond some critical mass and becomes more meaningful than the mailing list, then the project has effectively moved to github.

As I mentioned, I have nothing against that, but I think the "core governance" should consider that it might/will happen.

And that poses two issues:
1. What happens with the relation between the mailing list and github (some solutions/approaches were offered already).
2. How to make sure the "core governance" still doesn't lose all the communication if github closes tomorrow (also sort of addressed).

Just things to think about. I'm all for the move to github in general and moderated PRs specifically.

On Sunday, October 16, 2016 8:05 PM, David Mertens <address@hidden> wrote:

avih, one more note:

The big problem is not how we handle our discussions on the mailing list, it's when a person does not respect the open source governance and pushes a bunch of unsolicited commits without any discussion. This has happened many times over the last three or four years. Pull requests would let us manage those, mostly by preventing them when they do not fit the goals of the project (i.e. unwanted extensions to the compiler).

FWIW, I don't think this would stifle the current discussion of patches that occurs on the mailing list.


On Sun, Oct 16, 2016 at 12:53 PM, David Mertens <address@hidden> wrote:
On Sun, Oct 16, 2016 at 11:26 AM, avih <address@hidden> wrote:
> I am less concerned about losing this kind of meta-info, as I expect we would continue discussion primarily on the mailing list.

Would you/we?

The initial suggestion mentioned pull-requests as being easier to handle than discussing patches over mailing lists - to which personally I agree (though I don't claim everyone should agree to that).

PRs carry discussions - which typically happen on the PR "page", on github and the github hosting would also be quite more useful if people can report bugs via github.

I had a vision in which the pull requests lived on github, but discussion of merging (or not) would take place on the mailing list. Even if we don't use the github facilities for discussion, just having a system for managing pull requests is a big win, in my book.

That said, I think we can set up email notifications so that any bug notifications or pull requests would send an email to the mailing list. In that case, replies would go back to the PR/bug discussion, so we would have a synchronized discussion.
Otherwise, if there's no intention to use the github facilities which make collaboration easier and more visible, what's the point of moving to github? Just a different git-repo host?

Having a system for managing multiple pull-requests would be a big win. In addition, and probably more importantly, it's possible to set up travis and appveyor testing on pull requests, so we could get integration testing even before pulling in the code.


 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]