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.

David

On Sun, Oct 16, 2016 at 12:53 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> On Sun, Oct 16, 2016 at 11:26 AM, avih <avih...@yahoo.com> 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.
>
> David
>
> --
>  "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
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Reply via email to