spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jungtaek Lim <>
Subject Re: [DISCUSS] filling affected versions on JIRA issue
Date Fri, 03 Apr 2020 00:39:50 GMT
On Fri, Apr 3, 2020 at 12:31 AM Sean Owen <> wrote:

> On Wed, Apr 1, 2020 at 10:28 PM Jungtaek Lim
> <> wrote:
> > The definition of "latest version" would matter, especially there's a
> time we prepare minor+ version release.
> >
> > For example, lots of people (even including committers) filed an
> "improvement" issue with setting fix version to 3.0, which is NOT incorrect
> in point of "release", but incorrect in point of the version of "master
> branch". If we say it as "latest" version, maybe they should not even be
> set to 3.0. Looks like it still confuses someone; we need to make clear
> which version it should if we really want to require it, and should be
> documented.
> OK shall we simply say, tag it with whatever version you were using
> when you found the bug? If the reporter or anyone else knows it
> affects other versions, sure, add that. Point being, I don't think we
> should ask people to investigate which N versions it affects, unless
> it's particularly vital to the nature of the issue.

The paragraph is aimed for "new feature" / "improvement", not for "bug". I
guess we have consensus for "bug".

> For improvements, it matters less, and simply saying 'the latest
> version' is a fine default.

I meant 'the latest version' is confusing one. If someone is not tightly
involved into Spark development then they would consider the latest version
as 'the latest released version'. Even for someone who works on Spark
development it gives confusion when we cut a branch for minor+ version,
master branch goes up to (unreleased version + 1), which some of us may
think the latest version as the minor+ version we will target to release.

It would avoid the confusion if we decide the definition of 'the latest
version', and define the standard way to get 'the latest version'. and
document into contribution guide page. Otherwise we would have different
understanding and try to guide with different version, or even try to
correct others.

> Is there another desired standard out there that we're debating
> against? so far this sounds like existing practice.

Existing practice is not documented and gives confusion - 3.1.0 vs 3.0.0
for now. Though I believe leaving it empty or N/A if the field is required
should be even better.

> > Also I'm not in favor of bumping affect version in existing improvement
> issues when bumping up the minor+ version. As I said, I'm not sure we get
> some benefits from there. Even more, once batch updates are executed, lots
> of notifications happen in issue@ and these issues bump to the top in
> mail inbox, whereas technically they have no actual update. I'd rather say
> we should do opposite, don't update it to leave some context which version
> it was considered.
> What is this referring to - there are some batch updates of affected
> version? could be fine but for what reason?
> You can disable sending an email for bulk updates in JIRA, if that's the
> issue.

If you're subscribing to issue@ then you've recognized there were bulk
updates after cutting the branch for 3.0. (That's not controllable by
myself unless I unsubscribe.) I didn't do bulk update by myself - as I said
I'm not in favor of updating version.

And bulk mail update is just a side-effect and not the main issue, of
course. The main point is that the benefits/values: personally I don't see
any value from doing that. If we are on the same page then why we do that,
and if someone objects then doesn't it the thing we need to discuss?

> I'm assuming that we should require the affect version even for non-bug
> issue, but yes if possible I'd in favor of leave it empty. In any way let's
> document it explicitly.
> Agree. I think it's required in JIRA just because we can't require it
> for Bugs but not Improvements though?

There's "N/A" which could simply play as a dummy marker which would avoid
confusion at any time. I'm not expert on JIRA automation (especially ASF
JIRA) but we might be able to ask ASF INFRA to do it automatically for the
some types. Even it can't be automated, still clearer to set the version.

View raw message