RE: Revisiting tradition: branches and tags

2020-04-14 Thread Dr. Matthias St. Pierre
> > We change the GitHub setup such that pull requests to stable
> > branches need to be based onto the new-style branches, but keep the
> > old-style stable branches in sync with the new-style branches for a
> > little while.
> 
> Er...  how do you change that Github setup?  I thought it simply
> showed a list of all available branches regardless.  So if we got a
> duplicate set, it's going to show both, isn't it?  Considering that
> the github repo is a --mirror of the git.openssl.org repo, I'm not
> sure how the old branch refs would be filtered out...

You are right, I thought it was possible using protected branches, but that
doesn't seem to be the case.

> 
> It seems to me like this discussion is splitting into two:
> 
> 1)  Start with new names for 3.0 and on (I can only see positive
> responses so far, even with Matt's hesitance)
> 2)  Rename of the old names.
>
> As far as I can see, those two don't have to be in absolute sync, even
> though that would be desirable.  In other words, we can figure out the
> details of 2 even after we've started 1.

Agreed.

The best thing would be to publicly announce the branch renaming in a blog post
with a sufficient notice time  (3-6 months) and with detailed instructions
how to rename the local branches and how to reset the upstream branches
(using `git branch --set-upstream-to=...`). Just as we did for the grand code 
reformatting. We might even provide a smart helper script for users to do the
local conversion.


Matthias



Forthcoming OpenSSL Release

2020-04-14 Thread Matt Caswell
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The OpenSSL project team would like to announce the forthcoming release
of OpenSSL version 1.1.1g.

This release will be made available on Tuesday 21st April 2020 between
1300-1700 UTC.

OpenSSL 1.1.g is a security-fix release. The highest severity issue
fixed in this release is HIGH:
https://www.openssl.org/policies/secpolicy.html#high

Yours

The OpenSSL Project Team
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl6VuVwACgkQ2cTSbQ5g
RJEGGwgAnvbo6LVTEz8PdAOoKPgHiz1ObbB8M/fNANk1Oog1w6CF7a8JPEuB/LlQ
ZS0/31x+69xE+GzD4kPBglG6IVnt7F1mlXSc1YEh5c5zs2T5w5Gak5AIzJNZqEFK
EmplFS8eZCpKJZc+0YKgMisF4Q+VbRjI+KVtYQKBn3sHRNH04z4Ti6jlS14R4pQd
PCB4ftXS/LnISkrxL1uVf1seY+5SpmQjk3FR8ZgrR3vuYAyLcD7aeQNKf+unsS4W
u8VnDmqONHa2JfHjsr5PezLZfWa3YTvK352gamyq5sn6y2ciTcI+fABeSD4OYjvQ
I6t4kQrzfCdMrBNY8G2D5NYOi5cOKQ==
=5CII
-END PGP SIGNATURE-


Re: Revisiting tradition: branches and tags

2020-04-14 Thread Richard Levitte
On Tue, 14 Apr 2020 09:28:26 +0200,
Dr. Matthias St. Pierre wrote:
> 
> > > Is it possible to set up alias names for the historical branches?
> > 
> > It's possible yes.  The hard part is 1.1.1.  There *is* something
> > called 'git symbolic-ref', but they can only be added in repos we have
> > physical access to, so while can add those on our git server, and they
> > will work, we cannot add them in github.
> > 
> > Ref git help symbolic-ref
> 
> Symbolic references are *not* the right solution to the problem IMO. They are 
> not equivalent to branches.
> Checking out a symbolic reference leaves you in the 'detached HEAD' state:
> 
> msp@msppc:~/src/openssl$ git symbolic-ref ossl111 
> refs/heads/OpenSSL_1_1_1-stable
> msp@msppc:~/src/openssl$ cd ../openssl-1.1.1
> msp@msppc:~/src/openssl-1.1.1$ git checkout ossl111
> Note: switching to 'ossl111'.
> 
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by switching back to a branch.

Okie.  I hadn't experimented with that, so didn't know.  That manual
is fantastically unclear on what this command does too, at least the
way I read it.  I guess that's another nail in its coffin.

> The proper way to do it IMO is to create new branch and tag
> references for all the stable branches resp. release tags.
...
> Currently, the only old-style branch which needs to be synchronized
> is `OpenSSL_1_1_1-stable`. This could easily be done by the git
> post-receive hook on git.openssl.org. In fact, all old-style branch
> and tag references for all eol-branches could be removed
> immediately.

Good point.  The posst-update hook should be usable for this.

> We change the GitHub setup such that pull requests to stable
> branches need to be based onto the new-style branches, but keep the
> old-style stable branches in sync with the new-style branches for a
> little while.

Er...  how do you change that Github setup?  I thought it simply
showed a list of all available branches regardless.  So if we got a
duplicate set, it's going to show both, isn't it?  Considering that
the github repo is a --mirror of the git.openssl.org repo, I'm not
sure how the old branch refs would be filtered out...

It seems to me like this discussion is splitting into two:

1)  Start with new names for 3.0 and on (I can only see positive
responses so far, even with Matt's hesitance)
2)  Rename of the old names.

As far as I can see, those two don't have to be in absolute sync, even
though that would be desirable.  In other words, we can figure out the
details of 2 even after we've started 1.

Cheers,
Richard

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


RE: Revisiting tradition: branches and tags

2020-04-14 Thread Dr. Matthias St. Pierre
> > Is it possible to set up alias names for the historical branches?
> 
> It's possible yes.  The hard part is 1.1.1.  There *is* something
> called 'git symbolic-ref', but they can only be added in repos we have
> physical access to, so while can add those on our git server, and they
> will work, we cannot add them in github.
> 
> Ref git help symbolic-ref

Symbolic references are *not* the right solution to the problem IMO. They are 
not equivalent to branches.
Checking out a symbolic reference leaves you in the 'detached HEAD' state:

msp@msppc:~/src/openssl$ git symbolic-ref ossl111 
refs/heads/OpenSSL_1_1_1-stable
msp@msppc:~/src/openssl$ cd ../openssl-1.1.1
msp@msppc:~/src/openssl-1.1.1$ git checkout ossl111
Note: switching to 'ossl111'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

The proper way to do it IMO is to create new branch and tag references for all 
the stable branches
resp. release tags. We change the GitHub setup such that pull requests to 
stable branches need to
be based onto the new-style branches, but keep the old-style stable branches in 
sync with the new-style
branches for a little while. Currently, the only old-style branch which needs 
to be synchronized is
` OpenSSL_1_1_1-stable`. This could easily be done by the git post-receive hook 
on git.openssl.org.
In fact, all old-style branch and tag references for all eol-branches could be 
removed immediately.

Matthias