[openssl.org #2950] [PATCH] Fix speed.c to show human readable output

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #2950] [PATCH] Fix speed.c to show human readable output

Rich Salz via RT
Fixed in the documentation; -multi fordes -mr because otherwise it can't
distinguish the
output and summarize.

Fixed in rsalz-monolith branch of akamai/openssl fork on github for release
after 1.0.2

commit dad54e853ca8cd094bd110aa1b99311717d78905
Author: Rich Salz <[hidden email]>
Date: Tue Aug 26 13:26:55 2014 -0400

RT2950: issue with -mr and -multi

Fixed in documentation: -multi implies -mr and clears -usertime
because otherwise the message outputs get interwoven

--
Rich Salz, OpenSSL dev team; [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

official repository vs forks, and fixes

Support

Hi Rich,

First off thanks for grinding through the buglist.
I'm a bit confused however - do I understand it correctly that some bugs are being fixed in a different, forked repository (https://github.com/akamai/openssl) instead of the official one (https://github.com/openssl/openssl) ?

[openssl.org #2950] [PATCH] Fix speed.c to show human readable output

Fixed in rsalz-monolith branch of akamai/openssl fork on github for release after 1.0.2

Shouldn't the official repository be the single source of truth ? I see a rsalz-monolith branch in the official repo, but that seems to be a bit out of date - the last commit is from July 16th.
Personally I would consider a bug resolved if it's fixed in the official repository (in the applicable branches), not when it's patched in a forked repo.

Thanks,


Peter Mosmans
Reply | Threaded
Open this post in threaded view
|

RE: official repository vs forks, and fixes

Salz, Rich

Think of this as pre-release software.  The changes are too large to disrupt the 1.0.2 release, which is already in beta.

 

We haven’t yet figured out how to make early-access to branches available, so for now I just did it via Akamai.  At some point, I’d expect that branch to “move” over to openssl’s repo, but we’re not there yet.

 

Make sense?

 

                /r$

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: [hidden email] Twitter: RichSalz

Reply | Threaded
Open this post in threaded view
|

RE: official repository vs forks, and fixes

wrowe
--------- Original Message ---------
Subject: RE: official repository vs forks, and fixes
From: "Salz, Rich" <[hidden email]>
Date: 8/26/14 4:13 pm
To: "[hidden email]" <[hidden email]>

Think of this as pre-release software.  The changes are too large to disrupt the 1.0.2 release, which is already in beta. 

We haven’t yet figured out how to make early-access to branches available, so for now I just did it via Akamai.  At some point, I’d expect that branch to “move” over to openssl’s repo, but we’re not there yet.

Make sense?

 

 
FWIW, most of us picking up 1.0.2 will be in it for the long haul, I wouldn't expect many to shift from 1.0.2 again to 1.0.3 over the course of a year or several.  It might be worth rethinking the 1.0.2 release plan to pick up corrections, especially if they improve the trust in the code that ships, even if this means resetting the 1.0.2 scope or API?

 

It also ensures that some platforms being kicked off the bus will stall at 1.0.1, rather than leaving that code around for years in a 1.0.2 release.  If the decision's been made to drop them, then the sooner, the better.

 

Just food for thought.
Reply | Threaded
Open this post in threaded view
|

RE: official repository vs forks, and fixes

Salz, Rich
> FWIW, most of us picking up 1.0.2 will be in it for the long haul, I wouldn't expect many to shift from 1.0.2 again to 1.0.3 over the course of a year or several.  It might be worth rethinking the 1.0.2 release plan to pick

I understand the concern.  But we have already declared that 1.0.2 is frozen except for fixes. And we have some other changes coming post-1.0.2 that we don't want to delay.  For example, I'd expect TLS1.3 to be in, well, 1.0.3 or whatever we call it.

        /r$

:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�
Reply | Threaded
Open this post in threaded view
|

Re: official repository vs forks, and fixes

Support
In reply to this post by Salz, Rich

Hi Rich,

Thanks for your explanation. Branching in git is extremely fast and lightweight, which makes it excellent for feature developing without disrupting anything :)
I wondered why the changes weren't applied onto the rsalz-monolith branch in the official repository, since that branch already exists there.
A big advantage of having everything in the same official repo is that developers who forked the repo can merge and/or cherry-pick changes onto their own branches. Having to work with multiple upstream repositories is, err, less-than-optimal and error-prone.

Would it be an idea to create branches in the official repo for (certain classes of) bugfixes, which can be merged onto the respective branches at set times ? For instance one for documentation fixes ? You could merge these bugfix branches then also to onto your rsalz-monolith branch, which would keep the repository nice and orderly.
Branches having lots of different commit types (features, bugfixes, enhancements, changes) can diverge so much from the official branches that it will get harder and harder for others to merge them onto forks or other diverged branches without running into issues. A codebase as large and as complex as openssl makes it already prone to versioning errors (eg. fixes implemented in branch X but not in branch Y).

I'm eagerly awaiting the 'move' of your forked repo branch to the official repository... I'd say the more branches in the official repo the better!


Peter Mosmans



On 26-08-2014 23:13, Salz, Rich wrote:

Think of this as pre-release software.  The changes are too large to disrupt the 1.0.2 release, which is already in beta.

 

We haven’t yet figured out how to make early-access to branches available, so for now I just did it via Akamai.  At some point, I’d expect that branch to “move” over to openssl’s repo, but we’re not there yet.

 

Make sense?

 

                /r$

 

-- 

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: [hidden email] Twitter: RichSalz


Reply | Threaded
Open this post in threaded view
|

RE: official repository vs forks, and fixes

Salz, Rich
> Would it be an idea to create branches in the official repo for (certain classes of) bugfixes, which can be merged onto the respective branches at set times ? For instance one for documentation fixes ? You could

Yes.  But we (the dev team) haven't figured out all of the details of our workflow yet.

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [hidden email] Twitter: RichSalz
:��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%����&jם.+-1�ځ��j:+v�������h�