On Wed, 2007-04-11 at 20:02 +0700, Nguyễn Thái Ngọc Duy wrote: > > I tend to agree that this is a problem, but only insofar as we've become > > too territorial. Many times I see bugs filed with seemingly minor > > changes being asked for. A good example is bug #173884 which is a > > completely valid request. The change is simple, removing > > "insinto /etc/env.d ; doins $somefile" and replacing it with "doenvd > > $somefile" instead. Now, this is something that *anyone* with commit > > access should feel comfortable doing to *anyone's* packages without fear > > of being attacked for touching someone else's packages. > > I wish we could have a list stating which package you have to contact > its maintainer first (and the reason why if possible), or add > <restricted> tag in metadata.xml to warn people. The rest of the tree > will be free land (unless you break the tree of course)
That's really the point here. You should *never* have to contact the maintainer first for minor QA issues like changing something as simple as "insinto /etc/env.d ; doins $somefile" into "doenvd $somefile" or fixing a typo. The maintainer only needs to be contacted on changes that modify the end result. If you're completely rearranging the ebuild or trying to add a patch, you should definitely contact the maintainer. If you're just cleaning up minor QA issues, it isn't necessary. This has always been the case, but perhaps it would be better to state it more plainly so people understand that they are allowed to touch *anything* in the tree. The main thing to take into consideration is the scope of who is affected. Take a package rename as an example. If your package foo is being renamed bar, then I would fully expect you to change all instances of foo in dependencies in the tree to bar, as it really only "affects" you since it was your package that changed. If you're adding a new default local USE that only affects your package, there's no need to ask anyone. If you're adding a new default USE that's used in a bunch of packages, it should be asked here. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
