Hi Sergio, It isn't really a PR-like workflow if the comments are on Jira and the topic branch is somewhere else as the definition of PR reviews is that the comments are inline with the code. However, that is what people typically used before GitHub/BitBucket started making PR available for code review so it is well known.
Once the comments are being mirrored to the list reliably (some have, but it may have broken itself), then PR should be fine from my point of view. If anyone is worried that they may not be getting notifications then they can Watch the GitHub repository in the meantime. Cheers, Peter On 14 April 2015 at 16:25, Sergio Fernández <wik...@apache.org> wrote: > In other projects we use jira issues and topic branches to allow PR-like > workflows. Could that work here? > > On Mon, Apr 13, 2015 at 7:02 PM, Stian Soiland-Reyes <st...@apache.org> > wrote: > >> Agree about the need to use list. >> >> The GitHub pull requests were meant to be mirrored two-way with the >> dev@ list - if this stopped working we need to ping INFRA agian. >> >> https://issues.apache.org/jira/browse/INFRA-9398 >> >> could anyone reincarnate this or ping them on #asfinfra? I'm afraid I >> am a bit busy today.. >> >> INFRA might be a bit busy at ApacheCon which started today. >> >> On 13 April 2015 at 17:33, Reto Gmür <r...@apache.org> wrote: >> > Reviewing a pull request I saw that a lot of discussion is goin on there: >> > >> > https://github.com/apache/incubator-commonsrdf/pull/7 >> > >> > conatining for example an important discussion point you raise: >> > >> > I have seen commons rdf as being for interoperability, not integration. >> Ie, >> >> it provides for passing objects across a boundary into another >> >> implementation, but doesn't require the other implementation to then >> agree >> >> on any further integration past what is required for future message >> passing >> >> operations to succeed. >> >> >> > >> > These comments never showed up on our list, this is problematic because >> at >> > apache "if its not on the list, it didn't happen". >> > >> > Cheers, >> > Reto >> > >> > On Sat, Apr 11, 2015 at 12:44 PM, Peter Ansell <ansell.pe...@gmail.com> >> > wrote: >> > >> >> Hi Reto, >> >> >> >> If you prefer to post patches to Jira (or email) then feel free to do >> >> so. Pull Requests on GitHub are just a smooth and fluid modern method >> >> of reviewing patches that reduce the turnaround for comments and >> >> acceptance of changes, which is a big deal for some contributors here. >> >> >> >> In terms of voting on each issue, that is not going to happen. If the >> >> issue is large, we encourage discussion about it before merging, but >> >> we are not going to vote on whether to accept a patch for issues. >> >> >> >> Cheers, >> >> >> >> Peter >> >> >> >> On 11 April 2015 at 21:47, Reto Gmür <r...@apache.org> wrote: >> >> > So you are suggesting we are actually requiring committers to use >> GitHub? >> >> > Not sure what the difference between "propose/(PR|JIRA)" and >> "(email|JIRA >> >> > -> PR/review)+" is in Andy's proposal. >> >> > >> >> > Are the pull request automatically referenced in the Jira issues? Are >> >> code >> >> > commits already referenced (or do we have to ask Infra to enable >> this)? >> >> > >> >> > I think as our project is supposed to deliver little but high quality >> >> code >> >> > this would be a case for the RTC approach. My suggestion would have >> been >> >> to >> >> > have branches in git (typically one per issue) and then vote on >> merging >> >> it >> >> > into master. >> >> > >> >> > Cheers, >> >> > Reto >> >> > >> >> > On Fri, Apr 10, 2015 at 10:54 AM, Sergio Fernández <wik...@apache.org >> > >> >> > wrote: >> >> > >> >> >> +1 the pragmatic approach Andy suggested >> >> >> >> >> >> On Fri, Apr 10, 2015 at 1:05 AM, Peter Ansell < >> ansell.pe...@gmail.com> >> >> >> wrote: >> >> >> >> >> >> > On 10 April 2015 at 03:49, Andy Seaborne <a...@apache.org> wrote: >> >> >> > > As a small project, I think we should be pragmatic: >> >> >> > > >> >> >> > > Things that are clearly fixes: >> >> >> > > commit-then-review >> >> >> > > Things that are localised changes: >> >> >> > > propose/(PR|JIRA) -> timeout -> commit >> >> >> > > Things that are major changes: >> >> >> > > (email|JIRA -> PR/review)+ -> commit >> >> >> > > >> >> >> > > making sure that the GH plumbing is actually sending the emails >> to >> >> dev@ >> >> >> > >> >> >> > >> >> >> > +1 for pragmatic. We are a very small project, so minor changes can >> >> >> > easily be reverted if they are not going to work, but if the >> change is >> >> >> > large it should be discussed first. >> >> >> > >> >> >> > Cheers, >> >> >> > >> >> >> > Peter >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Sergio Fernández >> >> >> Partner Technology Manager >> >> >> Redlink GmbH >> >> >> m: +43 6602747925 >> >> >> e: sergio.fernan...@redlink.co >> >> >> w: http://redlink.co >> >> >> >> >> >> >> >> >> -- >> Stian Soiland-Reyes >> Apache Taverna (incubating), Apache Commons RDF (incubating) >> http://orcid.org/0000-0001-9842-9718 >> > > > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: sergio.fernan...@redlink.co > w: http://redlink.co
