On 4/26/13 9:36 PM, janI wrote: > On 26 April 2013 20:41, Jürgen Schmidt <jogischm...@gmail.com> wrote: > >> On 4/26/13 8:10 PM, janI wrote: >>> On 26 April 2013 18:52, Rob Weir <robw...@apache.org> wrote: >>> >>>> On Fri, Apr 26, 2013 at 12:45 PM, Claudio Filho <filh...@gmail.com> >> wrote: >>>>> Hi >>>>> >>>>> Em 26/04/2013 12:13, "janI" <j...@apache.org> escreveu: >>>>> >>>>>>> for the record, this was not what I said....I simply believe that a >>>>>> feature without help (and documentation) is not complete and if >> released >>>>>> should be highlighted because our average user depend on help in many >>>>>> situations. >>>>> >>>>> Only to give an out perspective, this "highlighted" can return against >>>> we, >>>>> as a incomplete or immature development. >>>>> >>>>> Imho, an important feature of aoo project is its concern in bring and >>>>> deliver a product with high quality. So, the PoV of Ariel and Jan are >>>> solid. >>>>> >>>> >>>> Then all the more reason for someone who cares to enter an issue into >>>> BZ for this. Don't you agree? >>>> >>> >>> I have not seen BZ yet for problems/shortcomming with new features in >>> development (e.g. where are the detailed outstandings of IA2, jsc 3 layer >>> change etc). The help/documentation issue is part of the general sidebar >>> development, but of course we can make one big extra BZ for the 4.0 >>> release just to please the administrative overhead. >> >> well I had at least one issue for my 3 layer work and got a second one >> for a problem that I introduced. I will create more top finish the SDK >> adoption. An of course I would prefer indeed issues for all many more >> changes. >> >>> >>> making BZ for problems/missing with ongoing development is highly >>> problematic, I could f.x. make about 10 BZ for genLang, and I am pretty >>> sure the sidebar developers/documenters/testers could make about at least >>> 100 BZ if they wanted to. It would simply flood BZ, make real problems >>> harder to spot, and put an extra burden on the people doing the work. I >>> f.x. have a simply list with my outstandings,which is quite normal during >>> the development/initial test phase. >> we have indeed many issues now for the sidebar to document the problems. >> Problems from very trivial to more complex and not easy to solve. >> Missing help is of course one that should be tracked with an issue. As >> release manager I will of course not accept it as showstopper if we have >> no issue. And even then it has to be discussed. >> >> We had again a lot of discussion and nobody started to solve the >> problem. I have at least tried to collect some info about the format and >> the tooling. And Ariel provided a patch that will help with extended >> tooltips. But nobody started work on a help file so far. >> >> If somebody will veto the release because of a missing help file you can >> be sure that I will never ever acting as release manager again. >> > According to ASF rules a veto cannot be vetoed...release manager needs to > say go, with min. 3 PMCs.
I know and I meant more that I wouldn't understand if somebody votes -1 for this. I wood prefer if we can all support a release and can reach common consensus. Juergen > > In general the vote is a majority vote for releases, so even if e.g. I was > to vote -1 it would not have a big effect...but stay rested I will not be > the show stopper. > > Unless I read the rules really wrong. > > rgds > Jan I > > >> >> And yes it would be missing and it should be fixed, we all agree but it >> is not stopper issue. We have much more serious problems that we have to >> fix before. >> >>> >>> making a special BZ for this issue, is in my opinion just an >> administrativ >>> trix, it does not change 1 millimeter about the fact, that we have both a >>> challenge. And also I dont understand why you separate this issue from >> all >>> the other open issues with sidebar. >> >> I really don't see a separation here, it's simply one more issue >> regarding the sidebar. >> >>> >>> We should be focussing a lot more on solving our challenges !! >> >> exactly and I don't see that here >> >>> >>> Discussing whether or not help is integrated after both developers and >>> documenters have told it is not, or whether or not a BZ should be filled >>> out are not positive for the process or for our community. >>> >>> This is of course my private meaning, but we have a real tendency at the >>> moment to discuss the administrative surrounding and not the kernel >> issues. >>> I do not understand, why that is, but I strongly believe it signals >>> something negative. >> >> bring your concerns on the table and describe it clearly that we all can >> understand exactly what you mean. It is better to start the discussion now. >> >> >>> >>> Lets try to focus on the problems, make solutions...not administrative >>> stoppers, any objections to that ? >> >> an issue for this problem is quite normal and the solution is to start >> working on it. Quite easy from my pint of view. >> >> Juergen >> >>> >>> rgds >>> Jan I. >>> >>> >>> >>> >>> >>>> >>>> -Rob >>>> >>>>> My 2 ¢ >>>>> >>>>> Claudio >>>> >>>> --------------------------------------------------------------------- >>>> 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
