[openssl-project] GitHub labels

[Benjamin Kaduk]

On Wed, Jun 20, 2018 at 10:29:37PM +0200, Richard Levitte wrote:
> In message <c9407418eba94248bb9717273124395d at Ex13.ncp.local> on Wed, 20 Jun 2018 19:59:02 +0000, "Dr. Matthias St. Pierre" <Matthias.St.Pierre at 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