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 <yzhda...@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 > >
signature.asc
Description: Digital signature
