Re: [openssl-project] GitHub labels
> 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
> 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&q=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
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/ ___ openssl-project
Re: [openssl-project] GitHub labels
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&q=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&q=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
[openssl-project] GitHub labels
I think it’s a good idea that we periodically review the labels we’re using. Please look at https://github.com/openssl/openssl/labels and maybe suggest changes. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Beta release today
Release is done - repo is unfrozen! Thanks to Richard once again for helping out. Matt On 20/06/18 15:11, Matt Caswell wrote: > The last few commits seem to have stabilised the build: > > https://travis-ci.org/openssl/openssl/builds/394565396 > > There is one red cross from travis. That is due to one failure in the > pyca external tests. However, we know what that is and believe it to be > a bug in pyca itself (a latent bug that we inadvertently triggered > recently): > > https://travis-ci.org/openssl/openssl/builds/394565396 > > Therefore we are going to press ahead with the release. > > Matt > > > On 20/06/18 11:32, Matt Caswell wrote: >> The build is currently not stable. We have a number of outstanding issues: >> >> - external pyca tests are failing >> - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that >> at the moment >> - failures in test_internal_sm2. Bernd has been working on that and we >> now have a fix that I just need to merge >> - run-checker reported a failure in no-ec. This turns out to the be the >> same problem as the no-sm2 failure >> - run-checker reported a failure with asan. I think this is the same >> issue as the test_internal_sm2 one above >> >> The biggest blocker is the pyca one. We don't currently understand that >> issue. I think we understand the resolution for the others. >> >> With the above issues I don't think we're ready to release yet. Possibly >> later today. Watch this space. >> >> >> Matt >> ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] OpenSSL version 1.1.1 pre release 8 published
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 OpenSSL version 1.1.1 pre release 8 (beta) === OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 8 has now been made available. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1-pre8.tar.gz Size: 8334954 SHA1 checksum: 6bca29b8b9b6cf399ad9ee585ff72c314406a757 SHA256 checksum: 1205cd763dd92c910cc590658a5b0774599e8587d89d6debd948f242b949321e The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1-pre8.tar.gz openssl sha256 openssl-1.1.1-pre8.tar.gz Please download and check this beta release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsqaTYACgkQ2cTSbQ5g RJEDPgf+MNjzRojgEzlu1IQmBthLgE2u9FL1IzTqeDGLBHolCws136AP0C8meHMi kJUS616C5Xe8P4NYJKHQhrRoJoB8iY92aJRJTjWLEic/KWR/SmTfLLuUCQ35iArP sT95NOhtHiYhc5iHAk0cDt42kf8ukgpLi1DcobNwzoFUma9M5y973V6fMg7OpIWu gdSFFRjajmGJnWWmlW6+25XPBW+2otu07yRTIM+O08CEl2EcYf0TxDmncCoHS1Zu vHt8HmRVTTzZ27hFndeD2HLeiVUe/teUfHAWe5VyqRhLcNoa20zGX2F/cvzZH8Zb 7qmwRpfVFJX0llNccuhCQVKnah1kjw== =6mX8 -END PGP SIGNATURE- ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Beta release today
The last few commits seem to have stabilised the build: https://travis-ci.org/openssl/openssl/builds/394565396 There is one red cross from travis. That is due to one failure in the pyca external tests. However, we know what that is and believe it to be a bug in pyca itself (a latent bug that we inadvertently triggered recently): https://travis-ci.org/openssl/openssl/builds/394565396 Therefore we are going to press ahead with the release. Matt On 20/06/18 11:32, Matt Caswell wrote: > The build is currently not stable. We have a number of outstanding issues: > > - external pyca tests are failing > - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that > at the moment > - failures in test_internal_sm2. Bernd has been working on that and we > now have a fix that I just need to merge > - run-checker reported a failure in no-ec. This turns out to the be the > same problem as the no-sm2 failure > - run-checker reported a failure with asan. I think this is the same > issue as the test_internal_sm2 one above > > The biggest blocker is the pyca one. We don't currently understand that > issue. I think we understand the resolution for the others. > > With the above issues I don't think we're ready to release yet. Possibly > later today. Watch this space. > > > Matt > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Beta release today
The build is currently not stable. We have a number of outstanding issues: - external pyca tests are failing - no-sm2 fails (see PR#6531)...I'm doing some more investigation on that at the moment - failures in test_internal_sm2. Bernd has been working on that and we now have a fix that I just need to merge - run-checker reported a failure in no-ec. This turns out to the be the same problem as the no-sm2 failure - run-checker reported a failure with asan. I think this is the same issue as the test_internal_sm2 one above The biggest blocker is the pyca one. We don't currently understand that issue. I think we understand the resolution for the others. With the above issues I don't think we're ready to release yet. Possibly later today. Watch this space. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project