cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Tue, 13 Mar 2018 15:00:13 GMT
To add another $0.02 to this conversation, beyond what I posted above.

Ideally, in my humble opinion, we would use Github Issues for issues that
do not currently have code associated with it.  Jira is currently being
used for this and it is useful for users to be able to flag bugs without
knowing how to solve them.  I believe this would require that issues be
turn on for the repo and the details of the issue be pushed to one of our
apache mailing lists.

One of the reasons why Jira has remained in play and we have not gone with
Github Issues in the past was due to security related issues.  I don't
believe we have the ability in Github to have private issues, which I
believe use use in Jira to handle security/CVE related issues.  This is
something we may have to solve for if we do leverage Github Issues, but I
will lets someone closer to how that all goes down comment and confirm or
deny this.

If we could use Github Issues and Github PRs as the only location for
issues and development, I think that would make contribution more
approachable and easier to convey to users.

Those are my additional thoughts...

*Will Stevens*
Chief Technology Officer
c 514.826.0190

<https://goo.gl/NYZ8KK>

On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sahmed@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 <
> rafaelweingartner@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 <
> > rafaelweingartner@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.hoogland@gmail.com
> > >
> > > wrote:
> > >
> > >> right, also when an issue is created?
> > >>
> > >>
> > >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > >> rafaelweingartner@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.hoogland@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 <
> > >> > > rafaelweingartner@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 <
> > >> > marco@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.hoogland@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
<
> > >> > > > > > rafaelweingartner@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
<
> > >> > > wstevens@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 <
> > >> > > > > > > > rafaelweingartner@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
> <
> > >> > > > > > > marco@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.yadav@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.yadav@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message