On Fri, 14 Mar 2003 20:34, Leo Simons wrote: > The point is that you've issued some vetoes which I and others believe > to be applying to something not subject to a veto ... or provide > arguments that will convince us that they are.
Its a code change and thus subject to veto. I have a solid technical reason for veto, effects code that I work with and I am willing to do the work of supporting my vote. > The point is also that other points you've made in this thread about the > technical validity of the package should be addressed. If a package has > no use or an unacceptable implementation, we shouldn't release it, hence > claims like this need to be addressed when made, if the intent is indeed > to release the package. I don't care if it is released or not. Quality matters less than your commitment to maintain it. If there is people who will maintain and support it then it should be released else not. > On a personal note, I am also pretty annoyed with your whining about us > doing a "half-assed job" in various respects. I think the picture you > paint is wrong, and you should either stop painting it and "get over it" > or back things up. * website is screwed * released components have backwards compat broken haphazardly * indepent release of components is non existent * docs are non existent for many components * unit tests are non existent for many components * unit tests when present have poor coverage * unit tests when present and with good coverage are not run (and thus "released" code fails to pass them) * when changes are made the required work of making changes is rarely done (involves updating all avalon users of change, gump, build system and docs). * licenses on 90% of files is invalid Oh I am sure that you can say "you are working on it" but I have heard that story for years now and nothing has changed. > Also, you are a smart guy who knows quite well how the voting and > discussion process flows here, and dragging out an explanation of > something I know you understand perfectly well (as you taught me!) is > just as annoying, so please stop that too. I have explained the same things in the past. It is annoying to have to repeat things when I know you will only ignore things again this time. > So, turning this around: what possible advantage is there to being a > royal pain in the butt trying to block these things? Would it not be > much more productive to focus on improving the quality of the code? I am not blocking release (as that is impossible). All I am blocking is diluting quality of framework CVS for the sake of change and chest thumping. I would similarly block addition of all other similar stuff and it has nothing to do with the quality of lifecycle or event that it is lifecycle. -- Cheers, Peter Donald *----------------------------------------------------* | We must become the change we want to see. - Gandhi | *----------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
