I'm not sure how the "pull-request" concept can be applied to the Apache infrastructure. But what we should describe is we operate commit-then-review or review-then-commit. See: https://www.apache.org/foundation/glossary.html
Cheers, Reto On Tue, Mar 31, 2015 at 11:38 AM, John D. Ament <[email protected]> wrote: > I personally prefer the pull request approach. It gives others an > opportunity to review and provide input early in the development cycle. > > On Tue, Mar 31, 2015 at 6:31 AM Stian Soiland-Reyes <[email protected]> > wrote: > > > Hi, > > > > I saw this big merge from Peter: > > > > https://github.com/apache/incubator-commonsrdf/commit/ > > 20b0b000fc92a5699e0d79f9205cb62babe444bd > > > > This includes not just sorting out some BlankNode identifier stuff > > which we have already discussed at length (good) - but also a few > > other changes that got baked in, e.g. the return type of Graph.add(), > > and the removal of > > > > - Stream<? extends Triple> getTriples(Predicate<Triple> filter > > > > > > While I am not opposed to this removal (it's available as > > getTriples().filter()), I can't remember seeing these API changes > > being discussed (perhaps I missed something) - are we not keeping the > > way of working by pull requests and bugs? > > > > > > I would also prefer separate concerns as separate commits - I know > > from my own way of working that you find one thing when you work with > > another - but say getTriples(Predicate) has nothing with BlankNode > > identifiers directly, and so this should be a separate change request. > > > > > > > > I know we can follow and respond to commits@commonsrdf - but specially > > from git this often comes with 17 emails for a single merge, and so > > it's not good for anything but "something has changed". > > > > > > I propose that we work like this: > > > > API changes (e.g. signature modifications, change of semantics in > > javadoc) always as pull requests and/or Jira issues. > > > > Fixing typos, NullPointerExceptions and so on can just commit straight > in. > > > > "Trying out something" should be done as a branch or personal fork. > > (Branch is preferred, as it allows others to modify your experiment) > > > > Semantic changes to the tests should be pull requests and Jira issues > > - as they are the other half of the contract. > > > > Changes to the simple implementation to conform with the tests can go > > straight in. > > > > Changes to the simple implementation that forces a new contract > > implication (typically something we haven't explored in detail yet) > > should be formalized as new javadoc/tests - and therefore raised as a > > separate discussion point by pull request or issue. > > > > Brand new implementation stuff should be done as a branch or pull > > request (there is probably not many of these for now). > > > > > > In general - a pull request is preferable to an issue, as an issue is > > an unbounded discussion, while a pull request is a concrete change > > request that can be tweaked. > > > > If we do it the Commons way - then any other committer can review and > > accept the pull request - although I think we should also allow room > > for the consensus to form - specially on API changes & design issues > > which we want to be considerate about. > > > > > > Views? > > > > -- > > Stian Soiland-Reyes > > Apache Taverna (incubating), Apache Commons RDF (incubating) > > http://orcid.org/0000-0001-9842-9718 > > >
