Hi Cor,
> The way I see serveral people react on what happens, make me think that
> many:
> - are not enough aware of (the complexity of the product/) this process;
> and/or
> - have to high expectations of their individual influence; and/or
> - cannot understand why their 'easy to implement bugfix (etc)' cannot be
> integrated.
>
> If somehow this could be explained better, that would do quite some
> good. IMHO.
Yes, I tend to agree here. I'll try to raise the issue of missing public
product planning transparency ...
> This is about RFE's.
> What about bug-fixes? Can something be told on the process that
> seperates bugs that are going to be fixed and those that are not?
In general, bugs are handled similar as RFEs. That is, somebody claims
that a certain class of functionality, or an certain area is important
for the next release (or "important enough to throw my resources at
it"). This means that the respective bugs would automatically be
"promoted", which might not necessarily manifest itself immediately in
IZ, but at least in the heads of the owning developers :)
Besides this, developers usually have a certain amount of freedom fixing
bugs en-passant. Personally, I sometimes grab myself a bug which I find
annoying enough to encounter, or intersting enough to fix, and, well,
just fix it :)
Also, people "responsible" enough (which is not formally stated, of
course) are allowed to set targets at issues (say 2.0.3, in the current
stage). Technically, a lot of people are allowed to do so (simply
because IZ's permission system is too chunky). Effectively, not every
target from every user will be accepted. But a certain set of people,
usually QA members (be it internal or external to Sun) have a good
chance of their target suggestion being accepted by the developer. [1]
Nowadays, we (@Sun) work more according to a "what is ready will be put
in" model. That is, even for bugs which do not really qualify as
showstopper for a micro release (2.0.x), we can put them in, if a fix is
available (or cheap to obtain). This has not always been the case, but
it should, to a certain extent, relax the situation that people have to
wait 2 years or so for their bug/fix to appear in a new release.
This aligns with the more frequent feature releases of OOo which have
been proposed/announced in various channels: If something is ready (be
it a bug fix or a feature), it will be put into the next release, no
matter of the release number.
> Remembering some discussions on [EMAIL PROTECTED] and private with some
> very dedicated people, I'm sometimes a little concerned about the effect
> of the "grand, rough" process on active community-members.
Ehm, yes, you need to be tough to survive in the OOo community :) (or :( ?)
> But this thread is important for me, and might turn out to be a valueble
> part in the process :-)
Fine :)
Ciao
Frank
[1] I'd love to have a "target request/approval" mechanism in IZ, as
modern bugzilla installations (e.g. bugzilla.mozilla.org) have.
There, people can really explicitly *request* a target by setting a
respective flag, and this request is fulfilled or denied. Quite a
transparent mechanism for the users. But I suppose before we get
this in IZ, hell will freeze over ...
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
