Re: [RELEASE]: preparation for AOO 4.0.1

[Jürgen Schmidt]

On 8/13/13 6:55 PM, Ricardo Berlasso wrote:
> 2013/8/13 Fernando Cassia 
> 
>> On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt 
>> 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

[Kay Schenk]

On Tue, Aug 13, 2013 at 12:01 PM, Marcus (OOo)  wrote:

> Am 08/13/2013 06:13 PM, schrieb Kay Schenk:
>
>  On Tue, Aug 13, 2013 at 6:26 AM, janI  wrote:
>>
>>  On 13 August 2013 15:14, Rob Weir  wrote:
>>>
>>>  On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt
 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 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.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

[Marcus (OOo)]

Am 08/13/2013 06:13 PM, schrieb Kay Schenk:

On Tue, Aug 13, 2013 at 6:26 AM, janI  wrote:


On 13 August 2013 15:14, Rob Weir  wrote:


On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt
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

[Keith N. McKenna]

Kay Schenk wrote:

On Tue, Aug 13, 2013 at 6:26 AM, janI  wrote:


On 13 August 2013 15:14, Rob Weir  wrote:


On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt 
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

[Ricardo Berlasso]

2013/8/13 Fernando Cassia 

> On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt 
> 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

[Rory O'Farrell]

On Tue, 13 Aug 2013 12:43:47 -0400
Fernando Cassia  wrote:

> On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt  
> 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 

-
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

[Fernando Cassia]

On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt  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

-
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

[Jürgen Schmidt]

On 8/13/13 6:01 PM, Fernando Cassia wrote:
> On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt  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

[Jürgen Schmidt]

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

[Kay Schenk]

On Tue, Aug 13, 2013 at 6:26 AM, janI  wrote:

> On 13 August 2013 15:14, Rob Weir  wrote:
>
> > On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt 
> > 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

[Fernando Cassia]

On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt  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

[Yuri Dario]

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

[Jürgen Schmidt]

On 8/13/13 3:26 PM, janI wrote:
> On 13 August 2013 15:14, Rob Weir  wrote:
> 
>> On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt 
>> 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

[janI]

On 13 August 2013 15:14, Rob Weir  wrote:

> On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt 
> 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

[Rob Weir]

On Tue, Aug 13, 2013 at 5:24 AM, Jürgen Schmidt  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

[RELEASE]: preparation for AOO 4.0.1

[Jürgen Schmidt]

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 ;-)

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.


Any opinions or comment son this plan.

Juergen

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