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
