On Thu, Nov 9, 2017 at 11:10 PM, Vladimir Ozerov
wrote:
> Ok, I see. Then the question is when to do a review?
>
Whenever, the sooner the better. This we cannot enforce. But since the
tickets will have the upcoming release version, the review will have to
happen before the release. Makes sense?
Ok, I see. Then the question is when to do a review?
On Wed, Nov 8, 2017 at 9:19 AM, Dmitriy Setrakyan
wrote:
> On Wed, Nov 8, 2017 at 1:32 PM, Vladimir Ozerov
> wrote:
>
> > Dima,
> >
> > What is the problem you are trying to solve? I am not sure I understand.
> > You cannot force maintainers
On Wed, Nov 8, 2017 at 1:32 PM, Vladimir Ozerov
wrote:
> Dima,
>
> 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
> mandator
Dima,
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
On Wed, Nov 8, 2017 at 8:08 AM, Denis Magda 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
> 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
happ
On Wed, Nov 8, 2017 at 6:06 AM, Vladimir Ozerov
wrote:
> Dima,
>
> As I already mentioned, the whole community more or less followed this
> process for years already with no success. My suggestion is to ask
> component maintainers to perform regular review of relevant tickets.
>
Your suggestion
Dima,
As I already mentioned, the whole community more or less followed this
process for years already with no success. My suggestion is to ask
component maintainers to perform regular review of relevant tickets.
On Wed, Nov 8, 2017 at 12:15 AM, Dmitriy Setrakyan
wrote:
> On Tue, Nov 7, 2017 at
On Tue, Nov 7, 2017 at 7:16 PM, Vladimir Ozerov
wrote:
> Dima,
>
> When ticket is assigned to a version and doesn't guarantee that anyone will
> look at it either. When it is time to release we usually have hundreds of
> unresolved tickets on current version and it doesn't help us anyhow.
Why i
Dima,
When ticket is assigned to a version and doesn't guarantee that anyone will
look at it either. When it is time to release we usually have hundreds of
unresolved tickets on current version and it doesn't help us anyhow. This
is community, so there is little to no instruments for direct ticket
Vladimir,
In that case can you suggest a better process. I currently have a high
confidence that unless I assign the next release version to a ticket, it
will never be looked at. How do we fix it?
D.
On Wed, Nov 1, 2017 at 11:32 PM, Vladimir Ozerov
wrote:
> -1
>
> Ideally ticket should have a
-1
Ideally ticket should have a version only if we understand that it should
go to certain release. All other tickets should not have versions, because
otherwise it is hard to see the scope of the next release, and we woulld
need to move dozens of tickets from version to version constantly.
On Th
Igniters,
Currently, most new Jira tickets do not get reviewed and often get lost
unless some user complains about it.
In my view, the community must review all recently filed ticket and make
sure that we address most critical or most useful ones. Often an issue is
not critical from correctness s
13 matches
Mail list logo