I have offered this comment to the pull request. Hopefully, their next step will be to open a JIRA issue for it.
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Sat, Sep 3, 2011 at 6:58 AM, Richard Brown (gmail) < [email protected]> wrote: > I agree we should ensure the JIRA is still used and added in the commit > comments, not only to allow tracking through the history, but also to keep > the github JIRA integration working too. > > *From:* Diego Mijelshon <[email protected]> > *Sent:* Thursday, September 01, 2011 3:35 PM > *To:* [email protected] > *Subject:* Re: [nhibernate-development] Policy on PULL requests absent > correlated JIRA issue? > I'd just add a text to the README: > > "When submitting a pull request, please include a link to the JIRA issue > resolved by it, and add a link to the pull request in the JIRA issue ( > https://nhibernate.jira.com/)" > > This could be copy&pasted verbatim in pull requests that don't include JIRA > issues. > As long as there are bidirectional links, I don't think the fragmentation > will be an issue. > > Diego > > > On Thu, Sep 1, 2011 at 10:24, Stephen Bohlen <[email protected]> wrote: > >> This recent pull request >> https://github.com/nhibernate/nhibernate-core/pull/3 opens up an >> interesting challenge for us now that we are on github: how should we handle >> pull requests that don't have a correlated JIRA issue against them? This >> pull does mention an issue (NH-1280) but is actually a NEW issue related to >> something suggested to be a problem with the fix introduced for NH-1280 (and >> so IMO it should probably be logged as a new issue). >> >> My inclination is to tell people making pull requests that we have a >> policy that pulls without correlated JIRA issues aren't accepted, just as we >> never accepted SVN patches without a related JIRA issue. This was easier to >> 'enforce' with SVN b/c one needed the JIRA issue to attach the patch to in >> the first place but of course github makes it possible to circumvent that >> 'requirement' and issue an 'orphaned' pull request with no related JIRA >> issue (as seems to have been done in the case of this one). >> >> The challenge with something like github's pull-interface is that there >> are now potentially TWO places to 'discuss' the issue and any patch/pull >> related to it: JIRA and github. Fragmenting discussion of patch/pull >> submissions into multiple systems seems to me to be a bad/dangerous thing to >> support, but it also introduces an extra requirement on those forking and >> offering pull requests, potentially damping one of the stated goals of >> moving to github in the first place (increased ease of contribution by a >> wider group of participants). >> >> What are others' thoughts on the best way to handle this...? >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> > >
