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 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
