On Thu, Apr 25, 2013 at 2:25 PM, janI <j...@apache.org> wrote: > 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. >
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 > >> >> 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. > 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. 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-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
