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 19:11:24 GMT
On 25 April 2013 21:00, Rob Weir <robweir@apache.org> wrote:

> On Thu, Apr 25, 2013 at 2:25 PM, janI <jani@apache.org> wrote:
> > 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.
> >
>
> Those who are actually doing this work also think it is important.
> Otherwise they would not be doing it.  But it is not part of the 4.0
> plan that we've been executing on.
>
> >> >  * 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
> >
>
> And that's why we're working on the logo survey now, after collecting
> 40 proposals.  We'll certainly have a new logo and splash screen for
> 4.0.  But currently no one at all is working on branding changes
> beyond that. at least no work that is on the lists,   Items that no
> one is working on will not happen not matter how much time we wait.
>
> >> >
> >> >
> >> > 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.
> >
>
> Yes, many, many interop fixes.  100 or so were listed on the blog awhile
> ago:
>
> https://blogs.apache.org/OOo/entry/merging_lotus_symphony_allegro_moderato
>
that is still maintenance items...no big features. a change to 4.0 is not
just due to interop fixes.


>
> >
> >>
> >> 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.
> >
>
> We could have done many things in the past.  But the plan we agreed on
> was to do these things for AOO 4.0.
>

One of them was the sidebar, and to me that includes documentation and
online help.


>
> > Please remember 4.0 is a major release.
> >
>
> Only if we release it.  Otherwise it is nothing.
>
> >>
> >> 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.
> >
>
> Glad to hear it.  When it is ready we'll include it in a release.
>
> It is reasonable to discuss and balance between these two interests:
>
> a) Those who have already completed work they committed to doing for
> the release.
>
> and
>
> b) Those who have not yet completed the work they committed to doing
> and are asking for a delay.
>
> We can have that discussion and work something out.
>
> On the other hand I give very little weight to:
>
> c) Those who are not doing work, but only wish that someone else does
> work, work not part of the agreed-upon plan, and wish to delay the
> release until someone else does the work
>
> I hope you understand why it is not reasonable to give much weight to
> c).   The passive voice "X should be done" carries zero weight around
> here.  The active voice "I want to do X" is much better.
>

No actually I dont...I hear you say just because I am not capable of making
online help myself, I cannot have an opinion of whether or not it is
important.

I care a lot about the full products, even though I am not capable of
developing large parts of it...I assume I could say the same about you and
at the same time I think both of us have opinions on many aspects of AOO.

I think a lot of people have invested lots of time in preparing the 4.0
release (I know I have only done little pieces), and it would be a shame to
release the 4.0 highlight feature amputated.

rgds
Jan I.



>
> Regards,
>
> -Rob
>
> > 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
> >>
> >>
>
> ---------------------------------------------------------------------
> 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