Christian Faulhammer wrote: > Doug Goldstein <[EMAIL PROTECTED]>: > > >> Jonathan Adamczewski wrote: >> >>> Doug Goldstein wrote: >>> >>>> That's what this commits review list feels like. >>>> >>> Nearly every suggestion (from Donnie and others) has been over some >>> issue that relates directly to either correctness or >>> maintainability. It doesn't matter if you can "rattle off >>> capabilities to a millimeter" - if they're not documented somewhere >>> (like, say, in the comments of the ebuild) then the maintainer that >>> comes after you gets to go and break it all over again. >>> >> Correctness? Fine. Go ahead. Stick $(use_enable xvmc) into the ebuild. >> Do it. I dare you. Then try to compile. >> Guess what? When it blows up... that's called INcorrect. The opposite >> of the right thing. >> > > You were kindly asked if is not possible to use, so why do you feel > attacked? Do a comment on it and everybody would be fine, even the > people that would have to maintain it some time in the future. If you > don't like the review process, just ignore it. > Reviews are not a way to show what kind of idiot the committer is, but > to improve the overall quality of the tree. Nothing more, nothing less. > No. You clearly don't understand where I'm coming from. I think the commits review is pointless and a waste of resources that could be better used doing other things. Since commits review is a cyclic process you will never achieve a perfect state that all developers commit perfect ebuilds to the tree since new devs come and go. And since we don't document any of this stuff properly in the devmanual, incoming devs have to constantly relearn the same lessons that previous incoming devs learned through the review process. Effective workers work in 4 stages, we're effectively with this approach remaining in stage 1 and never progressing and admitting we will never progress.
> > >> The maintainer who comes after me would be someone with a experience >> with the package. Some bumkin isn't going to come to maintain package >> XYZ unless they know or use the package, and guess what? That means >> experience. >> > > Yes, and the same goes for GNU Emacs, I needed some time to figure out > what all those things did and I broke it several times because I tried > to be clever. Now we documented it and I think everyone coming after us > will have a less hard time to understand it. Better document it, you > never know what happens. > > V-Li > > Read the ChangeLog. It's there for a reason. It provides valuable knowledge and information about the package. I would expect any developer worth their salt to at least brush up on the ChangeLog for any package they are taking over. -- [EMAIL PROTECTED] mailing list
