incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luizheli <luizh...@gmail.com>
Subject Re: After AOO 3.4?
Date Sun, 29 Apr 2012 16:33:29 GMT
Hi,

The Writer can link text frames. This functionality would be greatly
appreciated if it worked also in the Draw.

Luiz Oliveira

Em 28-04-2012 21:30, Rob Weir escreveu:
> On Sat, Apr 28, 2012 at 4:07 PM, Pedro Giffuni <pfg@apache.org> wrote:
>> Hello;
>>
>>
>> On 04/28/12 11:32, Rob Weir wrote:
>>> I'm already starting to get questions on what we'll be doing after AOO
>>> 3.4 is released.  Based on previous conversations on this list, I'm
>>> able to speak confidently about a few things:
>>>
>>> 1) We'll probably graduate to a Top Level Project
>>>
>>> 2) IBM says they will contribute Symphony source code after 3.4 is
>>> released
>>>
>>> 3) We have some initial feature ideas for AOO 4.0 on the wiki:
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Feature+Planning
>>>
>>> 4) We also have some ideas listed for an AOO 4.1:
>>>
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1+Feature+Planning
>>>
>>> Beyond that, do we have anything to say?
>>
>> Well, we have to integrate some CWSs. I am interested in gnumake4
>> since it might help clean some issues in the BSD port. For the rest
>> I am not sure what is there or how stable it is so I would guess
>> we should tackle them slowly and leave most of them for "later".
>>
>> We also have to update some components. Anything with an Apache
>> tag on it, like Apache Commons or Apache Lucene comes first
>> because working with other Apache projects is key for our
>> graduation. Some other components are important but involve a lot
>> of hard work: It would be really great if someone from ICU would
>> give a hand too.
>>
>> The clang port is also rather important and would help the MacOSX
>> support.
>>
>> Finally, I think we should continue cleaning/replacing some Category-B
>> software. For example, carrying an outdated version of Mozilla SeaMonkey
>> just for addressbook support, is a nonsense.
>>
>> All in all, I think we should focus on stability and not on features.
>>
> So these (to me) sound more like items for a 3.5 than a 3.4.1.
>
> Here's how I see things, based on my experience with commercial
> software development:
>
> 1) We want to have a maintenance branch that can be used to deliver
> quick-turnaround releases.  This would be in case we receive reports
> of a security vulnerability, or a new critical bug, or maybe something
> that breaks in us due to a platform update.  In other words, things we
> need to react to quickly.
>
> In order to turn around a maintenance release quickly we need to limit
> changes.  We don't have betas for these releases.  We might require
> code reviews.   We test changes and "test around" changes, but we
> might not have a full test cycle.   The documentation does not change.
>
> We might make very limited feature additions, if they can be made
> without requiring core code changes.  For example, adding a new
> language is general safe, since the test effort is limited to that
> language.  You cannot break existing 3.4 functionality by adding a new
> language.
>
> 2) We also want feature release, like 3.5, 3.6, etc.  Almost anything
> can go into them.  They might have beta release.  They would have full
> test cycles.  They would require all translations to be updated.
> Documentation would need to be updated as well.
>
> 3) Then we have major updates, like 4.0.  These are similar to #2,
> only more substantial.
>
> Was there a similar distinction made in OOo?
>
> -Rob
>
>> Just my $0.02.
>>
>> Pedro.
>>


Mime
View raw message