Am 01/01/2015 10:19 PM, schrieb Andrea Pescetti:
On 30/12/2014 jan i wrote:
On Tuesday, December 30, 2014, Andrea Pescetti wrote:
Open issues were:
1) Decide on making 4.1.1.1, 4.1.2, whatever. This is solved, we are
going
to make a new release and call it 4.1.2.
2) Fix access to certificate for signing. Still waiting for Infra, but I
can't blame them.
3) Decide what to include. I opened a dedicated discussion yesterday,
with
an explicit list of about 20 bugs to consider.
4) Add 4.1.2 to Bugzilla. We need a Bugzilla admin to do it, asked
yesterday.
we also need
5) discuss do we need a release candidate or do we vote on the real
thing.

If I understand correctly, the best option is to tag a source package
that identifies itself as "OpenOffice 4.1.2" and vote on that (so it's a
Release Candidate but if approved it becomes the final one, and so far
there is nothing new), but binaries may be an issue since we would spend
a lot of time (and also many signing credits, which are not for free) if
we sign Windows artifacts that will not be approved. Here I can
understand you request to vote only on source + English Windows binary +
other platforms binaries and then build other languages separately, only
after the first vote has passed. I agree with that.

Just to remember:
We vote only on the source (and therefore the source tarballs are relevant).

AFAIK the signing process is without any code changes. So, we need some code changes (1 fixed bug or 1 new/updated language) if we want to vote for something. ;-)

6) get confirmation from jürgen that he has time now to this "double"
release
6a) check if he can do all platforms or alternatively find out how to do
the rest
7) make sure henkp will help with the mirrors again, last time he was
less
than pleased due to the 1week window of regular work.

I think henkp stopped uploading releases to the mirrors. 4.1.1 is on
SourceForge only, since putting it on Apache mirrors was a lot of work
by Infra for negligible benefit to the users. So step 7 can probably be
ignored.

Yes, the users do not get any benefit as it is not (well-)known that AOO could be downloaded via Apache mirrors. We use Sourceforge and this works very well. So, to be Infra-friendly just make sure that no binaries will be uploaded to Apache mirrors - only the SDK and source files.

8) prepare release notes etc.

Well, once we are set to make a release the release checklist applies:
https://cwiki.apache.org/confluence/display/OOOUSERS/Release+Planning+Template

(of course, most items do not apply since this is a micro release).

As for the source code, we don't even need a new branch (even though I
would be for creating it); as you see at http://svn.apache.org/viewvc/
openoffice/branches/ for 4.1.1 we reused the "AOO410" branch.
I am aware of that, personally I dont like it, because we loose track of
what was released, but I will leave that to the release manager.

OK, so if nobody sees reasons to reuse "AOO410" I think we agree that we
will create a "AOO412" branch for 4.1.2.

Yes, please. IMHO every new release with code changes should have a separated branch - or at least SVN tag.

Marcus


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to