On 26 December 2014 at 00:21, Andrea Pescetti <[email protected]> wrote:
> jan i wrote: > >> It seems (as usual) that the discussion has died out, and nobody does >> anything (my apologies in advance I am wrong, I would very much like to be >> wrong). >> > > You are wrong (so it's good news!), but not so much. I started looking at > it only 2 days ago and I didn't get far enough yet. I'm stuck in activating > access due to a procedural issue being addressed by Infra; so I don't have > the key, but only a preliminary password; and I haven't shared credentials > with anyone else at the moment. Anyway, I concur this is a priority. I am pleased to be wrong, even though "not so much", but some progress is a lot better than none. 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. > > > My suggestion is simple, lets rerun AOO 4.1 for windows, sign it >> digitally, >> and then release it as a patch version. >> > > As 4.1.1? As 4.1.2? From what machines? This is where the discussion is > (not where it stopped). And it is a very concrete issue, not some > theoretical stupidity. > > I'll state what I deem unacceptable (we can discuss it if you have > different opinions, maybe your views on item C are different?): > A) It is unacceptable that the next OpenOffice release is not signed B) It is unacceptable to call something 4.1.2 and release it on Windows only > Since you talk as PMC there are no need to discuss further. 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. 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. I did on purpose not suggest 4.2 since that signals a full release on all platforms. > 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 where we need to link against a new versions of e.g. openssl.lib then we cannot release it....that does not sound logical. Again if you release a patch for a limited set of platforms, it is because the source has not changed, but the surroundings (libraries, signing etc). > D) It is unacceptable that the build is not the same quality as 4.1.1 (in > terms of compatibility with Windows versions and so on); this risk is quite > remote on Windows from what I see. > +1 > > So I already wrote the two options, that can even coexist: > 1) Put online new 4.1.1 Windows binaries > This should really be a no-go. If we do that the checksums will change so people who have downloaded a legitimate 4.1.1 will suddenly see a non matching checksum. Doing this will be counterproductive to our marketing argument about always download from us, because its a trusted version. We cannot change checksums on something that is available on our mirrors Since you find platform patches unacceptable we could make a 4.1.1.1 but it would be kind of strange. 2) Create a 4.1.2 with minor updates and bugfixes, cherry-picking some > trunk updates. If we choose that 4.1.2 will be a quick release, we may > leave all translation updates out of it (Pootle is aligned to trunk at the > moment). > 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. > > I would favor option 2, provided we agree quickly (say, in one week) on > what we get in it. You'll be happy to know that I have already shortlisted > a few bugs that I see relevant for 4.1.2 (list available on request or in > separate discussion). > See above, to me that is full release 4.2 and not a patch to 4.1 > > I am happy to help, especially with the signing, but to help I need access >> to the certificate given to the PMC, and somebody who can make a release >> windows build. >> > > I can take care of the certificate part, which as I wrote move forward in > the last couple of days. For sure, I can't help you with Windows builds. So > you are saying you will need someone else, like Juergen? > My vm for windows can build AOO, but due to some security work I do my windows libraries are far from standard, so I would not recommend using a binary from that vm for production. > Steps are simple: >> 1) make a full build, pick all DLL, JAR and EXE from the object tree >> 2) Sign them, or let me help with that >> 3) Overwrite the object tree with the signed artifacts >> 4) run build but on postprocess (generate new setup package) >> 5) Sign the installer or let me help with that >> 6) Upload and start vote >> 7) Upload to dist and be happy. >> What is stopping us from doing something that simple ? >> > > This is OK for option 1 (the 4.1.1 replacement). Not quite for option 2, > meaning that in that case you need the builds in all platforms. But Juergen > wrote recently that he still volunteers to provide them, so indeed this is > quite feasible. > > And please lets not cloud this simple step, by missing buildbots etc. >> > > In option 1, you only need a Windows machine. In option 2, you need all > release build machines. Assuming we have them, I see no other obstacles; we > will eventually need buildbots, but these are no longer a prerequisite as I > recently wrote. So let's indeed clarify if we want to go for 1 or 2 (or for > something else) and then just do it. > 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 please bear in mind this is my personal opinion, and does not count should it come to a vote. rgds jan i. > > Regards, > Andrea. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
