spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <sro...@gmail.com>
Subject Re: [DISCUSS] filling affected versions on JIRA issue
Date Thu, 02 Apr 2020 15:30:58 GMT
On Wed, Apr 1, 2020 at 10:28 PM Jungtaek Lim
<kabhwan.opensource@gmail.com> 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.

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

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


> 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.


> 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?

---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org


Mime
View raw message