On Tue, 2006-06-13 at 23:52 +0100, Stuart Herbert wrote: > Packages are grouped into herds, which are managed by projects. If a > package doesn't belong to a herd, then it doesn't belong to the project, and > other developers are free to take ownership of the package and include it > into the tree.
Umm... pretty much all of these packages would belong to a herd. In fact, I haven't seen a single package added to bugzilla that *doesn't* belong to some herd. Just because the maintaining *project* doesn't want it doesn't mean it doesn't belong to that herd. > A great example of this are web-based applications. The web-apps project > does not own all the web-based packages in the Portage tree. There are many > such packages in the tree that are managed by developers that are not part > of the project. The web-apps project gets to decide what happens to the > packages grouped in the web-apps herd, but we neither have the right (nor > the desire) to tell other developers that they can't add web-based packages > to the tree; nor do other developers require our permission before adding > packages to the tree. Again, you are confusing herds and projects. Here's another example of it done correctly. If you add a game to the tree, the herd should be listed as games. Period. Even if you are going to be the sole maintainer of the package, games should be the herd. Why? Because it is a game, silly. There are quite a few packages under games-* that are completely maintained by someone not on the games team, which means it is not maintained by the games project. That doesn't change the fact that it is a game, and belongs in the games herd. Herd == grouping of packages Project == team of people > What they _do_ need is our permission before dumping packages into the > web-apps herd. If a developer doesn't want a package in our herd, then he > doesn't need our permission to add the package into the tree. That simply seems a bit backwards from the idea of a herd being a logical grouping of packages. You've simply removed logic from the equation and replaced it with permission. > That said, there obviously has to been a level of pragmatism. If a project > recommends that a package doesn't belong in the tree because it is dangerous > to users, then it would be irresponsible of developers to go against this > advice without good reason. > > But otherwise, if you don't want a package in your project, it's no longer > your package to make decisions about. You've declined stewardship of the > package, leaving others free to take on the package instead if they wish. Except I'm not arguing about abandoned packages. I'm arguing about things like kernel sources, that proponents of sunrise say should be in the overlay, even after the kernel team says that it should *never* go into the tree. In this case, the sunrise proponents are explicitly wanting to go against the wishes of the project. This is not and can not be acceptable, as it damages the *project* in question. Remember that people will *always* associate the kernel project with any kernels we provide, even if we put a big fat warning label on it. Warning labels don't accomplish much with some users. > | Please people, be sure you're actually commenting on the issues at hand, > | rather than just adding noise. > > Is that really fair? What's noise to you isn't noise to everyone else. It sure is fair. So much so that mcummings even spoke with me and apologized because he hadn't read what I had said correctly. What he said *was* absolutely correct, in the context to which he was writing. However, it didn't add anything to *this* context, since it was out of context and off-topic. That is pretty much the definition of what noise on a mailing list is. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
