On 25 April 2013 19:42, Rob Weir <robw...@apache.org> wrote: > On Thu, Apr 25, 2013 at 1:15 PM, Andrew Rist <andrew.r...@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 <jogischm...@gmail.com> wrote: > >>> > >>>> On 4/24/13 11:34 PM, janI wrote: > >>>>> > >>>>> On 24 April 2013 22:33, Juergen Schmidt <jogischm...@gmail.com> > wrote: > >>>>> > >>>>>> Am Mittwoch, 24. April 2013 um 17:06 schrieb janI: > >>>>>>> > >>>>>>> On 24 April 2013 16:25, Jürgen Schmidt <jogischm...@gmail.com> > wrote: > >>>>>>> > >>>>>>>> On 4/22/13 10:50 PM, janI wrote: > >>>>>>>>> > >>>>>>>>> On 22 April 2013 22:27, Jürgen Schmidt <jogischm...@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-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
