@Jeremiah, makes sense to send to commits@ On Fri, Aug 26, 2016 at 12:55 PM, Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote:
> +1 for PR’s but if we start using them I think we should get them sent to > commits@ instead of the dev@ they are currently sent to. > > -Jeremiah > > > On Aug 26, 2016, at 1:38 PM, Andres de la Peña <adelap...@stratio.com> > wrote: > > > > +1 to GitHub PRs, I think it will make things easier. > > > > El viernes, 26 de agosto de 2016, Jason Brown <jasedbr...@gmail.com> > > escribió: > > > >> D'oh, forgot to explicitly state that I am +1 one on the github PR > proposal > >> :) > >> > >> On Fri, Aug 26, 2016 at 11:07 AM, Jason Brown <jasedbr...@gmail.com > >> <javascript:;>> wrote: > >> > >>> It seems to me we might get more contributions if we can lower the > >> barrier > >>> to participation. (see Jeff Beck's statement above) > >>> > >>> +1 to Aleksey's sentiment about the Docs contributions. > >>> > >>> On Fri, Aug 26, 2016 at 9:48 AM, Mark Thomas <ma...@apache.org > >> <javascript:;>> wrote: > >>> > >>>> On 26/08/2016 17:11, Aleksey Yeschenko wrote: > >>>>> Mark, I, for one, will be happy with the level of GitHub integration > >>>> that Spark has, formal or otherwise. > >>>> > >>>> If Cassandra doesn't already have it, that should be a simple request > to > >>>> infra. > >>>> > >>>>> As it stands right now, none of the committers/PMC members have any > >>>> control over Cassandra Github mirror. > >>>>> > >>>>> Which, among other things, means that we cannot even close the > >>>> erroneously opened PRs ourselves, > >>>>> they just accumulate unless the PR authors is kind enough to close > >>>> them. That’s really frustrating. > >>>> > >>>> No PMC currently has the ability to directly close PRs on GitHub. This > >>>> is one of the things on the infra TODO list that is being looked at. > You > >>>> can close them via a commit comment that the ASF GitHub tooling picks > >> up. > >>>> > >>>> Mark > >>>> > >>>> > >>>>> > >>>>> -- > >>>>> AY > >>>>> > >>>>> On 26 August 2016 at 17:07:29, Mark Thomas (ma...@apache.org > >> <javascript:;>) wrote: > >>>>> > >>>>> On 26/08/2016 16:33, Jonathan Ellis wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> Historically we've insisted that people go through the process of > >>>> creating > >>>>>> a Jira issue and attaching a patch or linking a branch to > demonstrate > >>>>>> intent-to-contribute and to make sure we have a unified record of > >>>> changes > >>>>>> in Jira. > >>>>>> > >>>>>> But I understand that other Apache projects are now recognizing a > >>>> github > >>>>>> pull request as intent-to-contribute [1] and some are even making > >>>> github > >>>>>> the official repo, with an Apache mirror, rather than the other way > >>>>>> around. (Maybe this is required to accept pull requests, I am not > >>>> sure.) > >>>>>> > >>>>>> Should we revisit our policy here? > >>>>> > >>>>> At the moment, the ASF Git repo is always the master, with GitHub as > a > >>>>> mirror. That allows push requests to be made via GitHub. > >>>>> > >>>>> Infra is exploring options for giving PMCs greater control over > GitHub > >>>>> config (including allowing GitHub to be the master with a golden copy > >>>>> held at the ASF) but that is a work in progress. > >>>>> > >>>>> As far as intent to contribute goes, there does appear to be a trend > >>>>> that the newer a project is to the ASF, the more formal the project > >>>>> makes process around recording intent to contribute. (The same can be > >>>>> said for other processes as well like Jira config.) > >>>>> > >>>>> It is worth noting that all the ASF requires is that there is an > >> intent > >>>>> to contribute. Anything that can be reasonably read that way is fine. > >>>>> Many PMCs happily accept patches sent to the dev list (although they > >> may > >>>>> ask them to be attached to issues more so they don't get forgotten > >> than > >>>>> anything else). Pull requests are certainly acceptable. > >>>>> > >>>>> My personal recommendation is don't put more formal process in place > >>>>> than you actually need. Social controls are a lot more flexible than > >>>>> technical ones and generally have a much lower overhead. > >>>>> > >>>>> Mark > >>>>> > >>>>>> > >>>>>> [1] e.g. https://github.com/apache/spark/pulls?q=is%3Apr+is% > 3Aclosed > >>>>> > >>>>> > >>>> > >>>> > >>> > >> > > > > > > -- > > Andrés de la Peña > > > > Vía de las dos Castillas, 33, Ática 4, 3ª Planta > > 28224 Pozuelo de Alarcón, Madrid > > Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd > > <https://twitter.com/StratioBD>* > >
