Thank you very much for proposing the document changes, Stamatis. Regarding the issue status, personally I am good to try following a unified convention anyway, thank you for logging that to website also.
And I went quickly through the JIRA console page, but didn't either find an obvious way to custom the "screen"[1] of issue resolution (where the list of unreleased versions seems to be changeable). Or we can first do something manually to deal with the existing JIRA issues[2] having "Resolved" marked as resolution, and avoid using (if possible) that option in future. By the way, does the resolution "Resolved" and status "RESOLVED" mean differently? If "Resolved" does have its own use then maybe I misunderstood it. Generally it confused me more or less when I bumped into it at the first time. Thanks, Hongze [1] https://confluence.atlassian.com/adminjiraserver/defining-a-screen-938847288.html [2] https://issues.apache.org/jira/browse/CALCITE-2923?jql=project%20%3D%20CALCITE%20AND%20resolution%20%3D%20Resolved > On May 6, 2019, at 01:40, Stamatis Zampetakis <zabe...@gmail.com> wrote: > > I tried to summarize what we discussed here in the following PR: > > https://github.com/apache/calcite/pull/1196 > > I will leave it open for a few days in case we want to do some > modifications. > > @Hongze: > Thanks for cleaning up those [3] unfinished issues. > > Since nobody else expressed an opinion between closing issues directly or > marking them as resolved, I kept the second option. If the others have > another opinion we can easily change it back. As I said in the beginning, > I'm OK with both options. > > Regarding the JIRA configuration, I don't think we can do much. It seems > that field values are configured globally per JIRA instance (and not per > project) so I guess we cannot remove some values without affecting all > Apache projects. I'm not so familiar with JIRA so if somebody else knows > how to remove "Resolved" from the values of "Resolution" field (without > affecting all projects) it would be great. > > > On Sat, Apr 27, 2019 at 3:38 AM Hongze Zhang <notify...@126.com> wrote: > >> 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 >>>> >> >>
