ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: Jira Process Change
Date Wed, 06 Jan 2016 04:06:23 GMT
On Tue, Jan 05, 2016 at 07:19AM, Dmitriy Setrakyan wrote:
> Agree. No need to just keep reassigning a whole bulk of tickets from one
> release to another.

In JIRA, open tickets are automatically got moved to the next version, once
the current one is getting "released" in JIRA, so the reassignment is done
without any human intervention normally. There's no need for any process
around it, IIRC.

I want to comment on 
> > I think a much better approach would be for the committers and
> > contributors to keep the tickets assigned to themselves between releases,
> > and whenever

That's basically how it works in the OSS projects. People are working on what
they feel like/have time for. That said, it is entirely acceptable for one to
pick-up a ticket assigned to someone else and work on it to make to the next
release. Assuming that whoever the ticket being grabbed from doesn't already
work on it, nor doesn't mind letting it go.

Release manager job isn't to assign work to ppl in the community, but to shape
up a release to its liking, essentially. And then it is up to effectively PMC
to vote it up or down. Going to the extreme: there's nothing wrong with having
more than one release coming from the same project at the same time. It is
confusing and perhaps wasteful, but quite legit for sure.

A couple notes on the page:
 - the macro to JIRA doesn't work, actually. Wiki users are different from
   JIRA ones. So it'd make sense to make an anonymous filter
 - what's the "Lead" role?

Thanks,
  Cos

> On Tue, Jan 5, 2016 at 2:23 AM, Yakov Zhdanov <yzhdanov@apache.org> wrote:
> 
> > Guys,
> >
> > Our current Jira process involves going through potentially 100s of tickets
> > and moving them from one release to another. On top of being time
> > consuming, it just seems plain redundant.
> >
> > I think a much better approach would be for the committers and contributors
> > to keep the tickets assigned to themselves between releases, and whenever
> > they feel that the feature will make a certain release, set the
> > “fixVersion” in the ticket.
> >
> > The above process would work for the majority of bug fixes. Of course we
> > would still separately monitor tickets associated with main release
> > features and schedule them properly on the Release Plan [1] page.
> >
> > Comments?
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Plan
> >
> > --Yakov
> >

Mime
View raw message