Hi Michael,
Michael Meeks wrote:
> On Fri, 2006-08-18 at 10:55 +0200, Mathias Bauer wrote:
>> I agree that we should define these things and how
to handle the
>> situations where they happen. I know several
examples where this has
>> happened, for whatever reason.
>
> Great  I'm glad
it's not just painful for people outside Hamburg
Well, I meant cases outside of Hamburg that I know of but I
don't want
to differentiate here. Of course I'm also interested that
"external"
contributions are not hindered by "internal"
resource problems.
>> For me it boils down to the point: how to
>> make sure that the necessity of finding an
available QA representative
>> and getting feedback from him doesn't block the
integration of a small
>> or simple enhancement or feature.
>
> Right - so, any suggested rubric here ? my 1st attempt
was removed from
> the wiki. Joerg - how can we best capture the essence
of "if no-one is
> responding at all, it's not controversial & hence
we can skip approval
> from eg. the UI team ?".
I think your attempt was made under the wrong assumption
that any
"approval" was needed for a spec. But the real
problem at least IMHO is
another one.
> I would personally suggest something like:
>
> "It is necessary to post your spec. to an
archived OO.o mailing
> list, in order to solicit UI, i18n, etc. review,
however if
> there is no response within <N weeks> it is
acceptable to
> assume the spec. is 'uncontroversial', post to the
list again
> saying you assume it is approved, and move it to
'STANDARD'"
I don't think that we can use any fixed dates. You can't
integrate a CWS
without a QA rep. So this is the first barrier you have to
overcome and
this is your duty as a developer. We can't remove that
barrier.
Once you have found a QA rep you both need to negotiate what
is
uncontroversal and what isn't. As a result you hopefully
will come to an
agreement wether additional members of the iTeam are
necessary (e.g. for
providing input wrt. translation or UI).
"Uncontroversal" should mean
that nobody thinks that further input is necessary and that
you and the
QA rep can nail down the test plan from the spec. We could
talk about a
time frame for this agreement, starting from the day where
the QA rep
agreed to take over his role. You will still need a
negotiation about
the test plan and wether it can be created from the spec -
how else
should the code be tested?
> My point is that to measuring whether it is a 'good'
specification - ie.
> whether it should become 'Standard' (approved), the
criteria are *not*:
>
> "does it do what we wanted ?"
> "are the UI team happy with it ?"
>
> But only:
>
> "does the spec. match the code ?"
>
> ie. a 'good spec.' is one that matches the code: at
this point we have
> to abandoned any hope of the spec. process being used
to actually
> improve the code: beyond that perhaps of the burden of
writing it down
> twice  [ but
wouldn't a better burden be code review ? ]
You mix up the "formal" quality of the spec with
the "textual" one.
Surely a bad content doesn't become good if it is presented
nicely, but
OTOH the greatest content becomes garbage if it is presented
in a way
that is not understood or - even worse - if it is
misunderstood.
> So - the only quality metric in terminating this
process is unrelated
> to the quality of the software itself [ which AFAIR is
what we were
> trying to improve ;-] ie. this process appears to be an
end in itself -
> and worse ties into QA - so the QA process becomes one
of not "is this
> good enough", but of "is this what the
spec. says it is".
Of course the content of the spec is even more important but
this isn't
something you can verify in a formal process. If that was
possible we
all would be genius.
OTOH at least we can control that all people working on a
feature make
clear to anybody who needs (or wants) to know what they
wanted to
achieve, how they did it and what consequences this has for
the work of
others. And from own and painful experience we know how
important this
can be in many cases. I agree not in all cases, but you
never know
beforehand what case you have.
Therefore I agree that we need to simplify things a bit when
it is
uncontroversal that in all probability such bad things
won't happen.
Quite often the best ideas and implementations fail because
only the
developer doing them knew about them. Or they don't fail in
the first
place but break later because others didn't know about them
or their
influences on other areas.
Besides that: nobody prevents any involved parties from
discussing
wether what they provide is "good" or
"good enough", on the contrary, I
would assume that they have done this before or while they
have written
the spec!
If you have seen a boring movie don't blame it on the
script if it's the
story behind that bored you, but OTOH a bad script will
spoil even the
best movie with a great story and the best actors.
> Anyhow - I mention this merely as a highlight of the
IMHO stultifying
> nature of the process rather than as a serious request
for more barriers
> to entry, more gate-keepers, more pain etc.
Ultimately, I'm certain
> (as you know) that a better model is where the module
maintainer is
> responsible, and just reviews / approves patches as
they arrive; and the
> UI team review incoming changes, fix stuff and have
their own
> programming resources on-hand to fix larger / targetted
UI problems.
The module owner is a developer. Most (all?) developer
aren't able to
take care for all aspects that working in such a big and
complex project
gives rise to. I also think that even if they were able they
most
probably wouldn't like it and are glad that others do it
for them while
they can proceed with hacking.
As long as the quality of the product heavily relies on a
good QA and
especially on regression testing we must make sure that all
involved
parties have an aligned knowledge about new contributions to
the
product. And we have to admit that OOo *does* rely on a good
QA.
I'm also convinced that in many cases we need a lot of
preparatory work
prior to the development of OOo contributions or
accompanying it to
achieve a good quality: competitive analysis, UI consistency
checks etc.
Surely you can do these things withou a formal
specification, but we
don't want to rely on this being done by all developers
when necessary,
so we have a process that gives us a means to check it.
Again I agree
that this is not necessary in all cases, but also again you
never know
... (see above). "Confidence is good - control is
better." The bigger a
project is, the more important this becomes.
> [1] - that a good spec. is not a pre-requisite for
good software, is
> easily proved by examining 10+ clean, well designed,
efficient, fast,
> small, code reviewed Free software projects built by
teams with never a
> specification being written eg. read
gtk+ vs. VCL - compare and
> contrast: performance, feature use, API consistency,
API documentation,
> Object Oriented style, deprecation strategy, design:
eg. layout - the
> list goes on & on. Of course, not writing a spec.
is no guarantee of
> success either there
are plenty of badly designed projects too.
You shouldn't compare apples with oranges. VCL wasn't spec
driven, in
its roots it's a hacker product created by a single
developer and
meanwhile developed "a bit". I'm sure that a
formal spec process would
have helped to avoid a lot of the current shortcomings
because it had
created a platform where all relevant aspects could have
been logged,
discussed and finally verified.
OTOH comparing gtk with OOo doesn't fit, gtk is a library,
not a
product. If you want to compare OOo to something else you
should use
e.g. KOffice and I doubt that you will tell us that KOffice
is not far
behind OOo in any relevant criterion. Especially the
stability is
disastrous and many parts of its UI are looking too
amateurish. IMHO
nobody considers to use KOffice in a professional
environment. That's
not bad because I assume that this is not intended (at least
not ATM),
but OTOH has decided to play in another league.
We can agree to disagree but you shouldn't misinterpret
what we want to
achieve with specifications and use your wrong understanding
as
arguments against them. Let's concentrate on ways to avoid
the overhead
of this process where it is possible and desirable and not
question the
process per se.
Best regards,
Mathias
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribe specs.openoffice.org
For additional commands, e-mail: dev-helpspecs.openoffice.org
|