On 25 April 2013 21:22, Rob Weir <robw...@apache.org> wrote: > On Thu, Apr 25, 2013 at 3:11 PM, janI <j...@apache.org> wrote: > > 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. > > > > And you seem to be suggesting delaying the release because of a > documentation issue ?! But again, this is code that someone wrote > versus work that is not actually happening. I don't think we delay > the real stuff because you wish that someone else was doing something > that isn't being done. >
I see your point, and maybe I was all wrong about this...I just thought we wanted to deliver a prof. product. > > >> > >> > > >> >> > >> >> 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. > > > > I think you need to be far more specific about your concern. In fact, > please enter a BZ for what you think is lacking. We can triage that > along with the other bugs. There a keyword in BZ for suggesting > something is "stop ship" bug and in the past we seek consensus on > that designation on the dev list. But I just tried AOO 4.0 and when > I hit F1 when in the side panel I get the online help. When I am in a > specific panel I get help for the specific panel. So if there is > something huge lacking here, please write it up in BZ so we're all > talking about the same thing. > In one mail I am told, it is a new feature nobody works on, and now I read it is all in there... > > > > > >> > >> > 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. > > > > Opinions are free. I would not wish to deprive anyone of their opinions. > > > 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. > > > > Again, if you think something is missing in 4.0, enter a defect in BZ on > it. > > Thanks! > No need to thank me for saying my opinion. I should really never have raised this issue. Maybe one day our community are strong enough to have such discussions without using "killer argument" like write a BZ (but it is a quite polite way to silence people). I am sorry for having caused fuzz on the list with what I thought was a valid concern, lets simply see what 4.0 contains when it is released. rgds jan I > > -Rob > > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
