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

Reply via email to