Thanks for the summing up, Stamatis. That helps a lot, and I am convinced by the advantages.
Also, I've re-checked the original definition[1] of the status flags CLOSED, RESOLVED, etc. Following is what "RESOLVED" is for: > RESOLVED: The issue is considered finished, the resolution is correct. Issues > which are not closed can be reopened. It seems that marking an issue as "RESOLVED" implies we have anyway provided a resolution, no matter whether "Fixed" the resolution is, so using a "RESOLVED" at first looks to be reasonable to me now. Originally I wanted to debate on this because I see we (including myself ;) ) used a lot of "CLOSED"s[2] in similar cases these days, after finishing release of version 1.19. I can see the motivation of closing them directly, say, a JIRA contributor was pretty confident with the conclusion that the bug is invalid/duplicated/etc., so that the issue is no need to be reopened anymore. Should we still need RM to do a double-check in cases like this? Besides, I also found some issues[3] that are created for quite a long time and marked as RESOLVED but never CLOSED. I prefer to go through and try closing them somehow after we finish this discussion. Also I found we both have status "RESOLVED" and resolution "Resolved". Are we able to remove the latter? That's pretty confusing. And +1 to not having the "next" fixing version. I am not sure if we can remove the flag from JIRA console, but I see we already locked some of "status" flags such as "ACCEPTED", "REVIEWABLE", etc.. Hongze [1] https://issues.apache.org/jira/ShowConstantsHelp.jspa [2] https://issues.apache.org/jira/browse/CALCITE-2821?jql=project%20%3D%20CALCITE%20AND%20status%20%3D%20Closed%20AND%20resolution%20in%20(Unresolved%2C%20%22Won%27t%20Fix%22%2C%20Duplicate%2C%20Invalid%2C%20Incomplete%2C%20%22Cannot%20Reproduce%22%2C%20Later%2C%20%22Not%20A%20Problem%22%2C%20Implemented%2C%20Done%2C%20%22Auto%20Closed%22%2C%20%22Pending%20Closed%22%2C%20REMIND%2C%20Resolved%2C%20%22Not%20A%20Bug%22%2C%20Workaround%2C%20Staged%2C%20Delivered%2C%20%22Information%20Provided%22%2C%20%22Works%20for%20Me%22%2C%20%22Feedback%20Received%22%2C%20%22Won%27t%20Do%22)%20ORDER%20BY%20created%20DESC%2C%20priority%20ASC%2C%20updated%20DESC [3] https://issues.apache.org/jira/browse/CALCITE-1209?jql=project%20%3D%20CALCITE%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20created%20ASC%2C%20priority%20ASC%2C%20updated%20DESC > On Apr 27, 2019, at 02:13, Stamatis Zampetakis <zabe...@gmail.com> wrote: > > 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 >>
