Thanks for getting this discussion started, Stamatis!
I was actually going to start some discussion regarding the "next" fix
version/release on JIRA after making Avatica 1.14.0 rc0 available for
voting, so I think this thread would be a good place to do so too.
There are currently 18 issues on JIRA with the fix version set to "next"
[1]. In my opinion this creates extra work for the release manager.
For me, I open the list of commits on Github and check that the
corresponding issue in JIRA (if any) has the correct fix version set and
has been resolved. Unfortunately, some issues were tagged as "next" and
I had to hunt those issues down individually and fix them, rather than
being able to get a list of them by visiting the avatica-1.14.0 page on
JIRA.In addition, the "next" version does not seem meaningful to me, as
we do know the version number of the next release. There also seem to be
a few pretty old issues set to "next" but have not been worked on in a
while. In my opinion, it would be better if these issues have their Fix
Version set to blank instead, as it may give the wrong impression (false
hope), that a fix is in progress.
What do you guys think? If the "next" fix version should not be used, we
should set the fix version of those issues to a proper version number or
nothing and archive the "next" release, so that it cannot be used per
these instructions [2].
Francis
[1] https://issues.apache.org/jira/projects/CALCITE/versions/12329362
[2]
https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-lock-a-version-prevent-selecting-version/qaq-p/400996
On 26/04/2019 1:10 am, Chunwei Lei wrote:
Thanks very much for this, Stamatis. It is really helpful and +1 to
add them to website.
Best,
Chunwei
Best,
Chunwei
On Thu, Apr 25, 2019 at 10:43 PM Julian Hyde <jhyde.apa...@gmail.com> wrote:
Thanks for this, Stamatis. Much needed.
I agree with Vladimir that this should end up on the site, but it is
appropriate that it starts as an email discussion, so that we can build
consensus.
A few more things.
The subject line of a jira case (and a commit) is important. Crafting it is an
art. It should imply what the end user was trying to do, in which component,
and what symptoms were seen. If it’s not clear what the desired behavior is,
rephrase: eg “Validator closes model file” to “Validator should not close model
file”. Contributors to the case should feel free to rephrase and clarify the
subject line. If you remove information while clarifying, put it in the
description of the case.
Design discussions may happen in varying places (email threads, github reviews)
but the case is the canonical place for those discussions. Link to them or
summarize them in the case.
When implementing a case, especially a new feature, make sure that the case
includes a functional specification of the change. E.g. “Add a IF NOT EXISTS
clause to the CREATE TABLE command; the command is a no-op if the table already
exists.” Update the description if the specification changes during design
discussions or implementation.
When implementing a feature or fixing a bug, endeavor to create the jira case
before you start work on the code. This gives others the opportunity to shape
the feature before you have gone too far down (what the reviewer considers to
be) the wrong path.
Julian
On Apr 25, 2019, at 6:51 AM, Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
wrote:
Stamatis> If you see things that are
Stamatis> incorrect or that need to be done differently feel free to
reply to this
Stamatis> email.
LGTM.
Stamatis, thanks for the writeup, however I'm inclined to suppose it
makes sense to put that on the website.
Such mails will be hard to find, especially for the ones who don't
know such a mail exists at all.
On the other hand, "/develop/" page is trivial to navigate even by
just browsing the website.
Vladimir
