Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.7, 6.0
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      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:

      * LUCENE-XXXX: Add FooBar.  (Joe Contributor via John Committer)
      

      changes2html recognizes and expands these to jira issue links.

      so I think we should be able to do something like:

      * pull request #xxx: Add FooBar. (Joe Contributor via John Committer)
      

      and have it link to the request, too.

      1. LUCENE-5383.patch
        1 kB
        Steve Rowe
      2. LUCENE-5383.patch
        2 kB
        Steve Rowe
      3. LUCENE-5383.patch
        1 kB
        Steve Rowe

        Activity

        Hide
        Uwe Schindler added a comment -

        I don't trust GITHUB and the persistence of links to their system. So we have to make sure the links to non-apache resources from our changes.txt are persistent!

        Show
        Uwe Schindler added a comment - I don't trust GITHUB and the persistence of links to their system. So we have to make sure the links to non-apache resources from our changes.txt are persistent!
        Hide
        Hoss Man added a comment -

        "pull request" is vague - github is the flavor of the year, but that doesn't mean it will be obvious what system "pull request #xxx" refers to a year from now. I would suggest a convention of "github pull req #xxx" may help clarify longer term.

        I don't trust GITHUB and the persistence of links to their system.

        +1

        So we have to make sure the links to non-apache resources from our changes.txt are persistent!

        -0

        We've never, to my knowledge, had a hard and fast rule that every entry in CHANGES.txt needed to have an issue# (Jira now, bugzilla once upon a time) associated with it - but we've built up our tools such that if they have an issue number we link to it if we can.

        I don't see how referring to github pull requests (or github issue# if people start filing those, or CVE numbers, or hyperlinking raw URLs people type in) is really any different.

        If we start getting more patches from github pull requests, and more people start committing those patches directly w/o opening jira issues, then having some ref id in CHANGES.txt to refer to those contributions is better then nothing. And if we can also make a best effort to link those ref ids to more context on a third party system, we should attempt to do so – even if we can't guarantee those links are persistent.

        As long as the build doesn't fail if the third party server is down when we're trying to generate the changes.html, I don't see a problem with it. (it's no different then the way we generate javadocs that link to Oracle – we don't trust that Oracle's servers will be up when we generate the links, but we do assume the links won't change, and if they do - oh well.)

        Show
        Hoss Man added a comment - "pull request" is vague - github is the flavor of the year, but that doesn't mean it will be obvious what system "pull request #xxx" refers to a year from now. I would suggest a convention of "github pull req #xxx" may help clarify longer term. I don't trust GITHUB and the persistence of links to their system. +1 So we have to make sure the links to non-apache resources from our changes.txt are persistent! -0 We've never, to my knowledge, had a hard and fast rule that every entry in CHANGES.txt needed to have an issue# (Jira now, bugzilla once upon a time) associated with it - but we've built up our tools such that if they have an issue number we link to it if we can. I don't see how referring to github pull requests (or github issue# if people start filing those, or CVE numbers, or hyperlinking raw URLs people type in) is really any different. If we start getting more patches from github pull requests, and more people start committing those patches directly w/o opening jira issues, then having some ref id in CHANGES.txt to refer to those contributions is better then nothing. And if we can also make a best effort to link those ref ids to more context on a third party system, we should attempt to do so – even if we can't guarantee those links are persistent. As long as the build doesn't fail if the third party server is down when we're trying to generate the changes.html, I don't see a problem with it. (it's no different then the way we generate javadocs that link to Oracle – we don't trust that Oracle's servers will be up when we generate the links, but we do assume the links won't change, and if they do - oh well.)
        Hide
        Robert Muir added a comment -

        I would suggest a convention of "github pull req #xxx" may help clarify longer term.

        I don't think we should make this complicated without good reason. We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing.

        Show
        Robert Muir added a comment - I would suggest a convention of "github pull req #xxx" may help clarify longer term. I don't think we should make this complicated without good reason. We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing.
        Hide
        Hoss Man added a comment -

        it should also be recognized by github so the contributor knows we actually committed the thing.

        isn't that more a question of the commit message then what appears in CHANGES.txt?

        I believe all github cares about (for updating the pull request metdata on their end) is the commit message – so as long as that says "pull request #xxx" they'll do there thing – we should put whatever we think is best in CHANGES.txt to help us understand the providence of the code. I think adding the word "github" somewhere near "#xxx" would be helpful for us to keep things straight in the long term,

        Show
        Hoss Man added a comment - it should also be recognized by github so the contributor knows we actually committed the thing. isn't that more a question of the commit message then what appears in CHANGES.txt? I believe all github cares about (for updating the pull request metdata on their end) is the commit message – so as long as that says "pull request #xxx" they'll do there thing – we should put whatever we think is best in CHANGES.txt to help us understand the providence of the code. I think adding the word "github" somewhere near "#xxx" would be helpful for us to keep things straight in the long term,
        Hide
        Robert Muir added a comment -

        Don't clip my sentence in half, read the whole thing. thanks!

        Show
        Robert Muir added a comment - Don't clip my sentence in half, read the whole thing. thanks!
        Hide
        Hoss Man added a comment -

        I read the whole sentence, but i only felt the need to response to part of it.

        If it's important to you that i repsond to the whole thing...

        We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing.

        commit messages and CHANGES entries today are frequently the same but not always (examples: most people don't include the contributors names in the commit msg, but we do in CHANGES, if i'm merging to another branch i always include the source rev in the commit message but obviously never in CHANGES, sometimes people commit things for multiple issues at once, and use a isngle commit message refering to all of the affected issue#s, but split them out and provide more detail in CHANGES, etc...)

        It's been convention because it worked well, but it's never been a rule and it's never been enforced.

        we're now having a conversation about how we want to change our conventions and general practices to better integrate with github – and that's fine and i'm all in favor of it, but since by definition this a conversation about changing conventions I don't see why we it's a bad idea to consider tweaking one convention (keeping commit messages close to CHANGES entries) slightly in order to have better records as we amend another convetion (refering to github pull requests in commit msgs and/or CHANGES)

        If all github cares about is seeing "pull request #xxx" in the commit message, then what's wrong with using "pull request #xxx" in the commit msg – but in CHANGES.txt (where we are trying to keep a long term human permanent record of where stuff comes from and why) also mention, in some way, in some part of the CHANGES entry that the patch was contributed via github? (so X years from now when we are getting contributions via MercurialHub and BitBucket mirrors we'll know what the fuck we were talking about back in 2014)


        Or let's put it another way and consider the more general problem...

        Imagine a situation where we have a Jira issue tracking a bug, where people have heavily discussed the bug and explained it's symptoms and what's bad about it, and how it affects things, and you can work around it in some situations but not in others. (ie: stuff people might care about when reading CHANGES.txt to know if it's something that may affect them and their upgrade testing) and then someone comes along and contributes a fix, but instead of attaching it to the jira, they submit it as a pull request.

        how should that be tracked in CHANGES.txt?

        I would suggest that something like this may be a good convention moving forward...

        comit msg
        LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause merges to not be destroyed if it was a tuesday and you live in Angola (github pull request #ABC)
        
        CHANGES.txt
        * LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause
          merges to not be destroyed if it was a tuesday and you live in Angola
          (Sally Contributor via Jim Commiter - github pull request #ABC)
        

        With all of the changes2html hyperlinking you might expect.

        If there is no Jira, leave that part out (just like we do today). If there is no Contributor, leavethat part out (just like we do today). If there is no github pull request, leave that part out (just like we do today)

        Thoughts?

        Show
        Hoss Man added a comment - I read the whole sentence, but i only felt the need to response to part of it. If it's important to you that i repsond to the whole thing... We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing. commit messages and CHANGES entries today are frequently the same but not always (examples: most people don't include the contributors names in the commit msg, but we do in CHANGES, if i'm merging to another branch i always include the source rev in the commit message but obviously never in CHANGES, sometimes people commit things for multiple issues at once, and use a isngle commit message refering to all of the affected issue#s, but split them out and provide more detail in CHANGES, etc...) It's been convention because it worked well, but it's never been a rule and it's never been enforced. we're now having a conversation about how we want to change our conventions and general practices to better integrate with github – and that's fine and i'm all in favor of it, but since by definition this a conversation about changing conventions I don't see why we it's a bad idea to consider tweaking one convention (keeping commit messages close to CHANGES entries) slightly in order to have better records as we amend another convetion (refering to github pull requests in commit msgs and/or CHANGES) If all github cares about is seeing "pull request #xxx" in the commit message, then what's wrong with using "pull request #xxx" in the commit msg – but in CHANGES.txt (where we are trying to keep a long term human permanent record of where stuff comes from and why) also mention, in some way, in some part of the CHANGES entry that the patch was contributed via github? (so X years from now when we are getting contributions via MercurialHub and BitBucket mirrors we'll know what the fuck we were talking about back in 2014) Or let's put it another way and consider the more general problem... Imagine a situation where we have a Jira issue tracking a bug, where people have heavily discussed the bug and explained it's symptoms and what's bad about it, and how it affects things, and you can work around it in some situations but not in others. (ie: stuff people might care about when reading CHANGES.txt to know if it's something that may affect them and their upgrade testing) and then someone comes along and contributes a fix, but instead of attaching it to the jira, they submit it as a pull request. how should that be tracked in CHANGES.txt? I would suggest that something like this may be a good convention moving forward... comit msg LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause merges to not be destroyed if it was a tuesday and you live in Angola (github pull request #ABC) CHANGES.txt * LUCENE-XYZ: Fixed a bug in the HuperDuperMergeDestroyer that would cause merges to not be destroyed if it was a tuesday and you live in Angola (Sally Contributor via Jim Commiter - github pull request #ABC) With all of the changes2html hyperlinking you might expect. If there is no Jira, leave that part out (just like we do today). If there is no Contributor, leavethat part out (just like we do today). If there is no github pull request, leave that part out (just like we do today) Thoughts?
        Hide
        Robert Muir added a comment -

        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.

        Instead keep it simple and we will have consistency, committers will understand the system and use it.

        Show
        Robert Muir added a comment - 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. Instead keep it simple and we will have consistency, committers will understand the system and use it.
        Hide
        Steve Rowe added a comment -

        I would suggest a convention of "github pull req #xxx" may help clarify longer term.

        I don't think we should make this complicated without good reason. We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing.

        Adding the word "github" is complicated? Um, I don't think so.

        However, since "pull request" is AFAICT synonymous in the current context with "github pull request", and this is likely IMHO to be the case for years, we should not require committers to include "github" in CHANGES.txt entries to get pull request references linked to github pull requests.

        Does Github describe their commit message pull request reference syntax anywhere? I did lots of searching and couldn't find it (I only found stuff about how to refer to/close issues from commit messages). Apparently case-insensitive "pull request # <num>" is one form, but maybe the '#' isn't required, maybe PR would work instead of "pull request", etc.

        Show
        Steve Rowe added a comment - I would suggest a convention of "github pull req #xxx" may help clarify longer term. I don't think we should make this complicated without good reason. We should use consistent naming in CHANGES.txt and in commit messages like we do today, and it should also be recognized by github so the contributor knows we actually committed the thing. Adding the word "github" is complicated? Um, I don't think so. However, since "pull request" is AFAICT synonymous in the current context with "github pull request", and this is likely IMHO to be the case for years, we should not require committers to include "github" in CHANGES.txt entries to get pull request references linked to github pull requests. Does Github describe their commit message pull request reference syntax anywhere? I did lots of searching and couldn't find it (I only found stuff about how to refer to/close issues from commit messages). Apparently case-insensitive "pull request # <num>" is one form, but maybe the '#' isn't required, maybe PR would work instead of "pull request", etc.
        Hide
        Hoss Man added a comment -

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

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

        commit message: pull request #123 - Add a HupperDuperMergeDestroyer
        + * New HupperDuperMergeDestroyer class for destroying merges
        +   (Sally Contributor via Suzy Committer - pull req #123)
        
        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)
        
        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)
        

        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.

        Show
        Hoss Man added a comment - 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... commit message: pull request #123 - Add a HupperDuperMergeDestroyer + * New HupperDuperMergeDestroyer class for destroying merges + (Sally Contributor via Suzy Committer - pull req #123) 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) 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) 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.
        Hide
        Steve Rowe added a comment -

        patch to autolinkify text of the form "[ github | gh ] pull request [ # ] \d+" to the corresponding github pull request

        Show
        Steve Rowe added a comment - patch to autolinkify text of the form "[ github | gh ] pull request [ # ] \d+" to the corresponding github pull request
        Hide
        Robert Muir added a comment -

        I'm not adamant about any particular way, i just want it to be relatively consistent and simple.

        Unfortunately, it looks like the commit messages in practice need to be different from the CHANGES entry anyway to close the request

        Show
        Robert Muir added a comment - I'm not adamant about any particular way, i just want it to be relatively consistent and simple. Unfortunately, it looks like the commit messages in practice need to be different from the CHANGES entry anyway to close the request
        Hide
        Robert Muir added a comment -

        +1 for this patch: I tested it with trunk today (we have 2 CHANGES entries, though they are formatted differently and we should fix that to be consistent: but the patch worked with both).

        Show
        Robert Muir added a comment - +1 for this patch: I tested it with trunk today (we have 2 CHANGES entries, though they are formatted differently and we should fix that to be consistent: but the patch worked with both).
        Hide
        ASF subversion and git services added a comment -

        Commit 1555927 from Robert Muir in branch 'dev/trunk'
        [ https://svn.apache.org/r1555927 ]

        SOLR-2794: make formatting consistent (see hoss note in LUCENE-5383)

        Show
        ASF subversion and git services added a comment - Commit 1555927 from Robert Muir in branch 'dev/trunk' [ https://svn.apache.org/r1555927 ] SOLR-2794 : make formatting consistent (see hoss note in LUCENE-5383 )
        Hide
        ASF subversion and git services added a comment -

        Commit 1555928 from Robert Muir in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1555928 ]

        SOLR-2794: make formatting consistent (see hoss note in LUCENE-5383)

        Show
        ASF subversion and git services added a comment - Commit 1555928 from Robert Muir in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1555928 ] SOLR-2794 : make formatting consistent (see hoss note in LUCENE-5383 )
        Hide
        Stefan Matheis (steffkes) added a comment -

        I'm a bit late to the party .. just to mention it: github accepts GH-xxx as well as #xxx (see http://stackoverflow.com/a/6742691) - perhaps that's a bit "easier" since we are used to SOLR-xxx and LUCENE-xxx and for others (whoever) the notation might be a bit more obvious?

        Show
        Stefan Matheis (steffkes) added a comment - I'm a bit late to the party .. just to mention it: github accepts GH-xxx as well as #xxx (see http://stackoverflow.com/a/6742691 ) - perhaps that's a bit "easier" since we are used to SOLR-xxx and LUCENE-xxx and for others (whoever) the notation might be a bit more obvious?
        Hide
        Steve Rowe added a comment -

        github accepts GH-xxx as well as #xxx (see http://stackoverflow.com/a/6742691)

        +1, though the Github blog linked to from that SO post - https://github.com/blog/411-github-issue-tracker - only talks about the issue tracker, not pull requests. This fuzziness (allowing pull requests to work the same as issues) seems intentional, AFAICT, so it's likely that "closes GH-12" will close pull request #12.

        I'll modify the patch to recognize GH-xxx too.

        Show
        Steve Rowe added a comment - github accepts GH-xxx as well as #xxx (see http://stackoverflow.com/a/6742691 ) +1, though the Github blog linked to from that SO post - https://github.com/blog/411-github-issue-tracker - only talks about the issue tracker, not pull requests. This fuzziness (allowing pull requests to work the same as issues) seems intentional, AFAICT, so it's likely that "closes GH-12" will close pull request #12. I'll modify the patch to recognize GH-xxx too.
        Hide
        Steve Rowe added a comment -

        patch adding "gh-XXX" as a recognized pull request reference.

        Committing shortly.

        Show
        Steve Rowe added a comment - patch adding "gh-XXX" as a recognized pull request reference. Committing shortly.
        Hide
        Steve Rowe added a comment -

        Same patch, this time without the random CHANGES.txt test strings

        Show
        Steve Rowe added a comment - Same patch, this time without the random CHANGES.txt test strings
        Hide
        ASF subversion and git services added a comment -

        Commit 1555998 from Steve Rowe in branch 'dev/trunk'
        [ https://svn.apache.org/r1555998 ]

        LUCENE-5383: fix changes2html to link pull requests

        Show
        ASF subversion and git services added a comment - Commit 1555998 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1555998 ] LUCENE-5383 : fix changes2html to link pull requests
        Hide
        ASF subversion and git services added a comment -

        Commit 1556009 from Steve Rowe in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1556009 ]

        LUCENE-5383: fix changes2html to link pull requests (merged trunk r1555998)

        Show
        ASF subversion and git services added a comment - Commit 1556009 from Steve Rowe in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1556009 ] LUCENE-5383 : fix changes2html to link pull requests (merged trunk r1555998)
        Hide
        Steve Rowe added a comment -

        Committed to trunk and branch_4x.

        Show
        Steve Rowe added a comment - Committed to trunk and branch_4x.

          People

          • Assignee:
            Steve Rowe
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development