I think we should first define and document what we are considering a minor or trivial change, I am +1 on relaxing the requirement of a Jira ticket for those
________________________________ From: Daan Hoogland <daan.hoogl...@gmail.com> Sent: Wednesday, March 14, 2018 7:05:04 AM To: dev Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs Let me add to the below that I do think a ticketing system is a big help for keeping track of *un*implemented changes and *un*fixed bugs. On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > Boris, I hate to be strongly opinionated but I have to violently disagree > with you on some things here; > > On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov < > boris.stoya...@shapeblue.com> wrote: > >> Hi all, >> >> I do understand your point as developers if you want to fix something >> just open the PR and not deal with any extra details like JIRA tickets and >> etc, but I must say that JIRA tickets are quite often looked up from users >> as they experience an issue. > > It is not more or less effort for users to look up github PRs than Jira > tickets. They still need to be clever about search terms and still might > miss out. > > > >> Let’s say we’ve fixed an annoying UI bug in master and there’s no ticket >> for it in JIRA. As a user, if you try to search for this particular issue >> where would you go? In JIRA or GitHub? How would you know which release to >> pickup if you’re just an infrastructure guy and not following Github. >> > What is following here and why not Github but Jira. > > > >> >> Tracking every change with such tool is proven good practice in SDLC, > > No it is not. Absolutely not. That is what we have revision control > systems for. Your good practice is only true for enterprise controlled > projects. In cloudstack there are a lot of wild forks because this > enterprisy way of controlling change has pushed people away from > mainstream. This is a force to be reckoned with and we can not completely > ban it, but we have to minimise it if we want to survive as project. > > > >> it brings visibility and it’s a tool meant to be used not only from >> developers, but from everyone involved in the project. >> > How is this true for Jira anywhere near as much as it is true for github? > > > >> >> I also got the feeling that lacking a JIRA ticket could become a common >> practice in community submission and it’s yet another reason for me to be >> -1 on this. > > Another reason to be very much +1 on it. That is a good thing. Think > about it. People submistting features and bugfixes instead of asking for > them in a ticket. That is great. > > > >> Also I don’t think it’s causing big overhead, since it’s being updated >> mostly automatically. >> > No it is not. What is done automatically? put in progress?? closing? > undertest status? Only noise is added to those tickets automatically. > > > >> >> Boris Stoyanov >> >> >> boris.stoya...@shapeblue.com >> www.shapeblue.com<http://www.shapeblue.com> >> 53 Chandos Place, Covent Garden, London WC2N 4HSUK >> @shapeblue >> >> >> >> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com> >> wrote: >> > >> > I'm completely +1 on using GH as source of truth, both PR and issue >> wise, >> > with Daan comment regarding Apache rules in mind. >> > At least it doesn't need to have "yet another" integration to do >> automated >> > actions on an issue (such as auto close an issue by "Fixes NUMBER", >> > "Closes NUMBER") directly from commit or PR body. >> > >> > Khosrow Moossavi >> > CloudOps >> > >> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sah...@cloudops.com> >> wrote: >> > >> >> I agree with the relaxation as Rohit pointed out. At this point we >> should >> >> ask if Jira is really needed. Most people here I believe agree that it >> is >> >> not. The only reason we have Jira is to track releases. This could >> easily >> >> be replicated in GitHub as I see that GitHub is the place where we all >> >> collaborate. I would be completely in if we use GitHub issues and like >> it >> >> with Jira as we do with our PRs. >> >> >> >> >> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner < >> >> rafaelweingart...@gmail.com> wrote: >> >> >> >>> I was checking and for some reason ACS does not have an issue tab ( >> >>> https://github.com/apache/cloudstack/issues). It might be some >> >>> configuration in the repository. >> >>> >> >>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner < >> >>> rafaelweingart...@gmail.com> wrote: >> >>> >> >>>> What do you mean by issue? PR or issue (Github issue)? >> >>>> >> >>>> On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland < >> >> daan.hoogl...@gmail.com >> >>>> >> >>>> wrote: >> >>>> >> >>>>> right, also when an issue is created? >> >>>>> >> >>>>> >> >>>>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner < >> >>>>> rafaelweingart...@gmail.com> wrote: >> >>>>> >> >>>>>> We already have. All messages on ACS' GH go to commits@c.a.o >> >>>>>> >> >>>>>> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland < >> >>>>> daan.hoogl...@gmail.com> >> >>>>>> wrote: >> >>>>>> >> >>>>>>> Ok, one issue there is Apache foundation rules. If we copy every >> >>> thing >> >>>>>> into >> >>>>>>> jira or the mail list we are fine, where ever we have our >> >>> discussions. >> >>>>>> The >> >>>>>>> only thing is that we need a Apache hosted record. (as in not >> >>> github) >> >>>>>>> >> >>>>>>> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner < >> >>>>>>> rafaelweingart...@gmail.com> wrote: >> >>>>>>> >> >>>>>>>> I prefer the workflow in Github as you guy, but to be fair with >> >>> Jira >> >>>>>>> ticket >> >>>>>>>> system I mentioned it. >> >>>>>>>> >> >>>>>>>> @Marc, yes Jira can facilitate a lot the management. However, we >> >>> do >> >>>>> not >> >>>>>>> use >> >>>>>>>> it fully. In our workflow, there is no planning/roadmap for the >> >>> next >> >>>>>>>> release per se. Things seem to work in an ad-hoc fashion. On the >> >>>>> other >> >>>>>>>> hand, when you need to break down milestones into >> >>>>> issues/tickets/tasks >> >>>>>>> and >> >>>>>>>> then divide them into sprints, and manage a team of developers, >> >>> the >> >>>>>>>> oversight provided by Jira system is very good; specially, when >> >>>>> issues >> >>>>>>>> start to take more than a single sprint to finish. >> >>>>>>>> >> >>>>>>>> On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier < >> >>>>>> ma...@exoscale.ch >> >>>>>>>> >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> @rafael, you said: they all required Jira tickets to track the >> >>>>>>> discussion >> >>>>>>>>> and facilitate the management >> >>>>>>>>> >> >>>>>>>>> I can see the discussion happening in the PR on github, but >> >> the >> >>>>> Jira >> >>>>>>>> ticket >> >>>>>>>>> by itself doesn't do much, except copy/pasting the github >> >>>>> discussion. >> >>>>>>>> Then >> >>>>>>>>> it's down to "facilitate the management", which I only see as >> >>>>> listing >> >>>>>>> the >> >>>>>>>>> changes for a release as far as I know. But this can be >> >> achieved >> >>>>> on >> >>>>>>>> github >> >>>>>>>>> too. >> >>>>>>>>> >> >>>>>>>>> As Daan mentioned, there are those things that are not code >> >>>>> related >> >>>>>>> which >> >>>>>>>>> should have a way of tracking. But what's the difference in >> >>>>> tracking >> >>>>>>> them >> >>>>>>>>> as a Jira issue vs a Github issue (they can't be a PR)? Those >> >>> are >> >>>>>> point >> >>>>>>>> of >> >>>>>>>>> view exchanges with messages & links, with a final status, >> >> most >> >>> of >> >>>>>> the >> >>>>>>>> time >> >>>>>>>>> without a strong link to a release number. If they do, they >> >> can >> >>> be >> >>>>>>> added >> >>>>>>>> to >> >>>>>>>>> a milestone. >> >>>>>>>>> >> >>>>>>>>> So far I don't see how things done with Jira cannot be >> >> achieved >> >>> on >> >>>>>>>> Github. >> >>>>>>>>> It's just a matter of changing habits to simplify the workflow >> >>> for >> >>>>>> new >> >>>>>>>>> comers (and old joiners too ;-) ). >> >>>>>>>>> >> >>>>>>>>> On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland < >> >>>>>>> daan.hoogl...@gmail.com> >> >>>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> Will, you are speaking my mind; any external registration >> >> tool >> >>>>>> should >> >>>>>>>> be >> >>>>>>>>>> based on the source. The only reason for having an external >> >>> tool >> >>>>>>>> without >> >>>>>>>>>> relation to the code is to keep track of what is *not* (or >> >> not >> >>>>>> fully) >> >>>>>>>>>> implemented. >> >>>>>>>>>> >> >>>>>>>>>> On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner < >> >>>>>>>>>> rafaelweingart...@gmail.com> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> I meant a way of describing them (changes/proposals) >> >>> further. >> >>>>>>>> Sometimes >> >>>>>>>>>> we >> >>>>>>>>>>> have commits only with title, and then the Jira ticket >> >> would >> >>>>> be a >> >>>>>>> way >> >>>>>>>>> of >> >>>>>>>>>>> documenting that commit. I do prefer the idea of inserting >> >>> the >> >>>>>>> whole >> >>>>>>>>>>> description in the commit body though. [for me] it looks >> >>>>> easier >> >>>>>> to >> >>>>>>>> work >> >>>>>>>>>>> directly with commits and PRs; as you said, we can >> >> generate >> >>>>>> release >> >>>>>>>>> notes >> >>>>>>>>>>> based on commits directly [and issues on GH]. However, for >> >>>>> that, >> >>>>>> we >> >>>>>>>>> need >> >>>>>>>>>> to >> >>>>>>>>>>> fine-tune our workflow. >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens < >> >>>>>>> wstev...@cloudops.com >> >>>>>>>>> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> I am +1 to relaxing the requirement of Jira ticket. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Rafael, what do you mean when you say "Jira tickets are >> >>>>> used to >> >>>>>>>>>> register >> >>>>>>>>>>>> changes"? >> >>>>>>>>>>>> >> >>>>>>>>>>>> I think ever since 4.9 the actual PRs included in the >> >> code >> >>>>> are >> >>>>>>> the >> >>>>>>>>>> source >> >>>>>>>>>>>> of truth for the changes in the actual code (at least >> >>> from a >> >>>>>>>> release >> >>>>>>>>>>> notes >> >>>>>>>>>>>> perspective). This is why the release notes can show >> >>>>> changes >> >>>>>>> that >> >>>>>>>>> only >> >>>>>>>>>>>> have PRs and no Jira ticket. At least my release notes >> >>>>>> generator >> >>>>>>>> is >> >>>>>>>>>>> built >> >>>>>>>>>>>> that way. I think Rohit has built a similar release >> >> notes >> >>>>>>>> generator, >> >>>>>>>>>> so >> >>>>>>>>>>> I >> >>>>>>>>>>>> can't speak to his version... >> >>>>>>>>>>>> >> >>>>>>>>>>>> *Will Stevens* >> >>>>>>>>>>>> Chief Technology Officer >> >>>>>>>>>>>> c 514.826.0190 >> >>>>>>>>>>>> >> >>>>>>>>>>>> <https://goo.gl/NYZ8KK> >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner < >> >>>>>>>>>>>> rafaelweingart...@gmail.com> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> Marc, yes Jira tickets are used to register changes. >> >>>>> However, >> >>>>>>>> what >> >>>>>>>>>>> Rohit >> >>>>>>>>>>>>> and others (including me) are noticing is that there >> >> are >> >>>>>>> certain >> >>>>>>>>>> types >> >>>>>>>>>>> of >> >>>>>>>>>>>>> changes (minor/bureaucracy) that do not require Jira >> >>>>> tickets. >> >>>>>>> The >> >>>>>>>>>> issue >> >>>>>>>>>>>> is >> >>>>>>>>>>>>> the wording “change”. What consist of a change that is >> >>>>> worth >> >>>>>>>>>> mentioning >> >>>>>>>>>>>> in >> >>>>>>>>>>>>> the release notes? Everything we do in a branch is a >> >>>>> change >> >>>>>>>>> towards a >> >>>>>>>>>>>>> release, but not everything is useful for >> >>>>>>>> operators/administrators >> >>>>>>>>> to >> >>>>>>>>>>>> see. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I would say that to fix bugs, introduce new features, >> >>>>> extend >> >>>>>>>>> existing >> >>>>>>>>>>>>> features, introduce a major change in the code such as >> >>>>> that >> >>>>>>>>> standard >> >>>>>>>>>>>> maven >> >>>>>>>>>>>>> thing that you did, they all required Jira tickets to >> >>>>> track >> >>>>>> the >> >>>>>>>>>>>> discussion >> >>>>>>>>>>>>> and facilitate the management. On the other side of >> >> the >> >>>>>>> spectrum, >> >>>>>>>>> we >> >>>>>>>>>>> have >> >>>>>>>>>>>>> things such as removing dead/unused code, opening a >> >> new >> >>>>>> version >> >>>>>>>>>>> (creating >> >>>>>>>>>>>>> the upgrade path that we still use for the DB), fix a >> >>>>>>> description >> >>>>>>>>> in >> >>>>>>>>>> an >> >>>>>>>>>>>> API >> >>>>>>>>>>>>> method, and so on. Moreover, the excessive use of Jira >> >>>>>> tickets >> >>>>>>>>> leads >> >>>>>>>>>> to >> >>>>>>>>>>>>> hundreds of Jira tickets that we do not know that >> >> status >> >>>>> of. >> >>>>>> We >> >>>>>>>>> have >> >>>>>>>>>>>> quite >> >>>>>>>>>>>>> a big number of tickets opened that could be closed. >> >>> This >> >>>>> has >> >>>>>>>> been >> >>>>>>>>>>> worse; >> >>>>>>>>>>>>> we are improving as time goes by. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> I would say that to make this more transparent to >> >> others >> >>>>>>>>> (especially >> >>>>>>>>>>>>> newcomers), we need to discuss it, then write it down >> >> to >> >>>>> make >> >>>>>>> it >> >>>>>>>>>>>>> transparent the way we are working. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier >> >> < >> >>>>>>>>>>> ma...@exoscale.ch >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> That's a good idea, because people are more and more >> >>>>> used >> >>>>>> to >> >>>>>>>> only >> >>>>>>>>>>>> create >> >>>>>>>>>>>>> PR >> >>>>>>>>>>>>>> on github, and it would be helpful to be more >> >>>>> explanatory >> >>>>>> on >> >>>>>>>> the >> >>>>>>>>>> way >> >>>>>>>>>>> we >> >>>>>>>>>>>>>> work to push changes. I still think we should >> >>> encourage >> >>>>> the >> >>>>>>> use >> >>>>>>>>> of >> >>>>>>>>>>> the >> >>>>>>>>>>>>>> github milestone as Rohit did with the 4.11.0 ( >> >>>>>>>>>>>>>> https://github.com/apache/clou >> >>>>> dstack/milestone/3?closed=1) >> >>>>>>> to >> >>>>>>>>> list >> >>>>>>>>>>> the >> >>>>>>>>>>>>>> changes in the release notes with the help of the >> >>>>> labels to >> >>>>>>> tag >> >>>>>>>>> the >> >>>>>>>>>>> PRs >> >>>>>>>>>>>>>> instead of relying on the jira ticket (it requires >> >> to >> >>>>> have >> >>>>>>>>> another >> >>>>>>>>>>>>> login). >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> As far as I can remember, the JIRA tickets are used >> >> to >> >>>>> list >> >>>>>>> the >> >>>>>>>>>>> changes >> >>>>>>>>>>>>> of >> >>>>>>>>>>>>>> a release, but nothing else. Or am I missing >> >>> something? >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Marc-Aurèle >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav < >> >>>>>>>>>>>> rohit.ya...@shapeblue.com> >> >>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> All, >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> To make it easier for people to contribute changes >> >>> and >> >>>>>>>>> encourage >> >>>>>>>>>>>>>>> PR/contributions, should we relax the requirement >> >>> of a >> >>>>>> JIRA >> >>>>>>>>>> ticket >> >>>>>>>>>>>> for >> >>>>>>>>>>>>>> pull >> >>>>>>>>>>>>>>> requests that solve trivial/minor issues such as >> >> doc >> >>>>>> bugs, >> >>>>>>>>> build >> >>>>>>>>>>>> fixes >> >>>>>>>>>>>>>> etc? >> >>>>>>>>>>>>>>> A JIRA ticket may still be necessary for new >> >>> features >> >>>>> and >> >>>>>>>>>>> non-trivial >> >>>>>>>>>>>>>>> bugfixes or changes. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Another alternative could be to introduce a >> >>>>>> CONTRIBUTING.md >> >>>>>>>> [1] >> >>>>>>>>>>> that >> >>>>>>>>>>>>>>> explains the list of expected things to >> >> contributors >> >>>>> when >> >>>>>>>> they >> >>>>>>>>>>> send a >> >>>>>>>>>>>>> PR >> >>>>>>>>>>>>>>> (for example, a jira id, links to fs or other >> >>>>> resources, >> >>>>>> a >> >>>>>>>>> short >> >>>>>>>>>>>>> summary >> >>>>>>>>>>>>>>> and long description, test results etc). >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thoughts? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> [1] https://help.github.com/articl >> >>>>> es/setting-guidelines- >> >>>>>>>>>>>>>>> for-repository-contributors/ >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> - Rohit >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> <https://cloudstack.apache.org> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> rohit.ya...@shapeblue.com >> >>>>>>>>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> >> >>>>>>>>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N >> >> 4HSUK >> >>>>>>>>>>>>>>> @shapeblue >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> -- >> >>>>>>>>>>>>> Rafael Weingärtner >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> -- >> >>>>>>>>>>> Rafael Weingärtner >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Daan >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Rafael Weingärtner >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Daan >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Rafael Weingärtner >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Daan >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Rafael Weingärtner >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Rafael Weingärtner >> >>> >> >> >> >> > > > -- > Daan > -- Daan nicolas.vazq...@shapeblue.com www.shapeblue.com , @shapeblue