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> >>>> wrote: >>>>>>> >>>>>>>> On 4/22/13 10:18 PM, janI wrote: >>>>>>>>> On 22 April 2013 20:54, Jürgen Schmidt <jogischm...@gmail.com> >>>> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am currently preparing po files for AOO 4.0 and will focus >>>> on the >>>>>>>>>> languages that we have already released. All other langs will >>>> follow >>>>>>>>>> immediately. >>>>>>>>>> >>>>>>>>>> I have created 2 new projects on the "old" Pootle server to >>>> get an >>>>>>>>>> impression of how much work we have to do. >>>>>>>>>> >>>>>>>>> >>>>>>>>> What is the status of sidebar online help ? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> no update at the moment. Our xhp file format is not the most >>>> intuitive >>>>>>>> format and especially the unique id's are tricky. I will try to >>>> figure >>>>>>>> out how the help authoring tooling works and if we can use it. >>>>>>>> >>>>>>> >>>>>>> I hope we agree that we cannot release the sidebar without online >>>> help, >>>>>>> >>>>>> >>>>>> who >>>>>>> ever makes it. >>>>>> >>>>>> >>>>>> mmh, I am not sure if nobody will work on it and if we won't have it >> in >>>>>> time it would be no show stopper to me. Online help is not so >> critical, >>>>>> it would be of course good to have it. >>>>>> >>>>>> If you think it would be a stopper you should provide or propose a >>>>>> solution. >>>>>> >>>>> >>>>> >>>>> Well you know I cannot provide a solution, at least not within the >>>>> timeframe given. >>>>> >>>>> To me it would be a show stopper if the sidebar contains no help while >>>> the >>>>> old parts has help, or even worse non-translated help. >>>>> >>>>> Asking for a proposal is very fair. >>>>> >>>>> My top goal is to be consistent, so either: >>>>> 1) someone from doc. or elsewhere works on online help for the >> sidebar, I >>>>> can with my limited knowledge help with the integration. >>>>> 2) or we remove online help completly, stating it is being reworked. >>>>> >>>>> Our users are used to online help, and with a big new feature like the >>>>> sidebar, for sure many of them will seek online help in the way they >> are >>>>> used to, and be confused why the old features have help and the new >>>>> important one hasnt. >>>>> >>>>> To me this a very important issue: >>>>> >>>>> do we want to keep a dealine for the sake of the deadline and sacrife >> our >>>>> users, or do we want to release a "professional" product. In my mind >>>> there >>>>> are no doubt about the answer. >>>>> >>>>> >>>> >>>> we don't want to keep a deadline only for the sake of the deadline. We >>>> should be simply realistic, if nobody works on it we won't get one and >> it >>>> makes no sense to postpone the release because of a missing online help >> for >>>> one feature. >>>> We have released languages where the online help is not or only partial >>>> localized. This was and is fine as well. >>>>> >>>>> But of course it is not my opinion alone that counts, so lets have a >>>>> discussion...feel free to convince me why my point of view is wrong. >>>>> >>>>> >>>> >>>> I am simply realistic, if somebody steps forward and tell me that he/she >>>> can provide a basic online help for the sidebar in 1 week I would >> volunteer >>>> to merge and update the po files ones more to include the help in the >>>> translation process. If not I would move it to 4.1 because I believe >> that >>>> the online help is not so important . >>>> >>> >>> Fair, I believe it is very important....if you have a new feature and >> dont >>> know how it works you go to the online help, like you do in all other >>> parts. Of course if the product does not have online help at all, you >> would >>> also not expect it for a new feature. >> >> well I use integrated help rather seldom and search more often in the >> web if I need help. >> >> But in general if such a new shining and visible feature like the >> sidebar is not intuitive to use we have already made the first mistake >> and that will no available online help change ;-) >> >> Thas is a nice killer argument...why do we provide help at all, when our > system is so intuitive. > > maybe because we reach out, not only to skilled users as you and me :-) > > >> >>> >>> To put a bit more direct, if you bought a new car, and there was no >> manual >>> explaining how the new fancy voice activated radio worked, would you be >>> happy ? I would not. >>> >>> The 1 week is a selfmade deadline, that can be shifted as we like, we do >>> not break a contract or anything if we postpone the release. >>> >> >> We are planning more or less in 6 months cycles and I think this is a >> good approach. I would of course like to see more new stuff and more >> bugs fixed. But as always the work have to done. >> >> I would prefer a regular release cycle (more a train model) where we are >> flexible but where we try to hold the deadlines. >> >> If we move the deadlines every time somebody thinks we need a further >> fix, improvement, missing translation or whatever we ill have problems >> to release something at all. >> > hmmmm. I agree on your train model for maintenance/minor releases, but this > is a major release... > you see big companies postponing major releases because they want to > deliver a rounded > off product. > > I strongly disagree, that releasing just because it said so in the > calender, that is not a good idea.... > where do we draw the line, we are on a sliding path here. Is it ok to > release if a single button does not work, > if a single panel does not work, or even if a major function is broken...I > am not the one to set the limit, but > we should define that very carefull. > > >> >> The deadline is known for some time and incompatible work should have >> been done already. Everything else can be moved to a 4.1, 4.2 or when it >> is ready. I don't see a problem, if a fix or feature can't make it for >> the deadline, it will be integrated in the next. >> >> And in general we should create a plan what should be in next release or >> where we want to put the focus for our next release. It's fine if >> everybody makes what he/she want, especially regarding bug fixes. But >> for bigger features or directions I would like to see a plan where we >> can all agree and where we work together to achieve this plan. >> >> For example for a 4.1 I can imagine to focus on OOXML support as one key >> feature. You can see as a motto for the release, a focus area ... >> >> >>> WE should in general be very carefull about moving features from 4.0 to >>> 4.1. 4.0 is a major release, where we can allow ourself (with good >> reason) >>> to be incompatible, whereas 4.1. is a maintenance release and a bit. I do >>> not like the tendency at the moment to push everything difficult or >>> unpleasant to 4.1, just to keep the 4.0 deadline. >> >> we should more careful the next time when we put something on this plan >> that we can't achieve. I will for sure not put anything on the plan that >> I can't provide in time. >> >> But nevertheless a plan is necessary that we can organize the missing >> pieces in time. Coordinate development work with QA, documentation etc. >> > Of course a plan is needed, I totally agree with that...I just disagree > with what happens if a > feature does not meet the quality level I would expect. > > >> >>> >>> 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 > > rgds > jan I. > > >> >> Juergen >> >>> >>> jan I. >>> >>> Ps. I think the sidebar is a fantastic feature, and I also like the other >>> features I have seen (and understood). >>> >>> >>>> >>>> Juergen >>>>> >>>>> rgds >>>>> jan I >>>>> >>>>> >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> But for the future we need probably somthing new. >>>>>>> >>>>>>> yes, I used to use Qt help system, which are quite easy to maintain, >>>> but >>>>>>> this is only one of a couple of good candicates. The tricky thing is >>>> that >>>>>>> we problaly need to change all the keys in the src files...lots of >>>>>>> >>>>>> >>>>>> editing, >>>>>>> but a nice job for a new volunteer. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> For the UI in "de" will have to check/translate for example >>>> 4986 >>>>>>>>>> strings, I know we have string moved and translations should be >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> already >>>>>>>>>> available but my knowledge of the language tools and/or >>>> translation >>>>>>>>>> memory is too lazy. any kind of help is appreciated ;-) >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I am traveling the next 2 days and have onyl limited time to >>>> work on >>>>>> it. >>>>>>>>>> But I expect to have the po's ready at the end of the week >>>> that we can >>>>>>>>>> start with the work. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Please mail me, when you have synced the PO files on the old vm, >>>> then I >>>>>>>>> will copy them to the new vm. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ok >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I will keep you informed and please don't use the new AOO 4.0 >>>> related >>>>>>>>>> projects as long as I give the ok. We will potentially use the >>>> new >>>>>>>>>> Pootle server. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The new server is in test....and awaits a principle discussion >>>> between >>>>>>>>> >>>>>>>> >>>>>>>> AOO >>>>>>>>> and Infra. >>>>>>>> >>>>>>>> >>>>>>>> what kind of discussion? >>>>>>> >>>>>>> Only committer login (infra version ) or local login and committer >>>> login >>>>>>> (aoo version rob/andrea) >>>>>>> >>>>>>> I have given andrea and infra a possible compromise. >>>>>>> >>>>>>> Did you not see my mail (private list) ? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Juergen >>>>>>>> >>>>>>>>> >>>>>>>>> rgds >>>>>>>>> Jan I. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Juergen >>>>>>>>>> >>>>>>>>>> >>>> --------------------------------------------------------------------- >>>>>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> >> --------------------------------------------------------------------- >> 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
