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
>

Reply via email to