> "I'm less sure about requiring that the fix version is not set before > resolving the issue" Yeah, this aspect I don't think is particularly > important either way. We can establish a preference to leave blank until > release time, but say Blocker issues are a good exception.
> It'd be nice to have internal dev docs for us to write these down in so we > can refer to them, particularly to share with new committers as well. Were > you planning to do this Jan? If we can avoid adding another Jira field that would be best. Jira is complex enough as is. PS: One day I think I'll start a vote to move to GitHub issues for the entire project :) > It'd be nice to have internal dev docs for us to write these down in so we > can refer to them, particularly to share with new committers as well. Were > you planning to do this Jan? Exactly. I just revived the email thread "Lucene/Solr Developer content" to try to get such dev docs started. Part of that new DevGuide should probably be a Project Policies chapter such as Git branch policy, Jira FixVersion policy, commit policy (CTR) etc > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Wed, Jun 19, 2019 at 12:22 PM Mark Miller <[email protected] > <mailto:[email protected]>> wrote: > Can we address this in JIRA? In the past I've seen this handled in JIRA by > also having a 'target' version field - this is the intended version you want > to land in and you set it right away. Things were configured so you could > only set the fix version when you resolved I think. Then you would use target > for release blockers and such. Fix would just tell you what it's actually in. > > On Mon, Jun 17, 2019 at 4:49 AM Adrien Grand <[email protected] > <mailto:[email protected]>> wrote: > +1 to Jan's proposal about not adding master when changes are also pushed to > the previous major, I like the additional consistency with our CHANGES.txt. > > I'm less sure about requiring that the fix version is not set before > resolving the issue, I have used this in combination with the blocker label > to mean that an issue needs to be addressed before releasing, sometimes it > will be the next minor, sometimes the next major. For the record, the > ReleaseTodo[1] recommends to check for blockers by filtering by priority and > fixVersion. > > [1] https://wiki.apache.org/lucene-java/ReleaseTodo > <https://wiki.apache.org/lucene-java/ReleaseTodo> > On Fri, Jun 14, 2019 at 11:30 PM Gus Heck <[email protected] > <mailto:[email protected]>> wrote: > FWIW I tend to agree with Erick here on both his points, but the second one > more strongly than the first. The first I can live with either way really so > long as it's clearly documented somewhere (besides this thread). > > If we don't update the changes in master for bug fixes when we're committing, > who's going to go collect and add them later? I'm not sure I'm that big a fan > of generating changes... I haven't looked at Yetus specifically but I suspect > that this will just leave us with the title from the Jira, and often some > additional detail for changes is worthwhile beyond what the title says. So if > we create a field in Jira that is the Changes text, and make it required in > the resolution screen fine to generate from that, but I think there's real > value in the current system because you wind up writing a final short 1-4 > line summary focused on "what the user needs to know" > > Also line 3, the feature only in 8x (but not master) is a very odd case in > that table, I'm not sure when that would happen? could happen for a bug that > is fixed by other changes in master, but for a feature? > > Also if we aren't marking branches explicitly maybe the 9.0 (master) tag > should say 9.0 (unreleased)? Sure most developers know master is typically > unreleased, but why add that mental leap. It's possible that someone less > technical, or who is a student will stumble in from a link on SO... > > -Gus > > On Thu, Jun 13, 2019 at 3:23 PM David Smiley <[email protected] > <mailto:[email protected]>> wrote: > +1 to your plan Jan. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Thu, Jun 13, 2019 at 8:40 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Trying to reach a conclusion (or perhaps a vote) on this. > > Here is a table that sums up my proposal. Basically it means in most cases > stop adding master as fixVersion. > > Type Committed to fixVersion CHANGES.txt section > Feature master master (9.0) 9.0 > Feature master, branch_8x 8.2 8.2 > Feature branch_8x 8.2 8.2 > Bugfix master master (9.0) none (unreleased bug) > Bugfix master, branch_8x 8.2 8.2 > Bugfix master, branch_8x, branch_8_1 8.1.2, 8.2 8.1.2, 8.2 > Bugfix branch_8x 8.2 8.2 > Bugfix branch_8_1 8.1.2 8.1.2 > Bugfix branch_8x, branch_7_7 7.7.3, 8.2 7.7.3, 8.2 > > In addition to this, we should all wait until commit time with setting > fixVersion. > > To find branches for a JIRA, you just translate fixVersion to branch, e.g. > 8.1.2, 8.2 -> branch_8_1, branch_8x. > For features, if it is unclear whether master has the commit, check gitbot > log or git log > For bugfixes, there are cases where the bug does not exist in master at all, > and that can be reflected in affectsVersion field. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > >> 3. jun. 2019 kl. 19:56 skrev David Smiley <[email protected] >> <mailto:[email protected]>>: >> >> Right.... JIRA fixVersion has its use, and that would satisfy this use-case? >> It's what Jan proposes to do this very thing as part of generating release >> notes in a semi-automated way. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> <http://www.linkedin.com/in/davidwsmiley> >> >> On Mon, Jun 3, 2019 at 11:38 AM Erick Erickson <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> > On Jun 3, 2019, at 6:41 AM, David Smiley <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > If someone wants to know what branches an issue was committed to, then >> > review the bot comments to find out. >> >> What if I want to form a query that shows me all JIRAs fixed in version >> X.Y.Z? >> >> A bot comments with “branch_5x” doesn’t tell me which minor version it’s in, >> 5.1? 5.5? >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> <mailto:[email protected]> >> For additional commands, e-mail: [email protected] >> <mailto:[email protected]> >> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play) > > > -- > Adrien > > > -- > - Mark > > http://about.me/markrmiller <http://about.me/markrmiller>
