Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thursday 13 July 2006 18:53, Ciaran McCreesh wrote: On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | The dev manual is *wrong*. No, the devmanual reflects what's actually being done, rather than an impractical definition that was written years ago that no longer matches the development model. Then file a bug against the given definition. This only adds to the confusion. As I remember however there have been discussions on this topic and they never came to any conclusion. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbrgQXmxFw6.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thursday 15 June 2006 07:57, Harald van Dijk wrote: So herdgames/herd implies managed by the games team sometimes but not always? Meaning if the maintainer is games team + X, then games team must be explicitly listed as a maintainer in metadata.xml ? If so, sorry, misunderstood you, and this is far less insane than what I thought you were saying. RTFM. Metadata.xml specifies a herd for a package. That means that when there is no individual maintainer (or he/she fails to do his duty) that package is maintained by whomever maintain the herd. In this case the project members of the games project maintain the games herd. This means that they will maintain the package if there is no named maintainer or he/she leaves, is unavailable, etc. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9ccLfTTvJY.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thursday 15 June 2006 02:54, Dan Meltzer wrote: According to the devmanual [1] A herd is a collection of developers who maintain a collection of related packages are you sure you are using the correct term? [1] http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html The dev manual is *wrong*. I should know too. I wrote the bloody herds.xml and metadata.xml formats and the page along. Indeed it does not clearly specify what herds are, but it is certainly implied in the format description of for example the maintainer tag. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp8TaWnHwb21.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | The dev manual is *wrong*. No, the devmanual reflects what's actually being done, rather than an impractical definition that was written years ago that no longer matches the development model. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, Jun 14, 2006 at 05:13:48PM -0400, Chris Gianelloni wrote: On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote: On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote: 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. Why do no games' metadata.xml specify games@ as the maintainer? I thought it was because herdgames/herd implies this already, but if it doesn't, then dozens of games can be considered unmaintained right now, and fair game for anyone to mess with without approval. Are you sure you like this interpretation of 'herd'? You're probably right that herd is supposed to mean what you say it does, but existing practise, even by yourself, is very different from it. Umm... no. See, if there's no maintainer listed, it defaults to the maintaining project *for that herd*... So herdgames/herd implies managed by the games team sometimes but not always? Meaning if the maintainer is games team + X, then games team must be explicitly listed as a maintainer in metadata.xml ? If so, sorry, misunderstood you, and this is far less insane than what I thought you were saying. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote: http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4 Specifically the listing for the herd tag. Just because people are doing things *wrong* doesn't mean that there isn't a defined manner in which things should be done. From the document you've referenced: The metadata.xml file has as its purpose to give extra information about ebuilds. The metadata.xml file should exist in every package directory. A skel file can be found as skel.metadata.xml in the portage tree. That clearly doesn't say that every package _requires_ a metadata.xml file. The word used is should, not must. Also: herd There must at least be one herd subtag. The contents of this tag should be the name of be a herd as specified in the herds.xml file. It must occur at least once. Again, the word used is should, and not must. I'm sorry, but I do feel that your interpretation of the rules, on this point, isn't quite right. There _is_ no requirement that games added to the tree _have_ to be put into the games herd - just like there's no requirement that all web-based apps _have_ to be put into the webapps herd. Also, see Solar's post in this thread confirming what I'm saying. The bugs is assigned to the games team. Should I go and simply ACCEPT every single bug assigned to games in bugzilla, including all of the bug spam that will be caused by it, just to show that we *have* accepted these bugs, and are simply working through them at our own pace? Yes, that would be sufficient. That shows that the package is yours, and then the usual rule (that other developers should not mess with your packages) would then apply. That would be in keeping with how Gentoo does things, and would remove the need for you to request that there's a per-team opt-out clause in Project Sunrise. It would also leave Project Sunrise (_if_ the Council decides that it can go ahead) free to pick up any packages that end up in the maintainer-wanted bucket, regardless of what type of package that is. You'll only serve to piss me off. To refer once again to what you like to tell others, maybe you need to grow a thicker skin? ;-) In all seriousness, you're one of the two lead complainants about Project Sunrise. You've raised a number of points about Sunrise that need debating; you were right to do so, and I don't think anyone feels that they shouldn't have been raised. If you're not going to participate in a debate about those concerns without throwing your toys out of the pram, it undermines the complaint that you're making. That's plain enough to see by looking at the reaction elsewhere in these threads to some of the postings from the Sunrise project team, where they've behaved like that. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thu, 15 Jun 2006 15:07:36 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote: http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4 Specifically the listing for the herd tag. Just because people are doing things *wrong* doesn't mean that there isn't a defined manner in which things should be done. From the document you've referenced: The metadata.xml file has as its purpose to give extra information about ebuilds. The metadata.xml file should exist in every package directory. A skel file can be found as skel.metadata.xml in the portage tree. That clearly doesn't say that every package _requires_ a metadata.xml file. The word used is should, not must. Also: However it does mean you need to have a very good reason for not providing one. Compare with may or can. Can't be bothered or don't want to are not sufficient reasons. I read the should as implying that all new packages must have it, and packages existing before the introduction of metadata should get it as and when maintainer gets around to it (i.e. at least on the next bump). herd There must at least be one herd subtag. The contents of this tag should be the name of be a herd as specified in the herds.xml file. It must occur at least once. Again, the word used is should, and not must. So you'd better have a good excuse for violating the rule if you do so. Anyone adding a herd tag to meet the shall, then putting garbage in it that isn't the name of a defined herd for no good reason, deserves to be spanked. I'm sorry, but I do feel that your interpretation of the rules, on this point, isn't quite right. There _is_ no requirement that games added to the tree _have_ to be put into the games herd - just like there's no requirement that all web-based apps _have_ to be put into the webapps herd. However common sense suggests that anyone adding games to the tree should join the games team and add the game to the games herd (which obviously means playing by the rules of the team) - not least to provide consistency; but also to be in the loop for overall games issues and to provide the most sensible backup maintainers. In other words, you need to have a very good reason for avoiding the games team and herd when adding a game to the tree. Also, see Solar's post in this thread confirming what I'm saying. The bugs is assigned to the games team. Should I go and simply ACCEPT every single bug assigned to games in bugzilla, including all of the bug spam that will be caused by it, just to show that we *have* accepted these bugs, and are simply working through them at our own pace? Yes, that would be sufficient. That shows that the package is yours, and then the usual rule (that other developers should not mess with your packages) would then apply. That would be in keeping with how Gentoo does things, and would remove the need for you to request that there's a per-team opt-out clause in Project Sunrise. It would also leave Project Sunrise (_if_ the Council decides that it can go ahead) free to pick up any packages that end up in the maintainer-wanted bucket, regardless of what type of package that is. You'll only serve to piss me off. To refer once again to what you like to tell others, maybe you need to grow a thicker skin? ;-) In all seriousness, you're one of the two lead complainants about Project Sunrise. You've raised a number of points about Sunrise that need debating; you were right to do so, and I don't think anyone feels that they shouldn't have been raised. If you're not going to participate in a debate about those concerns without throwing your toys out of the pram, it undermines the complaint that you're making. That's plain enough to see by looking at the reaction elsewhere in these threads to some of the postings from the Sunrise project team, where they've behaved like that. Best regards, Stu -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Hi Kevin, On 6/15/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: I read the should as implying that all new packages must have it, and packages existing before the introduction of metadata should get it as and when maintainer gets around to it (i.e. at least on the next bump). Chris's argument was that this doc _requires_ packages to belong to herds (specifically, that all packages that are games automatically belong to the games herd). The document clearly doesn't support his argument. So you'd better have a good excuse for violating the rule if you do so. Anyone adding a herd tag to meet the shall, then putting garbage in it that isn't the name of a defined herd for no good reason, deserves to be spanked. ?? Where has that come from? Has there been a spate of people doing this? However common sense suggests that anyone adding games to the tree should join the games team and add the game to the games herd (which obviously means playing by the rules of the team) - not least to provide consistency; but also to be in the loop for overall games issues and to provide the most sensible backup maintainers. As you say yourself, it's suggested, not mandatory - and it doesn't have to be a specific herd. In other words, you need to have a very good reason for avoiding the games team and herd when adding a game to the tree. That's your personal opinion, which I respect, and I understand how you've come to that conclusion. But it doesn't change the fact that, if folks choose to maintain a game without joining the games herd, they're prefectly entitled to do so. And the same is true for webapps, or anything else. You simply can't go around clubbing people over the head and saying that's a project project ebuild, join our team or it doesn't go into the tree, which is where this is leading. What we _don't_ want are folks adding a package to a tree and dumping it on a herd without their permission. That always has been a big 'no no' in Gentoo. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thu, 2006-06-15 at 19:18 +0100, Stuart Herbert wrote: Hi Kevin, On 6/15/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: I read the should as implying that all new packages must have it, and packages existing before the introduction of metadata should get it as and when maintainer gets around to it (i.e. at least on the next bump). Chris's argument was that this doc _requires_ packages to belong to herds (specifically, that all packages that are games automatically belong to the games herd). The document clearly doesn't support his argument. I said no such thing. This is clearly a case of you trying to assume what I'm saying in such a way that it matches with what you want me to say. I said that all games in the tree should be in the games herd. We like it this way. Trying to make it out like I said something that I didn't does what for you, exactly? So you'd better have a good excuse for violating the rule if you do so. Anyone adding a herd tag to meet the shall, then putting garbage in it that isn't the name of a defined herd for no good reason, deserves to be spanked. ?? Where has that come from? Has there been a spate of people doing this? Ever seen a no-herd package? That's your personal opinion, which I respect, and I understand how you've come to that conclusion. But it doesn't change the fact that, if folks choose to maintain a game without joining the games herd, they're prefectly entitled to do so. And the same is true for webapps, or anything else. You simply can't go around clubbing people over the head and saying that's a project project ebuild, join our team or it doesn't go into the tree, which is where this is leading. Not at all... this is where the naysayers will lead you to *believe* that it is leading. How about this? How about you ask tcort about what happened the other day with the games package that he wanted to add? He asked me if he could add it and he would maintain it. I said yes. He added it with games as the herd, and him as maintainer. Where's the problem? What we _don't_ want are folks adding a package to a tree and dumping it on a herd without their permission. That always has been a big 'no no' in Gentoo. See, this is where you're mistaken in thinking that anyone says that you can dump a package on someone else. I *definitely* have said no such thing. If someone adds a game, they better damn well list themselves as the maintainer. The same should be true for all packages. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
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
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 08:38 +0200, Kevin F. Quinn wrote: On Tue, 13 Jun 2006 23:19:51 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Cummings wrote: | Chris Gianelloni wrote: | Using your example, if it will *never* make it into the tree, then what | is it doing on *.gentoo.org infrastructure? | | OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team | overlay repository. [snip] You're not alone. The webapps overlay contains ebuilds that may never make it into the tree. We have a lot of packages that we maintain, but which don't pass our upstream requirements [1] at this time. We're doing our best to work with $upstream on resolving such issues, but we're never going to achieve a 100% success rate. No-one is objecting to these project-local overlays. The objection is to a system-wide overlay. Correct. I would have *no problem* with an opt-in system. Instead of using InOverlay (which is a poor choice anyway... which overlay?) as some sort of tag, instead, assign the package to the project which maintains the herd the package belongs to. If the project does not want it, then they can add SUNRISE to Keywords (in bugzilla). The Sunrise project then has permission to do with the package as they see fit. At *this* point, you could use InOverlay, since it would be pretty obvious which overlay it means. The real root of the problem is that packages that were once assigned to teams/projects are now being assigned into a generic dumping ground and being forgotten. You're trying to resolve this problem by moving them to another dumping ground, which I completely disagree with. A better solution would be to revert the broken behavior, and start assigning packages back to the projects, as it used to be done. Let the project decide if they want the package or not. If they don't, then they can simply add a single keyword and Sunrise can have at it. This pleases everyone, as packages can be maintained in Sunrise, and the projects still get to decide about packages that would likely affect them. It changes the project to an opt-in project, rather than having to track down things and opt-out. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote: 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. Why do no games' metadata.xml specify games@ as the maintainer? I thought it was because herdgames/herd implies this already, but if it doesn't, then dozens of games can be considered unmaintained right now, and fair game for anyone to mess with without approval. Are you sure you like this interpretation of 'herd'? You're probably right that herd is supposed to mean what you say it does, but existing practise, even by yourself, is very different from it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote: I would have *no problem* with an opt-in system. Instead of using InOverlay (which is a poor choice anyway... which overlay?) as some sort of tag, instead, assign the package to the project which maintains the herd the package belongs to. If the project does not want it, then they can add SUNRISE to Keywords (in bugzilla). The Sunrise project then has permission to do with the package as they see fit. At *this* point, you could use InOverlay, since it would be pretty obvious which overlay it means. The real root of the problem is that packages that were once assigned to teams/projects are now being assigned into a generic dumping ground and being forgotten. You're trying to resolve this problem by moving them to another dumping ground, which I completely disagree with. A better solution would be to revert the broken behavior, and start assigning packages back to the projects, as it used to be done. Let the project decide if they want the package or not. If they don't, then they can simply add a single keyword and Sunrise can have at it. This pleases everyone, as packages can be maintained in Sunrise, and the projects still get to decide about packages that would likely affect them. It changes the project to an opt-in project, rather than having to track down things and opt-out. Except there is a flaw in your idea. As I see it, nothing prevents the developers of Project Sunrise from joining each and every team currently in existance and start marking enhancement requests SUNRISE, regardless of the general opinion of the team/project. I am not in favor of an opt-in/opt-out system. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpFtgAb8bneR.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Henrik Brix Andersen wrote: On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote: I would have *no problem* with an opt-in system. Instead of using InOverlay (which is a poor choice anyway... which overlay?) as some sort of tag, instead, assign the package to the project which maintains the herd the package belongs to. If the project does not want it, then they can add SUNRISE to Keywords (in bugzilla). The Sunrise project then has permission to do with the package as they see fit. At *this* point, you could use InOverlay, since it would be pretty obvious which overlay it means. The real root of the problem is that packages that were once assigned to teams/projects are now being assigned into a generic dumping ground and being forgotten. You're trying to resolve this problem by moving them to another dumping ground, which I completely disagree with. A better solution would be to revert the broken behavior, and start assigning packages back to the projects, as it used to be done. Let the project decide if they want the package or not. If they don't, then they can simply add a single keyword and Sunrise can have at it. This pleases everyone, as packages can be maintained in Sunrise, and the projects still get to decide about packages that would likely affect them. It changes the project to an opt-in project, rather than having to track down things and opt-out. Except there is a flaw in your idea. As I see it, nothing prevents the developers of Project Sunrise from joining each and every team currently in existance and start marking enhancement requests SUNRISE, regardless of the general opinion of the team/project. I would presume if the team is against that the hypothetical developer would find him(her)self in a sticky situation and perhaps even get kicked off of the team(s) in question. Some teams actually talk to each other, have policy, etc. I am not in favor of an opt-in/opt-out system. Regards, Brix -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Chris Gianelloni wrote: 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 This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. You'll get mis-assigned bugs. Either don't do it or find another tag and get the DTD updated. herd is being used for assigning bugs, you are using it as a placeholder for something else. Category already tells us that it's a game, don't stick games into herd unless you actually maintain it. Thanks. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:01:04 +0200 Jakub Moc [EMAIL PROTECTED] wrote: This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. It's not new. If it confuses you, perhaps you should learn the terminology used in metadata before you try to assign bugs based upon it. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Stephen Bennett wrote: On Wed, 14 Jun 2006 20:01:04 +0200 Jakub Moc [EMAIL PROTECTED] wrote: This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. It's not new. If it confuses you, perhaps you should learn the terminology used in metadata before you try to assign bugs based upon it. Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. Meanwhile, I can just tell you that quite a bunch of people will actually get pretty angry once you start to apply this new on not-so-new terminology on stuff placed under their herd/project/whatever and will be dumping stuff on them... Like, perl, apache or php for starters. Because, they will get the bugs assigned, and they won't like it. And, we yet lack another method of assigning bugs other than using metadata.xml for this. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:21:42 +0200 Jakub Moc [EMAIL PROTECTED] wrote: Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? A herd has always been a group of packages for as long as I can recall, which is about two years now. It's nothing new at all. Packages in that herd can be maintained by a developer or a project, or by the group of herd maintainers if there are no specific arrangements. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote: Just because the maintaining *project* doesn't want it doesn't mean it doesn't belong to that herd. This is incorrect and you should not encourage people to add pkgs to a herd unless they get permission from that herd. If a herd does not want it you shall not shit in their home (it's rude). When a package lists a herd then the responsibility is shared among the maintainer and the herd. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Chris Gianelloni wrote: 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 _is_ no requirement that a package must belong to a herd. It's very good advice, and it's good for Gentoo, but it's _not_ a requirement. I'm sorry, but I think in this case what you are asserting isn't correct. Why does this matter? Why am I bringing this up? You are asking for the ability to 'opt out' of Project Sunrise, to decide that certain types of packages are not added to the Project Sunrise overlay; specifically, that games are not added to the Sunrise overlay. As I understand it, and I apologise if I'm wrong, these are packages that you (and your project) do not maintain at the moment - if you did, they would be in the tree. You have already strongly asserted in this thread how you feel about things needing to be in the tree. When I say I don't believe, I mean that I'm not aware of any Gentoo rule giving project leads any such dominion.I don't believe being the lead of any project (be it games, webapps, or anything else) gives _anyone_ the automatic right to suppress packages that you're not going to maintain - subject to the due diligence about dangerous packages and unmaintained packages that I mentioned earlier in this thread. I believe that this is a right that you are claiming for yourself; I'm sure you're doing so with good intentions. You've raised a lot of valid concerns about the plans of Project Sunrise, but here I think you're asking for too much, by trying to assert dominion over what simply isn't yours to control. It's reasonable (and existing Gentoo practice) to say hands off - we maintain that package. Saying hands off, but we are not going to maintain that package either ... it may be good for you, but I can't see how it's good for Gentoo - unless the package is dangerous. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Stephen Bennett wrote: On Wed, 14 Jun 2006 20:21:42 +0200 Jakub Moc [EMAIL PROTECTED] wrote: Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? Well, that obviously doesn't match the reality. So, if they actually _are_ maintained by the relevant herd, then you shouldn't dump stuff on that herd without discussing it w/ them first. I'm pretty sure mcummings will gladly explain to you what will happen if you do, as well as a bunch of other devs... :P To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... That's how the large part of current ~600 dev-perl/* ebuilds has made it into the tree and that mistake doesn't need to be repeated. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 22:34:55 +0200 Jakub Moc [EMAIL PROTECTED] wrote: Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? No; read the second paragraph. To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... ...so packages marked with a herd and a maintainer have bugs against them assigned to the maintainer. Sure, it would be polite to at least talk to the relevant herd maintainers before adding a package, but that holds regardless of whether you put it in the herd or not. Either way the bugs will go to the specific maintainer, so herds having bugs assigned to them that they don't care about isn't really an argument. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 15:54 +0200, Harald van Dijk wrote: On Wed, Jun 14, 2006 at 09:13:34AM -0400, Chris Gianelloni wrote: 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. Why do no games' metadata.xml specify games@ as the maintainer? I thought it was because herdgames/herd implies this already, but if it doesn't, then dozens of games can be considered unmaintained right now, and fair game for anyone to mess with without approval. Are you sure you like this interpretation of 'herd'? You're probably right that herd is supposed to mean what you say it does, but existing practise, even by yourself, is very different from it. Umm... no. See, if there's no maintainer listed, it defaults to the maintaining project *for that herd*... Here's another good example. Go and look at herds.xml and you'll see this: herd namegames/name email[EMAIL PROTECTED]/email descriptionGentoo Games Team/description maintainingproject/proj/en/desktop/games/index.xml/maintainingproject /herd As you can plainly see, the games team is the maintaining project for applications within the games herd, except in cases where a maintainer is explicitly listed. That wasn't so hard, now, was it? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 15:56 +0200, Henrik Brix Andersen wrote: On Wed, Jun 14, 2006 at 09:18:57AM -0400, Chris Gianelloni wrote: I would have *no problem* with an opt-in system. Instead of using InOverlay (which is a poor choice anyway... which overlay?) as some sort of tag, instead, assign the package to the project which maintains the herd the package belongs to. If the project does not want it, then they can add SUNRISE to Keywords (in bugzilla). The Sunrise project then has permission to do with the package as they see fit. At *this* point, you could use InOverlay, since it would be pretty obvious which overlay it means. The real root of the problem is that packages that were once assigned to teams/projects are now being assigned into a generic dumping ground and being forgotten. You're trying to resolve this problem by moving them to another dumping ground, which I completely disagree with. A better solution would be to revert the broken behavior, and start assigning packages back to the projects, as it used to be done. Let the project decide if they want the package or not. If they don't, then they can simply add a single keyword and Sunrise can have at it. This pleases everyone, as packages can be maintained in Sunrise, and the projects still get to decide about packages that would likely affect them. It changes the project to an opt-in project, rather than having to track down things and opt-out. Except there is a flaw in your idea. As I see it, nothing prevents the developers of Project Sunrise from joining each and every team currently in existance and start marking enhancement requests SUNRISE, regardless of the general opinion of the team/project. Sure there is. That is what we would call an abuse of power and should be met with the appropriate $smackdown on the developer who went and did such actions. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 20:01 +0200, Jakub Moc wrote: Chris Gianelloni wrote: 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 This new terminology plain sucks. If you are sticking games into herd in metadata.xml, you are just confusing me and other people who are assigning bugs. You'll get mis-assigned bugs. Either don't do it or find another tag and get the DTD updated. herd is being used for assigning bugs, you are using it as a placeholder for something else. Category already tells us that it's a game, don't stick games into herd unless you actually maintain it. Thanks. New terminology? That is the definition of a herd. If you're using it incorrectly to mean something else, that doesn't mean I'm changing anything. The category doesn't tell you *anything* about who maintains it. Take dev-util/catalyst as an example, or app-misc/livecd-tools. You can't glean *any* maintainer information from the category. It just happens that all of the games are also in games-* categories. However, there are even some packages which are not in games-* that belong to the games herd, and are maintained by the games team. Also, we almost *never* get bugs assigned to us that don't belong, except for in the cases where a maintainer is listed, yet games gets the bug anyway. These cases are simple cases of whomever is doing the reassigning not checking the metadata, so any changes in behavior won't make a bit of difference here. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 20:21 +0200, Jakub Moc wrote: Sure... so, perhaps you have some suggestion how I can read assign bugs otherwise than using the metadata.xml; perhaps I could learn to read minds of the developers who dump irrelevant stuff into metadata.xml and expect someone to know what they meant. It isn't irrelevant, at all. It is a grouping of packages beyond what is provided by the categories. The idea was to have certain projects responsible for certain herds, but that isn't a requirement. Meanwhile, I can just tell you that quite a bunch of people will actually get pretty angry once you start to apply this new on not-so-new terminology on stuff placed under their herd/project/whatever and will be dumping stuff on them... Like, perl, apache or php for starters. Because, they will get the bugs assigned, and they won't like it. And, we yet lack another method of assigning bugs other than using metadata.xml for this. Umm... There's the maintainer tag that you seem to be either forgetting or ignoring. If I had $random_perl_library and it had the herd as perl, yet me listed as the maintainer, who would get the bug? Are you telling me now that bug wranglers ignore the maintainer field? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote: On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote: Just because the maintaining *project* doesn't want it doesn't mean it doesn't belong to that herd. This is incorrect and you should not encourage people to add pkgs to a herd unless they get permission from that herd. If a herd does not want it you shall not shit in their home (it's rude). A herd doesn't *want* anything. It is a group of packages. Perhaps you mean a maintaining project? When a package lists a herd then the responsibility is shared among the maintainer and the herd. Only if someone didn't list themselves as the maintainer, which would be wrong. Just because the games team doesn't maintain something doesn't mean it isn't a game anymore. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 20:15 +0100, Stuart Herbert wrote: Chris Gianelloni wrote: 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 _is_ no requirement that a package must belong to a herd. It's very good advice, and it's good for Gentoo, but it's _not_ a requirement. I'm sorry, but I think in this case what you are asserting isn't correct. http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4 Specifically the listing for the herd tag. Just because people are doing things *wrong* doesn't mean that there isn't a defined manner in which things should be done. When I say I don't believe, I mean that I'm not aware of any Gentoo rule giving project leads any such dominion.I don't believe being the lead of any project (be it games, webapps, or anything else) gives _anyone_ the automatic right to suppress packages that you're not going to maintain - subject to the due diligence about dangerous packages and unmaintained packages that I mentioned earlier in this thread. I believe that this is a right that you are claiming for yourself; I'm sure you're doing so with good intentions. Here's where you start making wild assumptions. Who ever said that we don't intend on maintaining *every* ebuild that gets submitted to us? You are starting to put words into my mouth and making claims that I'm not making. Stop. You've raised a lot of valid concerns about the plans of Project Sunrise, but here I think you're asking for too much, by trying to assert dominion over what simply isn't yours to control. The bugs is assigned to the games team. Should I go and simply ACCEPT every single bug assigned to games in bugzilla, including all of the bug spam that will be caused by it, just to show that we *have* accepted these bugs, and are simply working through them at our own pace? It's reasonable (and existing Gentoo practice) to say hands off - we maintain that package. Correct. Saying hands off, but we are not going to maintain that package either ... it may be good for you, but I can't see how it's good for Gentoo - unless the package is dangerous. I never said this. Please don't try to use things that I never said as an argument, especially putting them in quotes, as if to quote me. You'll only serve to piss me off. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote: It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? Well, that Nobody said that they were unmaintained. Again, why do people *insist* on trying bullshit arguments like this? Are you claiming.. No, he's not claiming that, or he would have *said* that. obviously doesn't match the reality. So, if they actually _are_ maintained by the relevant herd, then you shouldn't dump stuff on that herd without discussing it w/ them first. I'm pretty sure mcummings will gladly explain to you what will happen if you do, as well as a bunch of other devs... :P A herd is a group of packages, not a listing of people. When you get information from the herds.xml, you are getting the listing of the people that *maintain* that herd. You are not getting a listing of the people *in* the herd. Please go back and read the herds project page[1] and try to understand this. It really is printed quite simply. To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... That's how the large part of current ~600 dev-perl/* ebuilds has made it into the tree and that mistake doesn't need to be repeated. You are correct. This is *exactly* how it works. Also, you'll notice that nothing either I or Stephen has said contradicts this, if you actually went back and contemplated what we both said. [1] http://www.gentoo.org/proj/en/metastructure/herds/ -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 17:25 -0400, Chris Gianelloni wrote: On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote: On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote: Just because the maintaining *project* doesn't want it doesn't mean it doesn't belong to that herd. This is incorrect and you should not encourage people to add pkgs to a herd unless they get permission from that herd. If a herd does not want it you shall not shit in their home (it's rude). A herd doesn't *want* anything. It is a group of packages. Perhaps you mean a maintaining project? Nope not at all see below. When a package lists a herd then the responsibility is shared among the maintainer and the herd. Only if someone didn't list themselves as the maintainer, which would be wrong. Just because the games team doesn't maintain something doesn't mean it isn't a game anymore. I think you are confusing a category/ vs a herd. But in the case of games@ only we can take your note and keep it in mind when adding new packages to the tree to go ahead and slap a games@ on it. But sorry not the rest of the tree. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On 6/14/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Wed, 2006-06-14 at 22:34 +0200, Jakub Moc wrote: It's not irrelevant; you're just not reading it properly. You might notice that metadata.xml contains tags other than herd, like, say, maintainer. In the example that sparked this, herd is games and maintainer the individual dev who maintains it. Simple enough, no? Please, go through the tree and see at least so many metadata.xml files as I have seen, before claiming something that simply doesn't reflect current practice. There are many ebuilds with no maintainer tag and herd only. Are you claiming that they are unmaintained? Well, that Nobody said that they were unmaintained. Again, why do people *insist* on trying bullshit arguments like this? Are you claiming.. No, he's not claiming that, or he would have *said* that. obviously doesn't match the reality. So, if they actually _are_ maintained by the relevant herd, then you shouldn't dump stuff on that herd without discussing it w/ them first. I'm pretty sure mcummings will gladly explain to you what will happen if you do, as well as a bunch of other devs... :P A herd is a group of packages, not a listing of people. When you get information from the herds.xml, you are getting the listing of the people that *maintain* that herd. You are not getting a listing of the people *in* the herd. According to the devmanual [1] A herd is a collection of developers who maintain a collection of related packages are you sure you are using the correct term? [1] http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html Please go back and read the herds project page[1] and try to understand this. It really is printed quite simply. To make it pretty clear and explicit - bugs gets assigned to maintainer (if there's any in metadata.xml), and get CCed to herd (if there's any in metadata.xml). If there's no maintainer, whoever is in herd will get that bug assigned and can happily smack you butt once they've find out you've dumped the package on them without their knowledge... That's how the large part of current ~600 dev-perl/* ebuilds has made it into the tree and that mistake doesn't need to be repeated. You are correct. This is *exactly* how it works. Also, you'll notice that nothing either I or Stephen has said contradicts this, if you actually went back and contemplated what we both said. [1] http://www.gentoo.org/proj/en/metastructure/herds/ -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEkIGskT4lNIS36YERAlg2AKCmitk2Pwd7XSP+ysarJDc1imbnUgCgt2wv OYJuhhIg+vG5wom7DRcwHEg= =Tprl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Dan Meltzer wrote: According to the devmanual [1] A herd is a collection of developers who maintain a collection of related packages are you sure you are using the correct term? [1] http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html I guess it needs to get fixed, then. Proof that documentation isn't perfect. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 14 Jun 2006 20:54:21 -0400 Dan Meltzer [EMAIL PROTECTED] wrote: | According to the devmanual [1] | A herd is a collection of developers who maintain a collection of | related packages | | are you sure you are using the correct term? Ah, yes, we're back to the old what is a herd? thing again. There're at least three equally valid definitions you can trot out depending upon which suits your argument. There's the original metastructure description, which was suitable in the old days but no matches the realities of how things are developed (especially the dumping packages part, which used to be standard practice and is now considered extremely rude), there's the herds are people definition that matches how the word is most usually used (and which was argued for earlier by some of the people who are now arguing for the old metastructure definition) and there's the pragmatic definition in the devmanual. Really, anyone arguing purely on definition is missing the point... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, Jun 13, 2006 at 01:29:55PM -0400, Peter wrote: [snip] This kernel source will not cause Armageddon to arrive, cause smoke to issue from your power supply, nor interfere with other ebuilds. That's funny. Did you just claim that a sys-kernel/*-sources ebuild with the patch-sets listed below would have no possibility of interfering with other ebuilds? If so, you've just proven my point that many users wont be able to judge how ebuilds from overlays may affect the stable tree. Features -ck(s) Con Kolivas Patchset, (server version available as option) -ide libATA/ide updates, Alsa updates and fixes, Dothan Speedstep, Pentium M undervolt, IBM ACPI fan control, Suspend2, vesafb-tng, reiser4, unionfs squashfs, realtime-lsm, fbsplash, configurable mouse polling support, custom dsdt, Layer7, various fixes and updates. [1] Am I being to simplistic or naive? Both, it seems. Regards, Brix [1]: http://bugs.gentoo.org/show_bug.cgi?id=103354#c51 -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpUVjE0JAgg3.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Tue, 2006-06-13 at 13:29 -0400, Peter wrote: As an example, there is a kernel source build I've been playing with. I know, from the kernel team, it will never, repeat NEVER, get onto the portage tree. they want no part of it. However, the bug is widely followed, and if Sunrise were to be a home to it, then these bug readers would be able to continue to work on the project. Why should it just waste away on bz? See bug # 103354 started by Scott Jones who did most of the work on it. This kernel source is also tracked on the gentoo forums. Using your example, if it will *never* make it into the tree, then what is it doing on *.gentoo.org infrastructure? The authors are more than welcome to host this on their own. There's absolutely zero reason for us to support it in any way, including our infrastructure, if there's absolutely no way that it will *ever* make it into the tree. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: Using your example, if it will *never* make it into the tree, then what is it doing on *.gentoo.org infrastructure? OK, I'll speak up. I plan on using overlay.gentoo.org for the perl team overlay repository. dev-perl alone has 600+ ebuilds - we are at the point where we are only adding those modules that have specific support requirements (makes foo work, etc). But there are plenty of packages we'd love to add, but don't have the manpower/resources to do it. Catalyst comes to mind - awesome take on the rails phenom, but the size and volume makes it tough to fit into our tree, and its one of the first things I plan on putting up in the overlay. As for the next bit: The authors are more than welcome to host this on their own. There's absolutely zero reason for us to support it in any way, including our infrastructure, if there's absolutely no way that it will *ever* make it into the tree. I don't have the resources to support it somewhere, simply put. I don't have a server somewhere I can point users to, or the kind of friends that will run an open svn (or whatever) on their boxes and host my overlays for me. Plus, this gives me/us a place to combine our resources, our overlays, into a cohesive whole. Some of it may make it in the tree one day; some not; some of it has too small an audience to add the requirements of maintainership to it - but at least it would be going somewhere. Just my two cents. Not sure about sunrise, but I'm all behind the overlays. ~mcummings -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjw6Zq1ztTp5/Ti4RAlBFAJ0TEsgWyNC1z0LoN1kipYOXWbZILQCgoqs0 UzZvAcL5AtQNU33yt1MZB5Y= =NM8w -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
