Re: [RELEASE]: preparation for AOO 4.0.1
On 8/13/13 6:55 PM, Ricardo Berlasso wrote: 2013/8/13 Fernando Cassia fcas...@gmail.com On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt jogischm...@gmail.com wrote: But if we change it it annoys potentially other users. The question is what would be the correct and most often wanted default. What is the purpose of showing margins, and by extension, seeing text smaller, (less zoom level)?. Is there any data the user can put on Margins? change the margin colors? put pictures in margins?. In short: what use is there for margins taking a sizeable portion of the screen size? I do not see those margin you talk about and for a good reason: I never use maximized windows. I hate maximized windows. Other people love maximized windows, of course, but many of us just hate them: how do you count how many people is on each camp? Default values are an important discussion point and I started a couple of threads about defaults in the past, but defaults are also an incredible difficult question where almost all possible answers are at the same time wrong and right for someone. I propose to start (again) a discussion about default values, but not now: let's concentrate on 4.0.1. please start a new thread for this topic. It's a feature/enhancement discussion and doesn't belong to the topic of this thread Thanks Juergen Regards Ricardo I'm not saying we should NOT show margings, after all, in Optimal width, a portion of the margins is seen, but not 50-100 pixels of them, on every side. I'm not even saying the view with margins is wrong, maybe someone wants to look at the bigger picture. But for TYPING text, optimal width is the best. So, again, why isn't that option the default?. Maybe the UX guys can comment?. And yes, I'd love to see a survey. And even better, some telemetry (like Firefox' ) about how many users, when typing or browsing text documents, end up viewing the document in optimize width mode). Thanks for taking the time to answer, btw. Appreciate it. Best regards, FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. rgds jan I. -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On 8/13/13 3:26 PM, janI wrote: On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. indeed UI changes are not allowed for a micro update, only bugfixes. New features should be implemented on trunk for AOO 4.1 I is so natural for me that I forgot to mention this explicitly Juergen Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. no, the name contains the new version Juergen rgds jan I. -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
Hi, I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. sorry, but maybe I'm not understanding something; why do AOO400 (which is a branch) fixes going into next release (AOO401) require another branch? I committed to AOO400 because I supposed that newer (minor) releases were going into this branch, not into a different one. And I don't undestand at all why branching again for 401, while we can just use tagging to monitor minor bugfixes releases from AOO400 branch. I understand that a 4.1 release will incorporate new code while we can still produce 4.0.2 on the older branch, so branching for 4.1 makes more sense. with this branching tecnique, a bugfix must be sideported to every active branch, e.g. trunk, AOO401, AOO410 (maybe more in the future). If I missed some guideline doc on the wiki please excuse me. thanks, -- Bye, Yuri Dario /* * OS/2 open source software * http://web.os2power.com/yuri * http://www.netlabs.org */ - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? Is there a chance to get a fix so that AOO 4.0.1 starts properly maximized ALL THE TIME? On Windows at least (Win7 64bit) it didn't. Of course after maximizing it, it started maximized after the fact (probably reading the last window size from some saved preference, but the fact that it doesn't automagically maximize its window annoys me. Is there a bug report for this? Anyone else seen this? Any rationale for the app not starting maximized?. On a related note, the first thing I do (since the StarOffice 3.1 days) when I open a new document is set zoom level to Optimal (or optimize width, I'm not sure right now how it's called). Why isn't this the default is beyond me. Otherwise, with the standard zoom level lots of horizontal screen real state is wasted. Thoughts? Comments? Expletives? ;) FC - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On Tue, Aug 13, 2013 at 6:26 AM, janI j...@apache.org wrote: On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 For 3.4.1, which was basically an update release with addtional languages, the release notes were sort of like an addendum to 3.4.0 -- https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes I think Release Notes for 4.0.1 should be similar but, yes, we need a new page for them. I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. rgds jan I. -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
Re: [RELEASE]: preparation for AOO 4.0.1
On 8/13/13 5:55 PM, Yuri Dario wrote: Hi, I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. sorry, but maybe I'm not understanding something; why do AOO400 (which is a branch) fixes going into next release (AOO401) require another branch? I committed to AOO400 because I supposed that newer (minor) releases were going into this branch, not into a different one. And I don't undestand at all why branching again for 401, while we can just use tagging to monitor minor bugfixes releases from AOO400 branch. we simply preserve the release branch. A branch is cheap in svn and we can easier differentiate where the fixes should go. I understand that a 4.1 release will incorporate new code while we can still produce 4.0.2 on the older branch, so branching for 4.1 makes more sense. well we can of course discuss this further but because the fact that branches are cheap we can also use this scheme. with this branching tecnique, a bugfix must be sideported to every active branch, e.g. trunk, AOO401, AOO410 (maybe more in the future). why? We don't have a 4.1 branch and fixes only have to be merged in a branch if they are accepted showstopper. Now with the new branch nobody should work on the AOO400 branch. The branch is dead for further development. Work towards 4.1 should happen on trunk. Major features should be done on a separate branch anyway. If I missed some guideline doc on the wiki please excuse me. No you don't miss any guideline and again we can discuss it. But it change nothing. Either AOO400 or AOO401 in both cases you should integrate only code that are related to an existing issue which is proposed and accepted as showstopper. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On 8/13/13 6:01 PM, Fernando Cassia wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? Is there a chance to get a fix so that AOO 4.0.1 starts properly maximized ALL THE TIME? On Windows at least (Win7 64bit) it didn't. Of course after maximizing it, it started maximized after the fact (probably reading the last window size from some saved preference, but the fact that it doesn't automagically maximize its window annoys me. Is there a bug report for this? Anyone else seen this? Any rationale for the app not starting maximized?. On a related note, the first thing I do (since the StarOffice 3.1 days) when I open a new document is set zoom level to Optimal (or optimize width, I'm not sure right now how it's called). Why isn't this the default is beyond me. Otherwise, with the standard zoom level lots of horizontal screen real state is wasted. Thoughts? Comments? Expletives? ;) Probably not, it's mainly your personal preference which is fine. But if we change it it annoys potentially other users. The question is what would be the correct and most often wanted default. These are questions that we can't answer easy. We can run a survey and will potentially get a 60:40, 70:30 or 50:50 answer that won't help us. But you can try to figure out the related config item and can create a mini extension that you deploy in your office to use a different default. Don't ask me which config item is relevant here, I don't know without looking into the code. Juergen FC - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On Tue, 13 Aug 2013 12:43:47 -0400 Fernando Cassia fcas...@gmail.com wrote: On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt jogischm...@gmail.com wrote: But if we change it it annoys potentially other users. The question is what would be the correct and most often wanted default. What is the purpose of showing margins, and by extension, seeing text smaller, (less zoom level)?. Is there any data the user can put on Margins? change the margin colors? put pictures in margins?. In short: what use is there for margins taking a sizeable portion of the screen size? I'm not saying we should NOT show margings, after all, in Optimal width, a portion of the margins is seen, but not 50-100 pixels of them, on every side. I'm not even saying the view with margins is wrong, maybe someone wants to look at the bigger picture. But for TYPING text, optimal width is the best. So, again, why isn't that option the default?. Maybe the UX guys can comment?. And yes, I'd love to see a survey. And even better, some telemetry (like Firefox' ) about how many users, when typing or browsing text documents, end up viewing the document in optimize width mode). Thanks for taking the time to answer, btw. Appreciate it. Best regards, FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell Comments can live on the desktop beyond the right margin setting. Also, the margins help one see what the finished page will look like. -- Rory O'Farrell ofarr...@iol.ie - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
2013/8/13 Fernando Cassia fcas...@gmail.com On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt jogischm...@gmail.com wrote: But if we change it it annoys potentially other users. The question is what would be the correct and most often wanted default. What is the purpose of showing margins, and by extension, seeing text smaller, (less zoom level)?. Is there any data the user can put on Margins? change the margin colors? put pictures in margins?. In short: what use is there for margins taking a sizeable portion of the screen size? I do not see those margin you talk about and for a good reason: I never use maximized windows. I hate maximized windows. Other people love maximized windows, of course, but many of us just hate them: how do you count how many people is on each camp? Default values are an important discussion point and I started a couple of threads about defaults in the past, but defaults are also an incredible difficult question where almost all possible answers are at the same time wrong and right for someone. I propose to start (again) a discussion about default values, but not now: let's concentrate on 4.0.1. Regards Ricardo I'm not saying we should NOT show margings, after all, in Optimal width, a portion of the margins is seen, but not 50-100 pixels of them, on every side. I'm not even saying the view with margins is wrong, maybe someone wants to look at the bigger picture. But for TYPING text, optimal width is the best. So, again, why isn't that option the default?. Maybe the UX guys can comment?. And yes, I'd love to see a survey. And even better, some telemetry (like Firefox' ) about how many users, when typing or browsing text documents, end up viewing the document in optimize width mode). Thanks for taking the time to answer, btw. Appreciate it. Best regards, FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
Kay Schenk wrote: On Tue, Aug 13, 2013 at 6:26 AM, janI j...@apache.org wrote: On 13 August 2013 15:14, Rob Weir robw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt jogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 For 3.4.1, which was basically an update release with addtional languages, the release notes were sort of like an addendum to 3.4.0 -- https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes I think Release Notes for 4.0.1 should be similar but, yes, we need a new page for them. I agree, the release notes for 4.0.1 should have there own page documenting the changes for that release only with a link to the full 4.0.0 notes. Regards Keith I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. rgds jan I. -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
Am 08/13/2013 06:13 PM, schrieb Kay Schenk: On Tue, Aug 13, 2013 at 6:26 AM, janIj...@apache.org wrote: On 13 August 2013 15:14, Rob Weirrobw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidtjogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 I'm fine with another round. In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 For 3.4.1, which was basically an update release with addtional languages, the release notes were sort of like an addendum to 3.4.0 -- https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes I think Release Notes for 4.0.1 should be similar but, yes, we need a new page for them. +1 In general refer to the 4.0.0 release notes and add just the new things. The 3.4.1 release notes are a good example. Marcus I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. rgds jan I. -Rob Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: preparation for AOO 4.0.1
On Tue, Aug 13, 2013 at 12:01 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 08/13/2013 06:13 PM, schrieb Kay Schenk: On Tue, Aug 13, 2013 at 6:26 AM, janIj...@apache.org wrote: On 13 August 2013 15:14, Rob Weirrobw...@apache.org wrote: On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidtjogischm...@gmail.com wrote: Hi, first if all I volunteer to act as the release manager for AOO 4.0.1 if that is wanted but I am also open to let somebody else to the job ;-) It is probably best if you continue, since 4.0.1 is very closely related to 4.0.0, and you already have the build environment set up, etc. +1 I'm fine with another round. In preparation for an AOO 4.0.1 release I have first created a AOO400 tag based on revision 1503704. I have also created a new branch AOO401 based on branch AOO400 based on the head revision of the branch. I noticed that Yuri checked in some code on the branch already. Can we please follow some guideline how we handle such release branches? I would like to propose the following: Changes on a release branch should be discussed before and should be in relation to a proposed and approved fix (if you want showstopper) that will go in the next release. For now that means the branch AOO400 is dead and changes towards AOO 4.0.1 have to be made on the new branch AOO401 and should be discussed first. Or propose the related issue as showstopper first. I believe we agreed more or less to keep the changes for AOO 4.0.1 minimal to reduce the test effort. We should concentrate on the most serious issues only and on new languages or improved translations. Keep in mind that AOO 4.1 is coming as well. Stability is a key feature and every single bug fix can introduce a regression as well. Often not obvious directly. I assume we also want to avoid introducing new UI strings? Otherwise we'd require translation updates on all languages. I would formulate it stronger: we cannot allow new strings, unless it is absolutely unavoidable. Any opinions or comment son this plan. Should we create new Release Notes? Or augment the existing 4.0.0 ones? It might be simpler if 4.0.x releases share the same release notes, but we start with fresh ones for 4.1? Lets share release notes, amend so that is clear what is only available in 4.0.1, and start from a fresh with 4.1 For 3.4.1, which was basically an update release with addtional languages, the release notes were sort of like an addendum to 3.4.0 -- https://cwiki.apache.org/**confluence/display/OOOUSERS/** AOO+3.4.1+Release+Noteshttps://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes I think Release Notes for 4.0.1 should be similar but, yes, we need a new page for them. +1 In general refer to the 4.0.0 release notes and add just the new things. The 3.4.1 release notes are a good example. Marcus I took the liberty of setting up a couple of skeleton pages for 4.0.1 just now. Basically cloned some of the outline for 3.4.1 I also assume that 4.0.1 will simply overwrite 4.0 exe on mirrors etc. rgds jan I. -Rob Juergen --**--**- To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org -- - MzK Success is falling nine times and getting up ten. -- Jon Bon Jovi
