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. > >> >> > >> >> >> >> 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. > >> >> > 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! -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
