Re: [RELEASE]: preparation for our first release
On 27/02/2012 Andre Fischer wrote: Would it make sense to make localization a more continuous process? Like adding a step to the build server to collect new strings daily or weekly, upload them to the pootle server, and integrate any newly translated strings? It would be nice to have but not necessarily urgent or important: the most urgent problem is access for volunteers, that is being discussed separately. For the time being, it would be perfectly acceptable to establish deadlines, with no need for a continuous process. Regards, Andrea.
Re: Localization process (Re: [RELEASE]: preparation for our first release)
Il 01/03/2012 11:49, Andre Fischer ha scritto:
On 29.02.2012 21:59, Andrea Pescetti wrote:
On 27/02/2012 Andrea Pescetti wrote:
On 27/02/2012 Andre Fischer wrote:
It would help me, for example, if you could describe the localization
from you POV, like how you down- and later upload data from/to the
pootle server. When do you start translation, how do you signal that
you
have finished translating and the uploaded data is ready for
integration?
This is easy and I can answer it too: Sun/Oracle used to prepare the
data from the sources and uploaded them to a Pootle server; then
translation teams would operate on the PO files (online or offline)
before an announced "translation deadline"; at that point, control was
back in the hands of Sun/Oracle: they used data from the PO files to
repopulate the SDF files used in the source. But this probably adds
nothing to what you already know: in other words, the code<->Pootle
conversions have always been "black boxes" for translation teams.
Actually, the code<->Pootle conversions haven't always been "black
boxes": what I wrote is true for recent years, but before that the
translation teams delivered the sdf files directly, so we went an extra
step, even though not directly to the source code. That process was
managed by Paolo Pozzan, who recently joined the list, so he might
provide some useful insights.
Paolo,
http://wiki.services.openoffice.org/wiki/Localization_for_developers
contains the information we have so far. If you know more about any of
the steps involved, feel free to complete it.
And please don't be shy. I have no prior experience with the translation
process. I just pieced together what I found in the makefiles and source
code of tools.
Fortunately I'm not shy, just busy with other things ;-)
I added the few things I know to the wiki page. I am confident with all
the processes from .sdf to translators and back. If there is a way I can
help I am ready to do it, just tell me what I need to do.
Paolo also has Pootle backups for Italian taken in April 2011, which
means we might compare them to Andre Fischer's files
http://s.apache.org/5YT (thread: http://s.apache.org/k0 ) and see if
that backup is current. Anyway, we didn't update translations after
April 2011, so we surely have the latest data ("we" = "Italian
translation team").
That sounds great. Is your data in a form that could be checked into
extras/l10n/ directly?
I have the whole po files from pootle. I just downloaded the .sdf file
from extras/l10n. I'm going to convert it, check the differences and
then let you know.
Paolo
Re: Localization process (Re: [RELEASE]: preparation for our first release)
On 29.02.2012 21:59, Andrea Pescetti wrote:
On 27/02/2012 Andrea Pescetti wrote:
On 27/02/2012 Andre Fischer wrote:
It would help me, for example, if you could describe the localization
from you POV, like how you down- and later upload data from/to the
pootle server. When do you start translation, how do you signal that you
have finished translating and the uploaded data is ready for
integration?
This is easy and I can answer it too: Sun/Oracle used to prepare the
data from the sources and uploaded them to a Pootle server; then
translation teams would operate on the PO files (online or offline)
before an announced "translation deadline"; at that point, control was
back in the hands of Sun/Oracle: they used data from the PO files to
repopulate the SDF files used in the source. But this probably adds
nothing to what you already know: in other words, the code<->Pootle
conversions have always been "black boxes" for translation teams.
Actually, the code<->Pootle conversions haven't always been "black
boxes": what I wrote is true for recent years, but before that the
translation teams delivered the sdf files directly, so we went an extra
step, even though not directly to the source code. That process was
managed by Paolo Pozzan, who recently joined the list, so he might
provide some useful insights.
Paolo,
http://wiki.services.openoffice.org/wiki/Localization_for_developers
contains the information we have so far. If you know more about any of
the steps involved, feel free to complete it.
And please don't be shy. I have no prior experience with the
translation process. I just pieced together what I found in the
makefiles and source code of tools.
Paolo also has Pootle backups for Italian taken in April 2011, which
means we might compare them to Andre Fischer's files
http://s.apache.org/5YT (thread: http://s.apache.org/k0 ) and see if
that backup is current. Anyway, we didn't update translations after
April 2011, so we surely have the latest data ("we" = "Italian
translation team").
That sounds great. Is your data in a form that could be checked into
extras/l10n/ directly?
Thanks, Andre
Regards,
Andrea.
Localization process (Re: [RELEASE]: preparation for our first release)
On 27/02/2012 Andrea Pescetti wrote:
On 27/02/2012 Andre Fischer wrote:
It would help me, for example, if you could describe the localization
from you POV, like how you down- and later upload data from/to the
pootle server. When do you start translation, how do you signal that you
have finished translating and the uploaded data is ready for integration?
This is easy and I can answer it too: Sun/Oracle used to prepare the
data from the sources and uploaded them to a Pootle server; then
translation teams would operate on the PO files (online or offline)
before an announced "translation deadline"; at that point, control was
back in the hands of Sun/Oracle: they used data from the PO files to
repopulate the SDF files used in the source. But this probably adds
nothing to what you already know: in other words, the code<->Pootle
conversions have always been "black boxes" for translation teams.
Actually, the code<->Pootle conversions haven't always been "black
boxes": what I wrote is true for recent years, but before that the
translation teams delivered the sdf files directly, so we went an extra
step, even though not directly to the source code. That process was
managed by Paolo Pozzan, who recently joined the list, so he might
provide some useful insights.
Paolo,
http://wiki.services.openoffice.org/wiki/Localization_for_developers
contains the information we have so far. If you know more about any of
the steps involved, feel free to complete it.
Paolo also has Pootle backups for Italian taken in April 2011, which
means we might compare them to Andre Fischer's files
http://s.apache.org/5YT (thread: http://s.apache.org/k0 ) and see if
that backup is current. Anyway, we didn't update translations after
April 2011, so we surely have the latest data ("we" = "Italian
translation team").
Regards,
Andrea.
Re: [RELEASE]: preparation for our first release
2012/2/24 Jürgen Schmidt > Hi, > > we move closer forward to our first release. > > I would like to suggest that we focus on the following areas next week. > And I would like to propose the following schedule depending on the > progress we will make next week. > > > Monday: Feb. 27th new dev snapshots > Monday: March 5th first RC candidate (based on the progress next week) > > - increase QA work > - focus on stabilization, means focus on showstopper issues > - finalize the About dialog information, input for future bug reports > - online update service > well...a tiny little breakthrough on the update service... I did the following today-- * reassigned the old update service ( update36.services.openoffice.org) to the current web server IP via my /etc/host file * created a ProductUpdateService directory on www.openoffice.org and dumped Ariel's atom feed file into the directory with the name check.Update Now, on my exisiting OOo3.3, when I click "Check for updates", it *gets* somewhere but of course, my system is expecting an ".rpm" package and not a tar ball as spec'd in the DL url, so nothing happens. Really I didn't try to find something reasonable, I just wanted to see if the ideas I had about re-routing the connection would work. Bottom line. I think we should have infra also make this DNS change. At least folks with current "auto upgrades" will not continue to suffer from NO conenctions AND we now have an place to test/implement the feed, assuming we can get it in the right format for what we will be releasing with 3.4. Thoughts? ps. I will copy all this to the previous thread/post on the update service as well. > - updating building guides in the wiki > > > - documentation update can be run in parallel and are independent of the > binary release > - translation update, we have made minimal UI changes only and we will use > the 3.4 beta translation that were in place. > > Anything else that comes into your minds? > > I have started to work on the MacOS building guide and have simplified > some things (work ongoing). > > We need some volunteers who take a look on the other platforms. Especially > reference to the hg repo should be removed/replaced to our svn repo. > Information about childworkspaces can be removed because it is not longer > relevant for us. I would say the focus should be on simplification. > > What do others think about it? > > Juergen > -- MzK "Follow your bliss." -- attributed to Joseph Campbell
Re: [RELEASE]: preparation for our first release
Would it make sense to make localization a more continuous process? Like adding a step to the build server to collect new strings daily or weekly, upload them to the pootle server, and integrate any newly translated strings? Regards, Andre Not on a daily basis. If you make things available for translation too quickly, there's a lot of toing in froing. Say you accidentally commit a bit of code which requires 20 new strings to be translated. Some teams will deal with that quickly and if you have to back it out 2 days later, they will have worked for nothing. So experimental stuff should not come up for translation straight away. The thing is, making changed/new strings available fast is not key really. Between releases, there's not much usually. Michael
Re: [RELEASE]: preparation for our first release
On 27.02.2012 15:55, Andrea Pescetti wrote: On 27/02/2012 Andre Fischer wrote: It would help me, for example, if you could describe the localization from you POV, like how you down- and later upload data from/to the pootle server. When do you start translation, how do you signal that you have finished translating and the uploaded data is ready for integration? This is easy and I can answer it too: Sun/Oracle used to prepare the data from the sources and uploaded them to a Pootle server; then translation teams would operate on the PO files (online or offline) before an announced "translation deadline"; at that point, control was back in the hands of Sun/Oracle: they used data from the PO files to repopulate the SDF files used in the source. But this probably adds nothing to what you already know: in other words, the code<->Pootle conversions have always been "black boxes" for translation teams. So Sun/Oracle gave signals for both the start and the end of translation. I had suspected that. Would it make sense to make localization a more continuous process? Like adding a step to the build server to collect new strings daily or weekly, upload them to the pootle server, and integrate any newly translated strings? Regards, Andre Regards, Andrea.
Re: [RELEASE]: preparation for our first release
But this probably adds nothing to what you already know: in other words, the code<->Pootle conversions have always been "black boxes" for translation teams. Regards, Andrea. Yes, that's (fortunately) been the case and should continue to be the case. And I am a developer with limited knowledge about the localization process. Maybe we can help each other. It would help me, for example, if you could describe the localization from you POV, like how you down- and later upload data from/to the pootle server. When do you start translation, how do you signal that you have finished translating and the uploaded data is ready for integration? -Andre Sure. There's little in a way that I need to add to what Andrea said. The black magic between the po files on Pootle and the rc / releases must remain separate from the task of translation. Pootle server is good, it allows on and offline collaboration, offline for example by downloading the po files and then editing them in a translation memory such as Virtaal which reduces the amount of re-translation. There were and are (over on LO) no "signoffs" the way Mozilla has them. There are translation deadlines and if a locale has completed a sufficient amount of the UI by that date, then there will be a release in that language. I know we had this debate about release vs language pack; that should remain in the background, all the end user wants to know is that they can get OO with the UI in their language. I'm not sure if the upload options come with Pootle or if they must be coded, i.e. you get the choice of Uploading and overwriting, Uploading and turning conflicts into suggestions etc. If they need to be coded manually, we can talk about that. If you want to, you could sign up with the LO pootle server and I can give you rights in Scots Gaelic so you can see how it works? I'm just not sure what "comes with Pootle" and what doesn't, so perhaps the first thing to do would be to get it up and running and see what that gives you, perhaps with a small number of locales that we can test stuff with? Since this is still fluid, I'd like to make an impassioned plea. We should set intelligent cutoffs (note the plural). For most localizers, the key part of OO/LO is Writer. But the localization process so far has required teams to complete x% of the total UI. This is very unhelpful and an obstacle to new locales, especially small ones. There's a possibility here of making AOO very attractive to new, small locales by introducing stepped localization i.e. we identify the strings which are in Writer and allow releases for locales which have completed just Writer, OpenOffice "light" in a sense. I know there's grey areas in between (i.e. which strings show up where) but even just excluding those which are clearly Draw/Calc/Database/Formula/Present makes localization more manageable. OO has gotten fairly big. Beyond that, ideall you simply add and additional translations to a release but if someone argues heavily for doing it package by package i.e. once you finish Draw, you also get Draw localized UI, then I won't argue. Michael
Re: [RELEASE]: preparation for our first release
On 27/02/2012 Andre Fischer wrote: It would help me, for example, if you could describe the localization from you POV, like how you down- and later upload data from/to the pootle server. When do you start translation, how do you signal that you have finished translating and the uploaded data is ready for integration? This is easy and I can answer it too: Sun/Oracle used to prepare the data from the sources and uploaded them to a Pootle server; then translation teams would operate on the PO files (online or offline) before an announced "translation deadline"; at that point, control was back in the hands of Sun/Oracle: they used data from the PO files to repopulate the SDF files used in the source. But this probably adds nothing to what you already know: in other words, the code<->Pootle conversions have always been "black boxes" for translation teams. Regards, Andrea.
Re: [RELEASE]: preparation for our first release
On 27.02.2012 14:03, Michael Bauer wrote: Andre, Your mails arrive out-of-thread and I have no idea who wrote the sentence above. Could you check your mail client?That is a good idea. Please go ahead. The answer to your question is: I did not yet have time for it and nobody else did it. Therefore you are welcome to do it. -Andre Sorry, my emails arrive out of thread cause I get the digest and I have yet to discover a means of "replying" to specific strings. The post I was replying to was by Jürgen Schmidt. I see. No problem. Thank you for the invitation - I'd love to but I honestly don't have the right skills. I'm a really good translator but while I have some knowledge of localization from the translator's POV, I still can't do code. And I am a developer with limited knowledge about the localization process. Maybe we can help each other. It would help me, for example, if you could describe the localization from you POV, like how you down- and later upload data from/to the pootle server. When do you start translation, how do you signal that you have finished translating and the uploaded data is ready for integration? -Andre Michael
Re: [RELEASE]: preparation for our first release
Andre, Your mails arrive out-of-thread and I have no idea who wrote the sentence above. Could you check your mail client?That is a good idea. Please go ahead. The answer to your question is: I did not yet have time for it and nobody else did it. Therefore you are welcome to do it. -Andre Sorry, my emails arrive out of thread cause I get the digest and I have yet to discover a means of "replying" to specific strings. The post I was replying to was by Jürgen Schmidt. Thank you for the invitation - I'd love to but I honestly don't have the right skills. I'm a really good translator but while I have some knowledge of localization from the translator's POV, I still can't do code. Michael
Re: [RELEASE]: preparation for our first release
Hi Michael, On 26.02.2012 12:40, Michael Bauer wrote: here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( Your mails arrive out-of-thread and I have no idea who wrote the sentence above. Could you check your mail client? Well, for starters, why don't we get the Pootle server up and running, enable all the languages that were working on localization at the last known date but keep all data "blank". There will be a fair number of locales who have local backups of their latest dataset before the old Pootle server went dead (I know I have) so it would be a simple case of uploading the po files again. That would solve a number of headaches and give people the chance to bring them up to date. That is a good idea. Please go ahead. The answer to your question is: I did not yet have time for it and nobody else did it. Therefore you are welcome to do it. -Andre And *then* worry about the rest. At the moment, everything is dead on the localization side and if a release is being eyed, then the longer that's dead, the worse a headache it becomes for the translators. Michael
Re: [RELEASE]: preparation for our first release
On 2/26/12 12:40 PM, Michael Bauer wrote: here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( Well, for starters, why don't we get the Pootle server up and running, enable all the languages that were working on localization at the last known date but keep all data "blank". There will be a fair number of locales who have local backups of their latest dataset before the old Pootle server went dead (I know I have) so it would be a simple case of uploading the po files again. That would solve a number of headaches and give people the chance to bring them up to date. that is a very important info to know and shows a potential approach. We should start a new thread discussing this further. Juergen And *then* worry about the rest. At the moment, everything is dead on the localization side and if a release is being eyed, then the longer that's dead, the worse a headache it becomes for the translators. Michael
Re: [RELEASE]: preparation for our first release
On Sat, Feb 25, 2012 at 6:07 AM, Ross Gardler wrote: > On 25 February 2012 05:36, Rob Weir wrote: >> On Feb 24, 2012, at 11:05 AM, Ross Gardler >> wrote: >> >>> Without commenting on the dates, schedules and technical issues I >>> would urge you to make sure you allow significant time for IP review >>> from mentors and the IPMC. I imagine this release will get a great >>> deal of attention and, almost without a doubt, someone will come up >>> with something that needs to be addressed. >>> >> >> Mentors and IPMC members have had 8 months to offer IP related >> comments. They are welcome at any time. But in my experience declaring >> a Release Candidate is especially effective at concentrating their >> attention on that task. > > Exactly (this is especially true of those who are not formally mentors). > >> We should plan on having multiple RC iterations. There are enough >> unwritten rules related to release requirements that we'll almost >> certainly need several iterations. > > You've been paying attention to recent discussions on > general@incubator.a.o I see ;-) > > Glad to see this is a part of the release planning process. > >> But the most effective way to >> uncover these unwritten rules is by proposing a RC for a release vote. > > I would caution against this approach, generally a vote (any vote) > should only ever be called when you know it will pass. If you call for > the vote indicating that it is likely to pass because of the process > followed people are less likely to become involved and dredge up a > half dozen edge cases as objections. > > I happen to be be sat with Nick Burch, during a fashion show in a > hotel lobby in Sri Lanka believe it or not! Nick is a very experienced > ASF member who until recently was chair of the POI project, a project > that has experience of being under the IP microscope (he also hit > significant problems with the first ODF Toolkit release). He and I > have been discussing what we believe will be the least painful way of > getting the first AOO release out. Between us we suggest that you > invite the IPMC to start the review now in order to attract as many > interested, but helpful, volunteers as you can. We both feel that by > inviting some key IPMC members to participate now a stronger, more > positive vote can be called later. Votes attract attention from many > more people than requests for assistance. > OK. So this sounds like this can be done with a RC, but without calling a vote on the RC. The first RC can be like a "dress rehearsal". It goes beyond the dev milestone builds in several ways: 1) We include the source packages as well as the binaries 2) We deliver the platforms and languages that we actually intend to release 3) We follow release naming conventions, MD5 hashes, digital signatures, etc. 4) We tag the RC in SVN. 5) If during the informal review of that RC we uncover additional issues then we can spin a new RC2 build, etc. We call for a vote when we stop finding release blocking issues. 6) Generally be sensitive to the maxim: "Every new class of testers finds a new class of bugs". So extended gazing by the same set of reviewers will quickly lead to diminishing returns. Eventually we need to get the release vetted formally, and the vote is what drives that, > Consider sending a mail to general@incubator.a.o along the lines of... > > "The AOO PPMC is getting ready to prepare for our first release. As > you can imagine we have done a great deal of IP work. We believe we > are in good shape and our mentors have been asked to further review > our work. However, we are also aware that releases from the IPMC can > often highlight many grey areas in the legal policies of the ASF. > Outlined below is the process we intend to follow in ensuring that our > first vote on a release candidate is successful, if you are well > versed in Apache policies relating to releases we welcome your input > on this process and invite you to help us review our code prior to our > first RC build and vote." > > I realise this is only a small difference from what you propose with > multiple release candidates. My point is that calling a vote attracts > much more attention than calling for help. Whilst feedback on a vote > is often very useful it can also be contradictory. If we ask for input > from experienced parties and document their recommendations and the > actions taken in the issue tracker we can then refer to this in the > vote, in some cases breaking the deadlock that can occur where > feedback contradicts. > OK. > All that being said. this is just an alternative approach to the > multiple RC approach. There can be no predicting which is will be the > least painless - whichever route is followed there will almost > certainly be pain, even the simplest of projects usually have items > that have been missed by the project community and mentors. > I see no conflict between what you propose and moving to RC1 very soon. What I hear is that we might
Re: [RELEASE]: preparation for our first release
here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( Well, for starters, why don't we get the Pootle server up and running, enable all the languages that were working on localization at the last known date but keep all data "blank". There will be a fair number of locales who have local backups of their latest dataset before the old Pootle server went dead (I know I have) so it would be a simple case of uploading the po files again. That would solve a number of headaches and give people the chance to bring them up to date. And *then* worry about the rest. At the moment, everything is dead on the localization side and if a release is being eyed, then the longer that's dead, the worse a headache it becomes for the translators. Michael
Re: [RELEASE]: preparation for our first release
Am Samstag, 25. Februar 2012 schrieb Ross Gardler : > On 25 February 2012 05:36, Rob Weir > > wrote: > > On Feb 24, 2012, at 11:05 AM, Ross Gardler > > > > wrote: > > > >> Without commenting on the dates, schedules and technical issues I > >> would urge you to make sure you allow significant time for IP review > >> from mentors and the IPMC. I imagine this release will get a great > >> deal of attention and, almost without a doubt, someone will come up > >> with something that needs to be addressed. > >> > > > > Mentors and IPMC members have had 8 months to offer IP related > > comments. They are welcome at any time. But in my experience declaring > > a Release Candidate is especially effective at concentrating their > > attention on that task. > > Exactly (this is especially true of those who are not formally mentors). > > > We should plan on having multiple RC iterations. There are enough > > unwritten rules related to release requirements that we'll almost > > certainly need several iterations. > > You've been paying attention to recent discussions on > general@incubator.a.o I see ;-) > > Glad to see this is a part of the release planning process. > > > But the most effective way to > > uncover these unwritten rules is by proposing a RC for a release vote. > > I would caution against this approach, generally a vote (any vote) > should only ever be called when you know it will pass. If you call for > the vote indicating that it is likely to pass because of the process > followed people are less likely to become involved and dredge up a > half dozen edge cases as objections. > > I happen to be be sat with Nick Burch, during a fashion show in a > hotel lobby in Sri Lanka believe it or not! Nick is a very experienced > ASF member who until recently was chair of the POI project, a project > that has experience of being under the IP microscope (he also hit > significant problems with the first ODF Toolkit release). He and I > have been discussing what we believe will be the least painful way of > getting the first AOO release out. Between us we suggest that you > invite the IPMC to start the review now in order to attract as many > interested, but helpful, volunteers as you can. We both feel that by > inviting some key IPMC members to participate now a stronger, more > positive vote can be called later. Votes attract attention from many > more people than requests for assistance. > > thanks for sharing such thoughts with the broader community. I am happy to get so many useful info which is important for our release by simply using 2 letters "RC" and a potential date. And I would be even more happy if more people would start pro-active helping to prepare a release. I think we can invite the IPMC to take a closer or first look on our next dev snapshots on Tuesday. I will prepare source release snapshots as well. I would like to see at least the rules requirements for an Apache release fulfilled asap to be able to concentrate on the quality. I will be back in HH on Monday and will work on further preparation towards a release ;-) Juergen > Consider sending a mail to general@incubator.a.o along the lines of... > > "The AOO PPMC is getting ready to prepare for our first release. As > you can imagine we have done a great deal of IP work. We believe we > are in good shape and our mentors have been asked to further review > our work. However, we are also aware that releases from the IPMC can > often highlight many grey areas in the legal policies of the ASF. > Outlined below is the process we intend to follow in ensuring that our > first vote on a release candidate is successful, if you are well > versed in Apache policies relating to releases we welcome your input > on this process and invite you to help us review our code prior to our > first RC build and vote." > > I realise this is only a small difference from what you propose with > multiple release candidates. My point is that calling a vote attracts > much more attention than calling for help. Whilst feedback on a vote > is often very useful it can also be contradictory. If we ask for input > from experienced parties and document their recommendations and the > actions taken in the issue tracker we can then refer to this in the > vote, in some cases breaking the deadlock that can occur where > feedback contradicts. > > All that being said. this is just an alternative approach to the > multiple RC approach. There can be no predicting which is will be the > least painless - whichever route is followed there will almost > certainly be pain, even the simplest of projects usually have items > that have been missed by the project community and mentors. > > > Of course we should first make sure were following all the written > > rules. > > I think, in this respect, the project is doing well. Although I have > not yet done my own complete review. > > Ross >
Re: [RELEASE]: preparation for our first release
Am Samstag, 25. Februar 2012 schrieb O.Felka : > Am 25.02.2012 01:06, schrieb Rob Weir: > >> On Feb 24, 2012, at 11:05 AM, Ross Gardler >> wrote: >> >> Without commenting on the dates, schedules and technical issues I >>> would urge you to make sure you allow significant time for IP review >>> from mentors and the IPMC. I imagine this release will get a great >>> deal of attention and, almost without a doubt, someone will come up >>> with something that needs to be addressed. >>> >>> >> Mentors and IPMC members have had 8 months to offer IP related >> comments. They are welcome at any time. But in my experience declaring >> a Release Candidate is especially effective at concentrating their >> attention on that task. >> >> We should plan on having multiple RC iterations. There are enough >> unwritten rules related to release requirements that we'll almost >> certainly need several iterations. But the most effective way to >> uncover these unwritten rules is by proposing a RC for a release vote. >> > > A release by votes? Wouldn't it be better to have some > concrete release criteria? > Having some quality goals that must be reached? it is not contradictory and have I pointed out that we don't release if there are valid concerns. We will release when we don't have critical show stopper issues. And discussion on show stopper issues should take place on ooo-dev when issues marked as critical. I don't think we have to define the rules for show stopper issues again and can use the existing ones (e.g. crashes, data loss, ...) I hope people will take it serious and don't vote against a release without valid concerns. Juergen > Groetjes, > Olaf >
Re: [RELEASE]: preparation for our first release
2012/2/24 Jürgen Schmidt > Hi, > > we move closer forward to our first release. > > I would like to suggest that we focus on the following areas next week. > And I would like to propose the following schedule depending on the > progress we will make next week. > > > Monday: Feb. 27th new dev snapshots > Monday: March 5th first RC candidate (based on the progress next week) > > Jürgen -- Good goals and good luck to us! I will certainly do what I can next week to make this happen! As you (and others) have pointed out, a working 3.4 of OpenOffice.org existed as early as last April or May . Hopefully, the substitutions to make Apache OpenOffice IP ready have been successful. I am looking forward to learning more about the distribution/packaging process and producing a successful Apache OpenOffice release. - increase QA work > - focus on stabilization, means focus on showstopper issues > - finalize the About dialog information, input for future bug reports > - online update service > > - updating building guides in the wiki > > > - documentation update can be run in parallel and are independent of the > binary release > - translation update, we have made minimal UI changes only and we will use > the 3.4 beta translation that were in place. > > Anything else that comes into your minds? > > I have started to work on the MacOS building guide and have simplified > some things (work ongoing). > > We need some volunteers who take a look on the other platforms. Especially > reference to the hg repo should be removed/replaced to our svn repo. > Information about childworkspaces can be removed because it is not longer > relevant for us. I would say the focus should be on simplification. > > What do others think about it? > > Juergen > -- MzK "Follow your bliss." -- attributed to Joseph Campbell
Re: [RELEASE]: preparation for our first release
On 25 February 2012 16:56, O.Felka wrote: > Am 25.02.2012 01:06, schrieb Rob Weir: > >> On Feb 24, 2012, at 11:05 AM, Ross Gardler >> wrote: >> >>> Without commenting on the dates, schedules and technical issues I >>> would urge you to make sure you allow significant time for IP review >>> from mentors and the IPMC. I imagine this release will get a great >>> deal of attention and, almost without a doubt, someone will come up >>> with something that needs to be addressed. >>> >> >> Mentors and IPMC members have had 8 months to offer IP related >> comments. They are welcome at any time. But in my experience declaring >> a Release Candidate is especially effective at concentrating their >> attention on that task. >> >> We should plan on having multiple RC iterations. There are enough >> unwritten rules related to release requirements that we'll almost >> certainly need several iterations. But the most effective way to >> uncover these unwritten rules is by proposing a RC for a release vote. > > > A release by votes? Wouldn't it be better to have some > concrete release criteria? > Having some quality goals that must be reached? It is expected that the release vote is only called for after the release criteria and quality goals have been agreed upon and delivered by the (P)PMC. In the ASF anyone can create and publish a release as long as there are no legal barriers to that release and the majority of the PPMC wish to see the release proceed. A release cannot be vetoed unless for supported legal reasons. Objections based on quality and features only count towards a majority. Again, my comments above are based on the assumption that the PPMC (or someone willing to be release manager) believes there would be a majority in favour of a release and therefore the vote is simply to indicate, as far as is possible, sufficient oversight to allow the ASF to protect its committers in the event of a legal problem. Don't confuse voting with decision making. We don't make decisions with votes, we make decisions with actions. If someone wants a specific feature or quality improvement in a release the only way to ensure it is there to implement it. Ross
Re: [RELEASE]: preparation for our first release
Am 25.02.2012 01:06, schrieb Rob Weir: On Feb 24, 2012, at 11:05 AM, Ross Gardler wrote: Without commenting on the dates, schedules and technical issues I would urge you to make sure you allow significant time for IP review from mentors and the IPMC. I imagine this release will get a great deal of attention and, almost without a doubt, someone will come up with something that needs to be addressed. Mentors and IPMC members have had 8 months to offer IP related comments. They are welcome at any time. But in my experience declaring a Release Candidate is especially effective at concentrating their attention on that task. We should plan on having multiple RC iterations. There are enough unwritten rules related to release requirements that we'll almost certainly need several iterations. But the most effective way to uncover these unwritten rules is by proposing a RC for a release vote. A release by votes? Wouldn't it be better to have some concrete release criteria? Having some quality goals that must be reached? Groetjes, Olaf
Re: [RELEASE]: preparation for our first release
On 25 February 2012 07:54, Pedro Giffuni wrote: > On 02/24/12 11:04, Ross Gardler wrote: >> >> Without commenting on the dates, schedules and technical issues I >> would urge you to make sure you allow significant time for IP review >> from mentors and the IPMC. I imagine this release will get a great >> deal of attention and, almost without a doubt, someone will come up >> with something that needs to be addressed. >> >> Ross > > > As you know I have pointed out issues there but I am more > concerned that we really need to put out a release and give > signs of life soon. > > About how much time would be sufficient for the IP > review, and is there something we can do to help that > out? The earlier we start the review the sooner the release will take place. If the project believes it is ready then now, before the RC is rolled, is the best time to start the review (see my other mail, with a more detailed suggestion in reply to Rob). In terms of "how long". Once a review is requested you will need to allow a minimum of 72 hours, but expect some late comments. Unfortunately the real problem occurs when there are contradictory opinions, these contradictions need to be resolved. Shouting at one another about the intent of written policy or expecting the other person to back down because your voice is louder will only serve to crete entrenched positions that can take a long time. The thing to do is to take the *specifics* of the case in question to a JIRA issue for the legal team, provide links to policies both parties believe are relevant and ask for guidance. The legal team are, in many cases, very prompt, but sometimes this process can be slow. The sooner these specific cases get into the legal Jira the better. The PPMC here needs to be pro-active in identifying any such cases as early as possible. Waiting for an RC to be built will only delay things if such cases exist. > Please note that we have open JIRA issues that need to be > resolved: at least the copyleft dictionaries and the OFL are > issues that we identified long ago. Exactly my point, although I was not referring to any specific issues. My observations are more general in nature. Ross > > best regards, > > Pedro. -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
On 25 February 2012 05:36, Rob Weir wrote: > On Feb 24, 2012, at 11:05 AM, Ross Gardler wrote: > >> Without commenting on the dates, schedules and technical issues I >> would urge you to make sure you allow significant time for IP review >> from mentors and the IPMC. I imagine this release will get a great >> deal of attention and, almost without a doubt, someone will come up >> with something that needs to be addressed. >> > > Mentors and IPMC members have had 8 months to offer IP related > comments. They are welcome at any time. But in my experience declaring > a Release Candidate is especially effective at concentrating their > attention on that task. Exactly (this is especially true of those who are not formally mentors). > We should plan on having multiple RC iterations. There are enough > unwritten rules related to release requirements that we'll almost > certainly need several iterations. You've been paying attention to recent discussions on general@incubator.a.o I see ;-) Glad to see this is a part of the release planning process. > But the most effective way to > uncover these unwritten rules is by proposing a RC for a release vote. I would caution against this approach, generally a vote (any vote) should only ever be called when you know it will pass. If you call for the vote indicating that it is likely to pass because of the process followed people are less likely to become involved and dredge up a half dozen edge cases as objections. I happen to be be sat with Nick Burch, during a fashion show in a hotel lobby in Sri Lanka believe it or not! Nick is a very experienced ASF member who until recently was chair of the POI project, a project that has experience of being under the IP microscope (he also hit significant problems with the first ODF Toolkit release). He and I have been discussing what we believe will be the least painful way of getting the first AOO release out. Between us we suggest that you invite the IPMC to start the review now in order to attract as many interested, but helpful, volunteers as you can. We both feel that by inviting some key IPMC members to participate now a stronger, more positive vote can be called later. Votes attract attention from many more people than requests for assistance. Consider sending a mail to general@incubator.a.o along the lines of... "The AOO PPMC is getting ready to prepare for our first release. As you can imagine we have done a great deal of IP work. We believe we are in good shape and our mentors have been asked to further review our work. However, we are also aware that releases from the IPMC can often highlight many grey areas in the legal policies of the ASF. Outlined below is the process we intend to follow in ensuring that our first vote on a release candidate is successful, if you are well versed in Apache policies relating to releases we welcome your input on this process and invite you to help us review our code prior to our first RC build and vote." I realise this is only a small difference from what you propose with multiple release candidates. My point is that calling a vote attracts much more attention than calling for help. Whilst feedback on a vote is often very useful it can also be contradictory. If we ask for input from experienced parties and document their recommendations and the actions taken in the issue tracker we can then refer to this in the vote, in some cases breaking the deadlock that can occur where feedback contradicts. All that being said. this is just an alternative approach to the multiple RC approach. There can be no predicting which is will be the least painless - whichever route is followed there will almost certainly be pain, even the simplest of projects usually have items that have been missed by the project community and mentors. > Of course we should first make sure were following all the written > rules. I think, in this respect, the project is doing well. Although I have not yet done my own complete review. Ross
Re: [RELEASE]: preparation for our first release
Hi Ross; On 02/24/12 11:04, Ross Gardler wrote: Without commenting on the dates, schedules and technical issues I would urge you to make sure you allow significant time for IP review from mentors and the IPMC. I imagine this release will get a great deal of attention and, almost without a doubt, someone will come up with something that needs to be addressed. Ross As you know I have pointed out issues there but I am more concerned that we really need to put out a release and give signs of life soon. About how much time would be sufficient for the IP review, and is there something we can do to help that out? Please note that we have open JIRA issues that need to be resolved: at least the copyleft dictionaries and the OFL are issues that we identified long ago. best regards, Pedro.
Re: [RELEASE]: preparation for our first release
On Feb 24, 2012, at 11:05 AM, Ross Gardler wrote: > Without commenting on the dates, schedules and technical issues I > would urge you to make sure you allow significant time for IP review > from mentors and the IPMC. I imagine this release will get a great > deal of attention and, almost without a doubt, someone will come up > with something that needs to be addressed. > Mentors and IPMC members have had 8 months to offer IP related comments. They are welcome at any time. But in my experience declaring a Release Candidate is especially effective at concentrating their attention on that task. We should plan on having multiple RC iterations. There are enough unwritten rules related to release requirements that we'll almost certainly need several iterations. But the most effective way to uncover these unwritten rules is by proposing a RC for a release vote. Of course we should first make sure were following all the written rules. -Rob > Ross > > 2012/2/24 Jürgen Schmidt : >> Hi, >> >> we move closer forward to our first release. >> >> I would like to suggest that we focus on the following areas next week. And >> I would like to propose the following schedule depending on the progress we >> will make next week. >> >> >> Monday: Feb. 27th new dev snapshots >> Monday: March 5th first RC candidate (based on the progress next week) >> >> - increase QA work >> - focus on stabilization, means focus on showstopper issues >> - finalize the About dialog information, input for future bug reports >> - online update service >> >> - updating building guides in the wiki >> >> >> - documentation update can be run in parallel and are independent of the >> binary release >> - translation update, we have made minimal UI changes only and we will use >> the 3.4 beta translation that were in place. >> >> Anything else that comes into your minds? >> >> I have started to work on the MacOS building guide and have simplified some >> things (work ongoing). >> >> We need some volunteers who take a look on the other platforms. Especially >> reference to the hg repo should be removed/replaced to our svn repo. >> Information about childworkspaces can be removed because it is not longer >> relevant for us. I would say the focus should be on simplification. >> >> What do others think about it? >> >> Juergen > > > > -- > Ross Gardler (@rgardler) > Programme Leader (Open Development) > OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
Without commenting on the dates, schedules and technical issues I would urge you to make sure you allow significant time for IP review from mentors and the IPMC. I imagine this release will get a great deal of attention and, almost without a doubt, someone will come up with something that needs to be addressed. Ross 2012/2/24 Jürgen Schmidt : > Hi, > > we move closer forward to our first release. > > I would like to suggest that we focus on the following areas next week. And > I would like to propose the following schedule depending on the progress we > will make next week. > > > Monday: Feb. 27th new dev snapshots > Monday: March 5th first RC candidate (based on the progress next week) > > - increase QA work > - focus on stabilization, means focus on showstopper issues > - finalize the About dialog information, input for future bug reports > - online update service > > - updating building guides in the wiki > > > - documentation update can be run in parallel and are independent of the > binary release > - translation update, we have made minimal UI changes only and we will use > the 3.4 beta translation that were in place. > > Anything else that comes into your minds? > > I have started to work on the MacOS building guide and have simplified some > things (work ongoing). > > We need some volunteers who take a look on the other platforms. Especially > reference to the hg repo should be removed/replaced to our svn repo. > Information about childworkspaces can be removed because it is not longer > relevant for us. I would say the focus should be on simplification. > > What do others think about it? > > Juergen -- Ross Gardler (@rgardler) Programme Leader (Open Development) OpenDirective http://opendirective.com
Re: [RELEASE]: preparation for our first release
On 2012/02/24 18:23, Jürgen Schmidt said: > Monday: Feb. 27th new dev snapshots > Monday: March 5th first RC candidate (based on the progress next week) > Anything else that comes into your minds? It's nice to see this. But is the translation platform ready? I believe the text messages related to "Pivot Table" is still not translated for Traditional Chinese, for either the Pootle or Mercurial version. This means the translation need to be revised before we may release. -- Best regards, imacat ^_*' PGP Key http://www.imacat.idv.tw/me/pgpkey.asc <> News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ Apache OpenOffice http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ signature.asc Description: OpenPGP digital signature
Re: [RELEASE]: preparation for our first release
On 2/24/12 1:36 PM, Rory O'Farrell wrote: On Fri, 24 Feb 2012 13:28:54 +0100 Jürgen Schmidt wrote: Raphael, you should keep in mind that we had a 3.4 beta already last year. We have removed things or have replaced things. And for both do we have tested it since weeks. If we figure further critical issues than we will fix it and will potentially move the date. Sorry - last posting escaped! I'd be happier if the proposed release was 3.4 Beta 2, even if that progressed to RC1 within a short period. To proceed from Beta 1 to RC1 after such a massive rebuild may suggest over-confidence. I think we are flexible here and can agree on a name. Important is from my point of view that we are aligned and can all support it. If somebody have valid concerns then please raise these concerns clearly based on facts or better submit Issues. Juergen
Re: [RELEASE]: preparation for our first release
On Fri, 24 Feb 2012 13:28:54 +0100 Jürgen Schmidt wrote: > Raphael, you should keep in mind that we had a 3.4 beta already > last year. We have removed things or have replaced things. And > for both do we have tested it since weeks. If we figure further > critical issues than we will fix it and will potentially move > the date. Sorry - last posting escaped! I'd be happier if the proposed release was 3.4 Beta 2, even if that progressed to RC1 within a short period. To proceed from Beta 1 to RC1 after such a massive rebuild may suggest over-confidence. -- Rory O'Farrell
Re: [RELEASE]: preparation for our first release
On Fri, 24 Feb 2012 13:28:54 +0100 > Raphael, you should keep in mind that we had a 3.4 beta already > last year. We have removed things or have replaced things. And > for both do we have tested it since weeks. If we figure further > critical issues than we will fix it and will potentially move > the date. I -- Rory O'Farrell
Re: [RELEASE]: preparation for our first release
On 2/24/12 12:37 PM, Raphael Bircher wrote: Am 24.02.12 11:23, schrieb Jürgen Schmidt: Hi, we move closer forward to our first release. I would like to suggest that we focus on the following areas next week. And I would like to propose the following schedule depending on the progress we will make next week. Monday: Feb. 27th new dev snapshots Monday: March 5th first RC candidate (based on the progress next week) - 1000 you have only 1 vote ;-) Sorry Jürgen, this plan is so far away from reality. We have this Week last feature integration, and you will do a RC in a bit more then a Week? Where you plane all the QA work? As QA I can't support a Release like this. We need one month time between last feature integration and Release for a minimum. Else you don't have time to perform serios tests. this conclusion is based on what? Can you explain it please further? Raphael, you should keep in mind that we had a 3.4 beta already last year. We have removed things or have replaced things. And for both do we have tested it since weeks. If we figure further critical issues than we will fix it and will potentially move the date. Non critical issues will be moved to later because we have to set priorities. We have always more issues that we can fix. And I hope that we all agree that we have to provide a release to signal that our project is alive and can deliver. I would strongly recommend that we plan to release as soon as possible. We might have a missing string or not 100% updated help files. But that is not different to any other release in the past. The most important thing is stability, that we don't crash and things work as expected. Sorry, that I have not much positiv feedback today. But I'm interested in a Apache OpenOffice with height quality and so I take my job as QA serios. it's the same for me and hopefully all of and I don't say that we will release it anyway. Fine that you will focus on QA now and that you will help us to find critical issues. Juergen
Re: [RELEASE]: preparation for our first release
On 24.02.2012 12:40, Andrea Pescetti wrote: Jürgen Schmidt wrote: RC should be used indeed only if we think that it can be released, and this depends on the progress ;-) Perfect. Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still not solved ... here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( OK, but still a Writer context menu like the one shown in https://issues.apache.org/ooo/attachment.cgi?id=77204 (it's supposed to be German) is clearly a release blocker. I'll have a look at the data Andre Fischer provided as soon as possible, and I'll ask our localization people to check whether we (meaning both the AOO project and our translation team, from possible backups) have the latest strings for Italian, that has more or less the same problems shown in the German screenshot above. That would be great. I hope that next week I find the time to look at the issue and find out a) if the translation(s) is (are) present and b) how much work it is to integrate it. -Andre Regards, Andrea.
Re: [RELEASE]: preparation for our first release
On 2/24/12 12:40 PM, Andrea Pescetti wrote: Jürgen Schmidt wrote: RC should be used indeed only if we think that it can be released, and this depends on the progress ;-) Perfect. Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still not solved ... here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( OK, but still a Writer context menu like the one shown in https://issues.apache.org/ooo/attachment.cgi?id=77204 (it's supposed to be German) is clearly a release blocker. I'll have a look at the data Andre Fischer provided as soon as possible, and I'll ask our localization people to check whether we (meaning both the AOO project and our translation team, from possible backups) have the latest strings for Italian, that has more or less the same problems shown in the German screenshot above. perfect because we need the feedback here from people who understand the strings ;-) Based on this we can probably do a one time conversion from po to sdf directly. But we need to know which data we have to use. Improving and establishing a working translating process will be a high prio for the future. Juergen Regards, Andrea.
Re: [RELEASE]: preparation for our first release
Jürgen Schmidt wrote: RC should be used indeed only if we think that it can be released, and this depends on the progress ;-) Perfect. Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still not solved ... here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( OK, but still a Writer context menu like the one shown in https://issues.apache.org/ooo/attachment.cgi?id=77204 (it's supposed to be German) is clearly a release blocker. I'll have a look at the data Andre Fischer provided as soon as possible, and I'll ask our localization people to check whether we (meaning both the AOO project and our translation team, from possible backups) have the latest strings for Italian, that has more or less the same problems shown in the German screenshot above. Regards, Andrea.
Re: [RELEASE]: preparation for our first release
Am 24.02.12 11:23, schrieb Jürgen Schmidt: Hi, we move closer forward to our first release. I would like to suggest that we focus on the following areas next week. And I would like to propose the following schedule depending on the progress we will make next week. Monday: Feb. 27th new dev snapshots Monday: March 5th first RC candidate (based on the progress next week) - 1000 Sorry Jürgen, this plan is so far away from reality. We have this Week last feature integration, and you will do a RC in a bit more then a Week? Where you plane all the QA work? As QA I can't support a Release like this. We need one month time between last feature integration and Release for a minimum. Else you don't have time to perform serios tests. Sorry, that I have not much positiv feedback today. But I'm interested in a Apache OpenOffice with height quality and so I take my job as QA serios. Greetings Raphael
Re: [RELEASE]: preparation for our first release
On 2/24/12 11:53 AM, Andrea Pescetti wrote: On 24/02/2012 Jürgen Schmidt wrote: And I would like to propose the following schedule depending on the progress we will make next week. Monday: Feb. 27th new dev snapshots Monday: March 5th first RC candidate (based on the progress next week) This is (of course) great and exciting news. I would only recommend to avoid the temptation to be marketing-driven... let RC1 be something that we believe we could actually release. There's nothing bad in using the name "dev" or "beta" for something that is not ready yet. This is how I interpret the "depending on progress" above, and it would be very good and show respect for users. RC should be used indeed only if we think that it can be released, and this depends on the progress ;-) - translation update, we have made minimal UI changes only and we will use the 3.4 beta translation that were in place. Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still not solved: it might be that the 3.4 beta translations are not integrated in our current dev builds, or, more likely, that language packs are not being built correctly. I've just set that issue as a release blocker. Using the 3.4-beta translations would be OK, but we need the full set, not what we have now (see issue page). here we might run into a problem because of not having the translation process in place 100%. We have to figure out which translation data is the latest one, it's still not 100% clear if we really have it :-( We will also need to: - Decide the URLs for all links in the suite (Extensions, Templates, Suite Updates, Extensions Updates...). I hope the links wouldn't really change, but it have to be clarified - Describe the 3.3 -> 3.4 migration path; it would be good to avoid the need to reinstall extensions, but I don't know the current state of the art here. that can't be avoided because of the removed berkeley DB. Not nice but we can't avoid it. Juergen
Re: [RELEASE]: preparation for our first release
On 24/02/2012 Jürgen Schmidt wrote: And I would like to propose the following schedule depending on the progress we will make next week. Monday: Feb. 27th new dev snapshots Monday: March 5th first RC candidate (based on the progress next week) This is (of course) great and exciting news. I would only recommend to avoid the temptation to be marketing-driven... let RC1 be something that we believe we could actually release. There's nothing bad in using the name "dev" or "beta" for something that is not ready yet. This is how I interpret the "depending on progress" above, and it would be very good and show respect for users. - translation update, we have made minimal UI changes only and we will use the 3.4 beta translation that were in place. Note that https://issues.apache.org/ooo/show_bug.cgi?id=118895 is still not solved: it might be that the 3.4 beta translations are not integrated in our current dev builds, or, more likely, that language packs are not being built correctly. I've just set that issue as a release blocker. Using the 3.4-beta translations would be OK, but we need the full set, not what we have now (see issue page). We will also need to: - Decide the URLs for all links in the suite (Extensions, Templates, Suite Updates, Extensions Updates...). - Describe the 3.3 -> 3.4 migration path; it would be good to avoid the need to reinstall extensions, but I don't know the current state of the art here. Regards, Andrea.
[RELEASE]: preparation for our first release
Hi, we move closer forward to our first release. I would like to suggest that we focus on the following areas next week. And I would like to propose the following schedule depending on the progress we will make next week. Monday: Feb. 27th new dev snapshots Monday: March 5th first RC candidate (based on the progress next week) - increase QA work - focus on stabilization, means focus on showstopper issues - finalize the About dialog information, input for future bug reports - online update service - updating building guides in the wiki - documentation update can be run in parallel and are independent of the binary release - translation update, we have made minimal UI changes only and we will use the 3.4 beta translation that were in place. Anything else that comes into your minds? I have started to work on the MacOS building guide and have simplified some things (work ongoing). We need some volunteers who take a look on the other platforms. Especially reference to the hg repo should be removed/replaced to our svn repo. Information about childworkspaces can be removed because it is not longer relevant for us. I would say the focus should be on simplification. What do others think about it? Juergen
