Re: [openssl-project] GitHub labels

2018-06-22 Thread Richard Levitte
In message <20180622010813.gy4...@kduck.kaduk.org> on Thu, 21 Jun 2018 20:08:13 
-0500, Benjamin Kaduk  said:

kaduk> What's still unclear to me in the current scheme is how I'm supposed to
kaduk> indicate something that is (intentionally) API/ABI-breaking and must be
kaduk> postponed to the next major release.  Bear in mind that we still don't 
know
kaduk> of the release after 1.1.1 will be such a thing or not...

Argh!

I'm pretty sure I added a label '1.2.0' to do *exactly* that.
Apparently, not everyone agrees with such indication...

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] GitHub labels

2018-06-21 Thread Benjamin Kaduk
On Wed, Jun 20, 2018 at 10:29:37PM +0200, Richard Levitte wrote:
> In message  on Wed, 20 Jun 
> 2018 19:59:02 +, "Dr. Matthias St. Pierre"  
> 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:' 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
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre
> Matthias.St.Pierre> The github search index allows to search for
> 'base:' 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.

Me neither, until today ;-). I looked it up on a useful page called 'Searching 
issues and pull requests':
https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-branch-name

Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre


> Matthias.St.Pierre> A propos: it might be useful to split the 'pending
> Matthias.St.Pierre> 2nd review' into two different labels (of the same color):
> Matthias.St.Pierre>
> Matthias.St.Pierre>  'pending 2nd review'  ->  'review-required'  
> and
> 'omc-review-required'
> 
> I'm frankly unsure...  it's not like there's such a massive amount of 
> 'pending 2nd
> review' at one time to warrant such a split...

You are probably right. It was just a quick idea that came to my mind.

> Matthias.St.Pierre> 'wont-fix' and 'technical-debt' are currently
> Matthias.St.Pierre> unused. Do we really need them?  For example, if
> Matthias.St.Pierre> an issue is closed without fixing it, does it
> Matthias.St.Pierre> really require a ‚wont-fix‘ label?
> 
> That depends on how keen you are, when someone asks two weeks later why
> an issue was closed, to dig through lots of commentary (for an issue that 
> did, in
> fact, contain a lot of commentary) to find that one comment that says "Wont
> fix" (remember that people can keep commenting after an issue is closed, so
> scrolling to the end isn't necessarely the easy answer).

Makes sense, in theory. In practice, there is not a single issue marked 
'wontfix',
neither open nor closed:

https://github.com/openssl/openssl/issues?utf8=%E2%9C%93=label%3A%22Issue+resolved+-+WONTFIX%22+



> 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.

You're right, having labels for all relevant branches ('master', '1.1.1', 
'1.1.0', '1.0.2') makes
sense for consistency and there is nothing wrong if people prefer to label a 
pull request
with the target branch, too.

> 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.

The milestones are listed to on the right hand side, too, see
https://github.com/openssl/openssl/pull/6509.
Under 'Labels' there is an entry 'Projects' followed by 'Milestones'


Matthias

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] GitHub labels

2018-06-20 Thread Richard Levitte
In message  on Wed, 20 Jun 
2018 19:59:02 +, "Dr. Matthias St. Pierre"  
said:

Matthias.St.Pierre> There are a lot of things that come to my mind when I see 
all those labels:
Matthias.St.Pierre> 
Matthias.St.Pierre> IMHO there are too many of them and for some of them the 
precise meaning is
Matthias.St.Pierre> not clear. So maybe we should reduce their number a bit and 
document the 
Matthias.St.Pierre> meaning and semantics of the other.
Matthias.St.Pierre> 
Matthias.St.Pierre> 
Matthias.St.Pierre> I) NAMING CONVENTIONS
Matthias.St.Pierre> 
Matthias.St.Pierre> First of all: Labels should be short and lowercase. 
Personally, I like these
Matthias.St.Pierre> lisp-style identifiers like 'need-cla' and 
'technical-debt'. So I would rename
Matthias.St.Pierre> 
Matthias.St.Pierre>  'pending 2nd review'  ->  'review-required'
Matthias.St.Pierre>  'Issue resolved - WONTFIX'   -> 'wont-fix'

There should be a consistent coloring scheme too.

Matthias.St.Pierre> A propos: it might be useful to split the 'pending
Matthias.St.Pierre> 2nd review' into two different labels (of the same color):
Matthias.St.Pierre> 
Matthias.St.Pierre>  'pending 2nd review'  ->  'review-required'  
and 'omc-review-required'

I'm frankly unsure...  it's not like there's such a massive amount of
'pending 2nd review' at one time to warrant such a split...

Matthias.St.Pierre> II) UNUSED LABELS
Matthias.St.Pierre> 
Matthias.St.Pierre> 'wont-fix' and 'technical-debt' are currently
Matthias.St.Pierre> unused. Do we really need them?  For example, if
Matthias.St.Pierre> an issue is closed without fixing it, does it
Matthias.St.Pierre> really require a ‚wont-fix‘ label?

That depends on how keen you are, when someone asks two weeks later
why an issue was closed, to dig through lots of commentary (for an
issue that did, in fact, contain a lot of commentary) to find that one
comment that says "Wont fix" (remember that people can keep commenting
after an issue is closed, so scrolling to the end isn't necessarely
the easy answer).

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.

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:' 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.

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___

Re: [openssl-project] GitHub labels

2018-06-20 Thread Dr. Matthias St. Pierre
There are a lot of things that come to my mind when I see all those labels:

IMHO there are too many of them and for some of them the precise meaning is
not clear. So maybe we should reduce their number a bit and document the 
meaning and semantics of the other.


I) NAMING CONVENTIONS

First of all: Labels should be short and lowercase. Personally, I like these
lisp-style identifiers like 'need-cla' and 'technical-debt'. So I would rename

 'pending 2nd review'  ->  'review-required'
 'Issue resolved - WONTFIX'   -> 'wont-fix'

A propos: it might be useful to split the 'pending 2nd review' into two 
different
labels (of the same color):

 'pending 2nd review'  ->  'review-required'  and 
'omc-review-required'


II) UNUSED LABELS

'wont-fix' and 'technical-debt' are currently unused. Do we really need them?
For example, if an issue is closed without fixing it, does it really require a 
‚wont-fix‘
label?


III) VERSION NUMBER LABELS

It seems like the version number labels '1.0.2', '1.1.0', '1.1.1', 'after 1.1.1'
currently serve two differente purposes: 

1. Indicate the intention to which branches a pull request will be backported
   Approval holds for all labeled branches.
   
2. As surrogate milestones


ad 1):
Using the version number labels as indication of merge intention makes sense.
But then the 'master' label and (currently) the '1.1.1' label are superfluous.
If the pull request targets the 'master' branch, why does it need a 'master' 
label?
The github search index allows to search for 'base:' which is a much
more reliable way of determining the target branch:

 Open pull requests targeting 'master':
 
https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+base%3Amaster

 Open pull requests targeting 'OpenSSL_1_1_0-stable':
 
https://github.com/openssl/openssl/pulls?utf8=%E2%9C%93=is%3Aopen+is%3Apr+base%3AOpenSSL_1_1_0-stable

If you follow the second link, you will immediately find #5260 which targets 
OpenSSL_1_1_0-stable
but is erroneously labeled with 'post 1.1.1'.

So IMHO it only makes sense to set labels for stable branches to which one 
intents to backport. 
This means that 'master' and (currently) '1.1.1' are superfluous.


ad 2): 
The label 'after 1.1.1' is a surrogate milestone and IMHO it would be better to 
use
the 'Post 1.1.1' milestone instead of the label. One could go even further and 
ask
what sense does it make to have such an unspecific milestone as 'Post 1.1.1'?
Wouldn't it be better to leave such pull requests unassigned? 

Maybe one reason for having the 'after 1.1.1' label is that these pull requests 
can't be merged yet,
since 1.1.1 has not been split off as a separate branch yet. But isn't the 
'hold' label intended for
precisely this case? Or will it be set only if an omc member places a veto and 
requests a vote?
The latter could be named 'vote-requested'.

IMHO it would make sense to use the version labels only to indicate merge 
intention and
otherwise use milestones.

 https://github.com/openssl/openssl/labels    
 https://github.com/openssl/openssl/milestones

Regards, Matthias


___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project