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