The bug was detected after months by incident. A good QA would have detected it before publishing the release.Also there still is no fix, since I am a beginner with Maven and a beginner with FOP. Actually I do not know well both, I just wanted to use FOP in my own project and found the bug. Now you require me to learn a lot about Maven, Ibiblio and FOP's INTERNALS(!) to get this fixed. Actually I like contributing fixes once I am qualified to do that. But for now I think there must be better ways than learning for FOP internals just to get fixed a bug that was neither done by FOP not by the Maven team nor by me -- identify the causer and make him fix HIS bug.
So do you still think there couldn't be a better QA?
Bruno Aranda schrieb:
The community itself is the community control. See your case. It is the user that reports if something fails, and maybe suggests/provides a patch or has the patience to let other do it. Here, there is no such a master-slave relationship where someone tells the changes and others do. If you need something, you can do it yourself. All the users/experts around here are the QA. And I assure you that it cannot be a better QA... Bruno On 9/20/06, Markus KARG <[EMAIL PROTECTED]> wrote:So since bugs once released cannot get fixed without changing the version (what is problematic with FOP as we have discussed today), this is one more reason for not let anybody upload things without doing quality control. :-) Wayne Fay schrieb: > Yes, this is the point of the discussion. Please search this mail list > (Nabble etc) and Maven Dev to see the entire history of this issue. > > Increment version by one, upload it, and allow Maven to find the > updated version the next time your build runs, it will automatically > find and use it. > > Wayne > > On 9/20/06, Markus KARG <[EMAIL PROTECTED]> wrote: > >> So the policy is "A bug cannot be fixed"?! >> >> Jochen Wiedmann schrieb: >> >> > Markus KARG wrote: >> >>> >> If Carlos is able to upload it while I seem not to be, he actually is>> >> in the role of the maintainer. >> >> Where am I going wrong with that assumption? >> > >> >>> > Your assumption is, that he is able to change files in the repository. >> > The answer is he isn't. Ok, he may be able to do that technically, but >> > the policy is clearly that already released files are left unchanged ->> > forever. >> > >> > >> > Jochen >> > >> >>> > --------------------------------------------------------------------->> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> >> >> >>
begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R & D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R & D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
