[
https://issues.apache.org/jira/browse/LUCENE-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862460#comment-13862460
]
Hoss Man commented on LUCENE-5383:
----------------------------------
bq. Don't overengineer it: your overengineered scheme would not work anyway,
with both bitbucket and github seeing the word "pull request" in the change
anyway (both number them) and tripping each other up and linking unrelated
issues to other things.
playing nice with github/whatever should be a secondary concern compared to
keeping good records of the providence of contributions. (and as mentioned:
should only be a factor in the _commit_ msg, we could differentiate in the
_CHANGES_ entry however we want)
But whatever -- i don't really care that much about whether changes2html should
expect/require "github pull request #xxx" vs just "pull request #xxx" when
hyperlinking -- if people think "pull request #xxx" is good enough so be it.
However: i still think the conventions you are advocating of putting the pull
req number in the front of the CHANGES entry (as if it were a Jira#) and always
making the CHANGES entry exactly like the commit message ("pull request #xxx"
at the front of both) doesn't really make much sense for 2 reasons...
1) as demonstrated by the example i mentioned above where we might have both a
Jira# and a pull req#
2) Situations where a single logical feature/bug-fix consists of mutiple
commits which might come from multiple pull requests (independent of whether
we have a jira tracking that feature/bug-fix). we typically only give logical
changes a single entry in CHANGES and list the multiple contributors who
participated in the multiple patches/commits. It would seem to make a lot more
sense to put the pull request info next to the name of the person who submitted
it, or at the end.
As a Concrete example, consider something like LUCENE-5273. It has a single
entry in CHANGES.txt, but there were 3 separate commits, containing
contributions from 3 distinct people who found bugs & help improve performance
before it was released....
* https://svn.apache.org/viewvc?view=revision&revision=r1531354
* https://svn.apache.org/viewvc?view=revision&revision=r1531711
* https://svn.apache.org/viewvc?view=revision&revision=r1531750
If one or more of those contributions had come in as pull requests, how would
you suggest we track them in CHANGES.txt?
I agree that listing the specific pull request # in the individual commit
messages to help integrate with github makes perfect sense, but I don't see how
trying to keep the CHANGES.txt entry identical to the commit message would even
be possible in a multi-commit situation -- and putting "pull request #xxx" (for
_each_ pull request) at the front of CHANGES.txt would make it really weird to
read. It seems like it would make a lot more sense to batch them up in a
single short statement -- preferably at the end of the entry along with the
existing info of _who_ made the contributions...
{noformat:title=commit message: pull request #123 - Add a
HupperDuperMergeDestroyer}
+ * New HupperDuperMergeDestroyer class for destroying merges
+ (Sally Contributor via Suzy Committer - pull req #123)
{noformat}
{noformat:title=commit message: pull request #456 - Perf improvements for
HupperDuperMergeDestroyer}
* New HupperDuperMergeDestroyer class for destroying merges
- (Sally Contributor via Suzy Committer - pull req #123)
+ (Sally Contributor, Joe Contrib via Suzy Committer - pull req #123, #456)
{noformat}
{noformat:title=commit message: pull request #789 - Generalize
HupperDuperMergeDestroyer into HupperDuperMergeRecycler}
- * New HupperDuperMergeDestroyer class for destroying merges
- (Sally Contributor, Joe Contrib via Suzy Committer - pull req #123, #456)
+ * New HupperDuperMergeRecycler class for destroying or re-using merges
+ (Sally Contributor, Joe Contrib, Amy Contrbutor via Suzy Committer - pull
req #123, #456, #789)
{noformat}
I think that in the long term, something like that will make a lot more sense
then trying to put "pull request #xxx" at the front of the entry for _every_
pull request that might related to that feature/fix -- but whatever.
if you still think this is over complicated and you're adamant about doing it
your way, then do it your way. we can always change the convention, update old
entries, and revise changes2html later if it becomes problematic as i expect it
will.
> fix changes2html to link pull requests
> --------------------------------------
>
> Key: LUCENE-5383
> URL: https://issues.apache.org/jira/browse/LUCENE-5383
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
>
> If someone submits a pull request, i think we should put it in changes.txt in
> some way similar to the jira issues:
> e.g. for a JIRA issue we do:
> {noformat}
> * LUCENE-XXXX: Add FooBar. (Joe Contributor via John Committer)
> {noformat}
> changes2html recognizes and expands these to jira issue links.
> so I think we should be able to do something like:
> {noformat}
> * pull request #xxx: Add FooBar. (Joe Contributor via John Committer)
> {noformat}
> and have it link to the request, too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
