openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Pescetti <>
Subject Re: Digital signing release for windows.
Date Fri, 26 Dec 2014 12:11:01 GMT
On 26/12/2014 jan i wrote:
> May I suggest that once you get access (no rush here, we need to prepare
> the release first), that you create 1-2 PMC credentials so that access is
> not lost if one credential gets locked.

Definitely. I'm now being the contact person since we don't have 
appointed a release manager yet. In the end, for sure I will not be 
producing Windows builds and it makes sense that people who produce the 
builds have access to the system.

>> B) It is unacceptable to call something 4.1.2 and release it on Windows only
> ... But I have say
> AOO has a different way of using x.y.z than other projects. The x.y.2
> signals a patch, and that is normally only done for the platforms who have
> the problem.

Historically we never released for one platform only. If we do it for 
4.1.2 there will be people who erroneously believe we have dropped Mac 
or Linux; this is my concern more than the use of numbering.

> If I follow your "unacceptable" then I hope we will never have a serious
> security issue on a single  platform, since we would have to have to wait
> for a release on all platforms, that would in my opinion be unacceptable.

If the needs arises, I'm sure this can be discussed. But this is not the 
case now. And historically, again, indeed security updates were included 
in the normal release cycle. But as far as I know we were never in the 
position to have to get a release out within 24 hours due to security 
issues. So I would keep this discussion for when it happens.

>> C) It is unacceptable to call something 4.1.2 if it is 100% identical to
>> 4.1.1 on Linux and Mac.
> Hmmm so if we have a security issue...

I'm speaking for 4.1.2, I'm not speaking in general.

>> 1) Put online new 4.1.1 Windows binaries
> This should really be a no-go. If we do that the checksums will change

Not necessarily, it all depends on how we restructure the web pages and 
the files tree on SourceForge. But nobody preferred this option across 
all discussions we had so far, so option 2 deserves more attention.

>> 2) Create a 4.1.2 with minor updates and bugfixes, cherry-picking some
>> trunk updates. ...
> We cannot cherry-pick trunk updates, that would make it a 4.2 !!!
> Patches are meant to be critical fixes, and not random bug-fixes.

Probably we agree, we simply use different wording. For 4.1.2, the 
reference would be the 4.1.0 -> 4.1.1 changes. See 
and from there: we included bugfixes 
that did not have impact on UI, that did not introduce new features, 
that updated translations (this would be out in 4.1.2 as I explained) or 
dictionaries, or that allowed building/running more smoothly in certain 
environments. What they all had in common was to be low-risk and 
reviewed. Not all of them were really "critical". I would do the same 
for 4.1.2, maybe fixing even just a handful of annoying bugs.

> I like option 2, but I am strongly against cherry picking updates on trunk.
> If we have serious bugs then they can be included. I do however not believe
> we have such bugs, otherwise we would have discussed 4.1.2 long time ago.
> I am open for option 2 as you describe it, if its called 4.2

All we need to agree upon is what we mean by "serious". This is not 
hard. I think we can agree that 4.1.1 to 4.1.2 will be like 4.1.0 to 
4.1.1, except that we put the threshold for inclusion higher, so we 
include fewer fixes (nowhere near the 89 fixes we had in 4.1.1).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message