On 6 February 2017 at 18:10, Andrew Stitcher <[email protected]> wrote: > On Mon, 2017-02-06 at 17:28 +0000, Robbie Gemmell wrote: >> On 6 February 2017 at 17:14, Andrew Stitcher <[email protected]> >> wrote: >> > On Mon, 2017-02-06 at 17:11 +0000, Robbie Gemmell wrote: >> > > This should have its own JIRA given PROTON-1344 was already >> > > released >> > > in 0.16.0 several weeks ago (and this also missed 0.17.0 too) >> > >> > TBH it's such a small change that I'd have used NO-JIRA except that >> > there was an obvious piece of work associated with it. >> > >> > Andrew >> > >> >> Related JIRA is certainly better than NO-JIRA, though that would >> still >> preferably be in the same release as the original change, so I'd >> likely have called use of that out too in this case. If its a trivial >> change its likely a trivial JIRA too. >> >> Its nice to know whats in a given release, e.g I'm already thinking >> of >> 0.17.1. Maybe this would be worth being in that...but on the other >> hand, if its not important enough to even warrant a JIRA, maybe not. > > It's mostly useful for debugging purposes more than anything else (and > isn't exactly a bug per se), so I'd probably not bother with 0.17.1. > > [and now we've written almost 10x the lines of the actual change!] >
Indeed, it might have been quicker just to raise a JIRA after all, as well as better for folks looking to see what is in a given release and why. I see another commit just went in for the same closed JIRA, along with a few more with no JIRA. When two thirds of the code changes pushed at the same time don't have a JIRA for the next release, it doesn't seem quite how things should be. Either a change is related to the other commits that did have a JIRA, in which case use them, or they aren't and then almost all of the time should have their own JIRA. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
