Hi Frank,

On Mon, 2006-10-23 at 13:12 +0200, Frank Schönheit - wrote:
> To me, this whole discussions seems to be about the
> 
>   "bring it in quick (and sometimes dirty)"
> vs.
>   "bring it in slow, but matured (though sometimes still dirty)"

        Well - it looks like that on the face of it. However - while I
absolutely loathe the process, I can (perhaps) live with it - if it
actually worked :-) Sadly it is totally dysfunctional. If 1 (one)
interaction can take of the order of months to occur, the spec. process
which mandates another order of magnitude more interactions, puts any
feature inclusion into the multiple year time frame. My problem
primarily is with responsiveness & inclusion.

> You prefer the first one, as you said often enough. I continue to
> think that the second one might bring more than it costs, *if* applied
> properly. I might be wrong here, but that's still not proven to me).
> Plus, that's a big, fuzzy "if", admittedly.

        Cool, I'm glad you're willing to accept there might be different
(perhaps just as valid) answers to the same question :-) And of course -
from my perspective the only certain way to ensure that the process is
applied properly is to have no process :-) On the other hand, I often
hear this wonderful (circular) argument it goes like this:

        them: "We need this burdensome process for Higher Quality !"
        us:   "But lets face it quality is still not good"
        them: "Then we need -even-more- burdensome process !"
              <repeat ad nauseum.>

        The 1st step here is to realise that perhaps there are other self
referential world views that also lead to better quality, and to tackle
the issue from 1st principles again, recognise the local maximum we're
at - and try to peer around the energy surface to see if we can see any
other big peaks around that would get us higher :-)

> The problem is: We need to find a consensus in the OpenOffice.org
> project as a whole, and all your sarcasm doesn't change this.

        Well, (apparently) my sarcasm has at least got people to discuss this
problem that has been festering, un-fixed for some years now. My feeling
is that some parts of Sun are in fact eager for the process to be
burdensome - precisely to raise the barrier to entry, and ensure that
(to their mind) "only the best" work gets included. To my mind this is a
tragedy and a sure-fire recipe for continuing to not attract any
developers. I sometimes think that some people are also in fact quite
pleased that eg. it's impossibly difficult for the average developer to
build on 2 platforms before getting their CWS included, (which would
explain the almost total lack of action wrt. making this easier to do).

> Or are there chances we find a compromise?

        I'd love to find a compromise, but this has to be part of a bigger
discussion as to why OpenOffice.org is failing to attract a meaningful
developer community - and who owns that problem; or if it even is a
problem. (There seems to be substantial doubt in a lot of people's minds
here).

        There also appears to be a "free labour" perception of volunteers in
certain places: that these people can be asked to do arbitrarily
unpleasant things, and that they will do them. I'd like to persuade
people this is (emphatically, and clearly) not the case. That if Sun QA
wants to include all this process for Quality reasons, then -it- must
shoulder the burden [ at least for volunteer contributions ].
Ultimately, I'm not unhappy to have a mega-ton of specifications that
few people if anyone read, and an ongoing maintenance nightmare of
keeping them in-sync with the code as long as I don't have to pour my
resources down this particular black hole :-)

> [1] Did I mention your port doesn't work as expected for me? After the
>     first start, I have a quickstarter. After closing it, I never get it
>     back, again, not even with checking the respective option in the
>     menu.

        This is in fact a 'feature' of the Win32 quick-starter too :-)
Basically the option is not "instant apply", consequently you need to
re-start OO.o to see the effects. Similarly (reading the code) it seems
it's likely that another bug filed (i#70484) also afflicts Win32 users
but they didn't notice ;-)

>     Somehow I think this particular feature *should* have had some
>     more QA, in other words: some involvement of more parties.

        Well - my attitude here is rather different :-) in the time that it
took to create the CWS, commit the code, go through QA etc. I had in
parallel done a number of other improvements / fixes, and subsequently
then fixed a number of other issues which were kindly reported when (you
guys) started using it in the milestone - all of which are committed to
gtkquickstart2 - which FWIW improves the usability, makes the settings
instant apply, etc. and starts to be a rather nice solution.
Unfortunately it may be mired in the process perhaps indefinitely
[ unless some friendly QA person wants to help out ].

        gtkquickstart2 also has the benefit of disabling the quickstarter in
Sun builds (i#70644#), which (I hope) will solve the problems for
~everyone (except your customers) [ it is now necessary to turn that
off, in the CWS since it changes a string too (wrt. improving the exit
semantics) ].

>     Speaking strictly, the solution you finally chose with the latest
>     fix is the proper one: You feature works perfectly in the use case
>     "distro-provided OpenOffice.org build", so it should be enabled in
>     exactly this particular use case.

        Having a formalised process (1 paragraph necessary?) for quickly
including code into OO.o that is disabled in all Sun builds, and quickly
getting fixes / changes into that etc. would be much appreciated. This
is something we have been wanting for some years now; but no action.

        Regards,

                Michael.

-- 
 [EMAIL PROTECTED]  <><, Pseudo Engineer, itinerant idiot


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to