openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <j...@apache.org>
Subject Re: Translation for AOO 4.0
Date Thu, 25 Apr 2013 18:25:29 GMT
On 25 April 2013 19:42, Rob Weir <robweir@apache.org> wrote:

> On Thu, Apr 25, 2013 at 1:15 PM, Andrew Rist <andrew.rist@oracle.com>
> wrote:
> >
> > On 4/25/2013 1:16 AM, Jürgen Schmidt wrote:
> >>
> >> On 4/25/13 9:55 AM, janI wrote:
> >>>
> >>> On 25 April 2013 07:34, Jürgen Schmidt <jogischmidt@gmail.com> wrote:
> >>>
> >>>> On 4/24/13 11:34 PM, janI wrote:
> >>>>>
> >>>>> On 24 April 2013 22:33, Juergen Schmidt <jogischmidt@gmail.com>
> wrote:
> >>>>>
> >>>>>> Am Mittwoch, 24. April 2013 um 17:06 schrieb janI:
> >>>>>>>
> >>>>>>> On 24 April 2013 16:25, Jürgen Schmidt <jogischmidt@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>>> On 4/22/13 10:50 PM, janI wrote:
> >>>>>>>>>
> >>>>>>>>> On 22 April 2013 22:27, Jürgen Schmidt <jogischmidt@gmail.com>
> >>>>>>
> >>>>>>
> > <snip snip snip>
> >
> >>>>> But again, if the general opinion is, that is better to keep a
> selfmade
> >>>>> deadline and release a half finished product, it would not be fair
of
> >>>>> me
> >>>>
> >>>> to
> >>>>>
> >>>>> stand in the way.
> >>>>
> >>>> See above, I think we have to hold our deadlines to show confidence
to
> >>>> the outside. But we can of course improve our planning in the future.
> >>>>
> >>>> Or we should think about a real train model where we release every 3
> or
> >>>> 4 month. But where we maintain also a more stable branch where we fix
> >>>> mainly bugs and potential security fixes.
> >>>>
> >>>> this would be a good idea for minor/maintenance releases but not for
a
> >>>
> >>> major release.
> >>>
> >>> However, it seems I am the only one with this concern, so I will
> silence
> >>> myself. You
> >>> are the voted in release maneger (which I highly support) so according
> >>> the
> >>> apache way,
> >>> it is your call together with a majority vote is a release is
> acceptable.
> >>
> >> I simply volunteered to do this task, I am happy if somebody else steps
> >> in ;-)
> >>
> >> And in general I share your opinion that releases should not have 100%
> >> fixed dates but should more take the planned features into account.
> >> Fixed dates result often in poor software or poor quality. But I believe
> >> we have to find a compromise and what's possible and to show the
> >> necessary confidence to the public about the progress in the project and
> >> in the product. It's not easy ...
> >>
> >> Juergen
> >>
> > Have we discussed, as a project, the tradeoffs that we are making here?
>   On
> > one hand we have solid decisions on the release made by Jürgen which trim
> > features, but lead to a predictable, stable, and complete release.  On
> the
> > other hand, we have we have the reasonable question by Jan, as to whether
> > there is an alternative approach that sacrifices the schedule (i.e.
> pushing
> > back release date) for the features.  My question is "Do we have a solid
> > understanding of this trade-off, and should we make this decision as a
> > project?"
> >
> > To me there are three major changes that would be good to be in AOO 4.0
> > which are currently in jeopardy:
> >
> >  * Accessibility - the integration of iA2 - work is ongoing. This has a
> >    major impact on the product, and the ability of large corporations
> >    and governmental agencies to embrace the product.
>
This is important to me.

> >  * New Translation Infrastructure - this is the major change to use the
> >    po files directly in the code, the consolidation of the poo files,
>
to me this is nice to have, but does not afftect end-users.

> >    and the new pootle server infrastructure.
>
Is ready in approx. 1 week.

> >  * Brand Refresh - this work is moving along now, but there is some
> >    question as to how much of this project can be completed in the
> >    timeframe necessary.  (logo + icons/resources + full brand/splash
> >    screens + color schemes + ??)
>
This is to a must for 4.0, we cannot change brand with 4.01

> >
> >
> > I see  a few directions that this could go:
> >
> > 1. Follow the current trajectory and push off a significant amount of
> >    originally planned 4.0 work to 4.1
> > 2. Push off the release by 3 months and get all of these features in
> >    completely
> >
>
> We're coming into summertime and vacations.  Nothing happens 3 months from
> now.
>
>  3. Hold the release indefinitely, waiting of these features
> >
> >
> > I think that pretty much everyone would disagree with option #3.
>
> Remember that is how this already feels for those who checked in code
> almost a year ago, when they were working on the trunk while work on
> 3.4.1 was occurring in a branch.  There is always more that can be
> added, if we wait.  But there are also a lot of improvements that
> we're withholding from users at the same time.
>
Are we really withholding any major features...when I compare the codebases
I cannot really see it, but I might be wrong.


>
> One thing already in the code is a fix to a horrendous random crash
> that hits users who upgrade from OOo 3.3.0.  Millions of users are
> likely crashing because of this.  Do we really want to hold this back?
>   We should consider not only the additional stuff we could do with
> more time on this release, but also all the stuff that we are
> preventing users from accessing every day we delay further.
>
This is a maintenence release, which could have been done in 3.4.1, and
still can be done as 3.4.2.

Please remember 4.0 is a major release.

>
> IA2 is not a regression. It is a new feature that is not yet done.  I
> wouldn't hold back anything there. It is progressing per the original
> plan, for AOO 4.1.  It was never in the plan for AOO 4.0, right?
>
> I think we already punted on the translation work for AOO 4.0.  I was
> ready to start recruiting translators but stopped since we said that
> was not ready.
>
That work is first of all only in the very beginning (see mails from jürgen
regarding po files), and it is not lost in any way.

rgds
Jan I.

>
>
> > Option #1 is a solid option, but I think that there is some portion of
> our
> > community that is not fully comfortable with this.
> >
> > That leaves us with option #2, which is not perfect, either. Do we have
> > estimates from each of the deferred features how long they would need to
> be
> > complete (with a reasonably high confidence level)?  If the time frame
> would
> > be 6 months instead of 3 months, would anyone be comfortable with that?
> >
> > Could we explore option #2 as a project, and get the answers to these
> > questions?  Then with a more full understanding, can we make a decision
> as a
> > project for #1 over #2 (or vice versa)?
> >
>
> Another option is to recognize that we'll probably need a 4.0.1 or
> something, later this summer, to fix any critical bugs that we miss.
> Of course, we hope this will not be necessarily, but it is prudent to
> plan for this possibility.  This release could accommodate new
> languages, even selected new features.
>
> Regards,
>
> -Rob
>
> > A
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message