On 25 April 2013 21:00, Rob Weir <robw...@apache.org> wrote: > 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 > 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-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 > >
