Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote:
Yes, I tend to agree here. I'll try to raise the issue of missing public product planning transparency ...
Would be great if some improvements could be made. We know it is not easy, but awarenes, little steps foreward and so, can do a lot.
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 :)
OK
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 :)
Very logical. Pls keep it that way.
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
[...] OK
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.
Of course I did notice this change in working. Although it does ask some extra from the Native-Lang projects, I think it is realy an improvement. Because of functionality (for example PDF in 2.0.3; mail merge/spell check/... in 2.0.2; ...). But also because it makes integration of solutions/fixes from others easier/faster, as you mentioned.
Ehm, yes, you need to be tough to survive in the OOo community :) (or :( ?)
Well, since OOo is such an huge project (and marvelous product) it just is tough to bring all things together. :-) for me.
Thanks again for responding (and to Andrew Jensen for being so free to asking the initial question - maybe he has a different experience of the situation and posibilities??).
I'm looking forward to the developments. Greetings, Cor
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 ...
-- Cor Nouws www.nouenoff.nl - www.bsooo.nl - http://nl.openoffice.org Open. For business. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
