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. > * New Translation Infrastructure - this is the major change to use the > po files directly in the code, the consolidation of the poo files, > and the new pootle server infrastructure. > * 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 + ??) > > > 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. 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. 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. > 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
