Thanks everybody for the feedback. I will try to gather up everything said here and complete the website.
@Hongze Using directly closed for duplicates, won't fix, etc., is a subject to debate so I am ok with any decision we take on this. Summing up below some pros and cons. Advantages: * Simplifies the resolution of issues since only the release manager is responsible for closing them. * Decreases the possibility of errors since the release manager can verify that the resolution status assigned to the issue is correct. Disadvantages: * Adds more burden to the release manager; * Looks weird in combination with other fields such as the resolution status. @Francis The current instructions [3] mention the following " If you are committed to fixing the issue before the upcoming release set the fix version accordingly (e.g., 1.20.0), otherwise leave it as blank." which implies that "next" should never be used. We can try to make it more explicit and if possible lock its usage. [3] https://github.com/apache/calcite/blob/master/site/develop/index.md On Thu, Apr 25, 2019 at 11:56 PM Francis Chuang <francischu...@apache.org> wrote: > 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 >
