cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Syed Ahmed <sah...@cloudops.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Tue, 13 Mar 2018 14:11:42 GMT
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