[getting back to this .. see below]
On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
On 29/01/2016 Andrea Pescetti wrote:
For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction ...
I am surely available to have a significant role in the 4.2.0 release
A few days after writing this, almost 2 months ago, sudden events left
me incapacitated to make any significant contributions until very
recently. I'm still unable to make long-term commitments.
Anyway, there are some issues we need to get done as a team before
appointing a release manager makes sense:
1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.
2) Localization. I got shell access to the Pootle server a few days ago.
I'm still looking around, and if someone else want to join this is an
important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.
As the localization changes are quite significant from 4.1.2 to 4.2.0,
can you give us an update on the porting process? Are there
instructions, etc?
3) Buildbots and ASF-owned build machines. Buildbots are not essential
for a release: 4.1.2 was built (like all previous releases in history)
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
can't use buildbots for it; we need to setup new systems. Those who read
the infrastructure@ list can see the discussion I started there
yesterday. Still, having buildbots helps QA and having ASF-owned build
machines is an important investment for the project: at that point we
will be able to make a release within days, not months. We should make
as much progress as we can here. Again, if anybody can help, this is an
important area.
On this. Why can't we use the buildbot assuming we can get all of them
working satisfactorily? I know there are, for example, some library
upgrades/differences between the buildbots and what we've used in the
past, but if we're upgrading to a new version, why can't we just spec
this in the system requirements for 4.2.0?
Can we flesh out specs in this direction? New versions of software often
dictate system software changes.
4) There are several optimizations I have in mind, especially on
reducing a bit our binary size on Linux (trust me, it is really a pain
to commit all those binaries to SVN, or to any version control system).
But they are not essential.
I have just committed to the devtools/ area the scripts we (mainly
Juergen) used to build the 4.1.2 release, with specs of the build
machines. I've had them since last October, but I never committed them.
They are a first step if we want to build our release binaries on ASF
hardware: they contain build options and config.log to have some more
information on the environment.
OK, we will take an indepth look at this, but I really feel we should
move on from specialized release build hardware.
My next priorities will be localization (especially, re-exporting the
Italian translation to Pootle and re-importing it) and and a
proof-of-concept VM for building releases on Linux (64 bit) based on the
above scripts. There is plenty of room for other to jump in (Linux 32,
Windows, Mac; or localization management) so please do!
Regards,
Andrea.
Thanks for all this!
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
