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/cloudstack/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/ > articles/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
