On Wed, Jun 20, 2018 at 10:29:37PM +0200, Richard Levitte wrote: > In message <c9407418eba94248bb97172731243...@ex13.ncp.local> on Wed, 20 Jun > 2018 19:59:02 +0000, "Dr. Matthias St. Pierre" <matthias.st.pie...@ncp-e.com> > said: > > Matthias.St.Pierre> III) VERSION NUMBER LABELS > Matthias.St.Pierre> > Matthias.St.Pierre> It seems like the version number labels '1.0.2', > Matthias.St.Pierre> '1.1.0', '1.1.1', 'after 1.1.1' currently serve > Matthias.St.Pierre> two differente purposes: > Matthias.St.Pierre> > Matthias.St.Pierre> 1. Indicate the intention to which branches a pull > Matthias.St.Pierre> request will be backported > Matthias.St.Pierre> Approval holds for all labeled branches. > Matthias.St.Pierre> > Matthias.St.Pierre> 2. As surrogate milestones > > ... and the other way around, it seems silly to use a "1.0.2" > milestone, since 1.0.2 was released a long time ago. I'd argue that > all old milestones should really be removed, and only future versions > should have milestones.
I would argue that old milestones should *not* be removed! There seems to be some archival value in being able to see the contents of the milestone even after it is completed. > Matthias.St.Pierre> ad 1): > Matthias.St.Pierre> Using the version number labels as indication of merge > intention makes sense. > Matthias.St.Pierre> But then the 'master' label and (currently) the '1.1.1' > label are superfluous. > > I'd suggest keeping the 1.1.1 label, as we will have use for it. > > Matthias.St.Pierre> If the pull request targets the 'master' branch, why does > it need a 'master' label? > Matthias.St.Pierre> The github search index allows to search for > 'base:<branchname>' which is a much > Matthias.St.Pierre> more reliable way of determining the target branch: > > I'm learning something new, I had no clue of the 'base:' feature. > > However, it sometimes happens that I do a PR based on, for example, > OpenSSL_1_1_0-stable, simply because that's where the issue was found, > but with the intent to cherry pick into newer lines of development > (master, and OpenSSL_1_1_1-stable soon). That gives those labels > their potential for showing intent. > > Matthias.St.Pierre> ad 2): > Matthias.St.Pierre> The label 'after 1.1.1' is a surrogate milestone > Matthias.St.Pierre> and IMHO it would be better to use the 'Post > Matthias.St.Pierre> 1.1.1' milestone instead of the label. > > I agree with you, but this was debated during the last F2F, and ideas > differ. I don't quite remember if we came to a real decision, though. > > Matthias.St.Pierre> One could go even further and ask what sense does > Matthias.St.Pierre> it make to have such an unspecific milestone as > Matthias.St.Pierre> 'Post 1.1.1'? Wouldn't it be better to leave such > Matthias.St.Pierre> pull requests unassigned? > > No, because we need to differentiate between PRs and issues we haven't > looked at yet and those where we have made a decision where they > should go. And perhaps that's an argument to keep using the label, as > it's more visible in the pull request summary. > > Matthias.St.Pierre> IMHO it would make sense to use the version labels > Matthias.St.Pierre> only to indicate merge intention and otherwise use > Matthias.St.Pierre> milestones. > > I personally agree. I think that could work. What's still unclear to me in the current scheme is how I'm supposed to indicate something that is (intentionally) API/ABI-breaking and must be postponed to the next major release. Bear in mind that we still don't know of the release after 1.1.1 will be such a thing or not... -Ben _______________________________________________ openssl-project mailing list firstname.lastname@example.org https://mta.openssl.org/mailman/listinfo/openssl-project