ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: [DISUCSS] Ticket filing process
Date Wed, 08 Nov 2017 05:32:38 GMT

What is the problem you are trying to solve? I am not sure I understand.
You cannot force maintainers to do a review. And you cannot force release
manager to do this either. Because this role is only about following
mandatory ASF steps to make release happen, nothing more.

ср, 8 нояб. 2017 г. в 3:28, Dmitriy Setrakyan <dsetrakyan@apache.org>:

> On Wed, Nov 8, 2017 at 8:08 AM, Denis Magda <dmagda@apache.org> wrote:
> > > However, if the release version was assigned properly, the
> > > release manager or component owners would have no choice but to do the
> > > review.
> >
> > There is actually an alternative the release managers tend to follow.
> They
> > simply move all the unresolved tickets to the next version blindly. This
> > happens around a release day and I get a dozen of JIRA notifications
> saying
> > that a ticket assigned to version X was rescheduled to version Y.
> >
> I do not believe this happens "blindly". These tickets get looked at before
> they get reassigned. Some of them get closed as duplicates, others are
> closed because they are not an issue anymore, others get reassigned to the
> next release. It is still better than what we have right now.
> However, even if you are right, and the tickets are not looked at, we are
> exactly at the same place we are today, when tickets just get ignored
> altogether, so no harm done.
> >
> > Anyway, we cannot force a single contributor such as the release manager
> > to be responsible for this. This should be a collaborative process
> > established between Ignite committers.
> >
> I keep hearing the word "process", but so far I have not seen anything
> workable proposed.
> > However, regardless of the chosen process those who are going to asses
> new
> > tickets have to look them up first. And here is a rule of “setting a
> ticket
> > to the latest version” might be one of the best options.
> >
> Exactly, it is the best of the worst options, and there is no better
> alternative so far. My suggestion would be to start assigning the next
> release version to all the tickets until the community comes up with a
> better process.
> D.

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