Re: [gentoo-dev] Herds, Teams and Projects
On Friday 28 April 2006 21:29, George Shapovalov wrote: > Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) Ви написали: > > OK; just to clarify my understanding, and perhaps for anyone else > > watching who saw things as muddled as I did: > > [skip] > > Just to be really anal :) > > > 3) A herd does not have an email address - it's not a person or group > > of people so an email address is nonsensical. > > 3a) A herd has an associated alias A team that maintains a herd may create a convenient mailing address on which matters for the specified herd can be handled. This email address may be used for multiple herds. (and as such does not need to be @g.o) > 3b) Individual developers add yourself (explicitly or get added by means of > herds.xml (gentoo module in cvs, under misc)) to this alias. Many herd maintenance teams/projects do have a free entry policy where you can enter by adding yourself to the alias and the herds.xml file. This could be indicated in herds.xml by a comment in the herd tag. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjsESxEMIta.pgp Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Wednesday 26 April 2006 20:29, Seemant Kulleen wrote: > I would like emphasise: > > A herd is a group of like *packages* > A team is a bunch of people who share a common goal (sometimes to > maintain a herd of packages). > A herd is also a bunch of mindless beasts who follow each other. does it really matter ? do the blurred lines between a herd and a team actually have some sort of detrimental affect ? using "teams" and "herds" interchangeably seems OK in my book ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Saturday, 29. April 2006 00:28, Kevin F. Quinn (Gentoo) Ви написали: > On Fri, 28 Apr 2006 21:29:58 +0200 > > George Shapovalov <[EMAIL PROTECTED]> wrote: > > Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) wrote: > > > 3) A herd does not have an email address - it's not a person or > > > group of people so an email address is nonsensical. > > > > 3a) A herd has an associated alias > > 3b) Individual developers add yourself (explicitly or get added by > > means of herds.xml (gentoo module in cvs, under misc)) to this alias. > > I thought this was the whole point of seemant's original message - it > is projects or teams that have a mail alias. Some herds happen to have > the same name as a project or team, but it's the team that you email, > not the herd. It doesn't make sense to email a herd, any more than it > makes sense to send email to an ebuild. It does however make sense to > email the maintainer of a herd, in the same way as it makes sense to > email the maintainer of an ebuild. Well, yes, you don't email a herd per se (if we strictly stick to these terms :)), but rather maintainers associated with it (via some project or listed in herds.xml). Above is just a mechanism that makes sure your email gets delivered to the right people. But we really now just do nitpicking of the terminology (which, although, the original message by Seemant was about). I just wanted to mention aliases to clarify the connection between packages, maintainers and herds.xml/metadata.xml. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Fri, 28 Apr 2006 21:29:58 +0200 George Shapovalov <[EMAIL PROTECTED]> wrote: > Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) wrote: > > 3) A herd does not have an email address - it's not a person or > > group of people so an email address is nonsensical. > 3a) A herd has an associated alias > 3b) Individual developers add yourself (explicitly or get added by > means of herds.xml (gentoo module in cvs, under misc)) to this alias. I thought this was the whole point of seemant's original message - it is projects or teams that have a mail alias. Some herds happen to have the same name as a project or team, but it's the team that you email, not the herd. It doesn't make sense to email a herd, any more than it makes sense to send email to an ebuild. It does however make sense to email the maintainer of a herd, in the same way as it makes sense to email the maintainer of an ebuild. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) Ви написали: > OK; just to clarify my understanding, and perhaps for anyone else > watching who saw things as muddled as I did: [skip] Just to be really anal :) > 3) A herd does not have an email address - it's not a person or group > of people so an email address is nonsensical. 3a) A herd has an associated alias 3b) Individual developers add yourself (explicitly or get added by means of herds.xml (gentoo module in cvs, under misc)) to this alias. George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
OK; just to clarify my understanding, and perhaps for anyone else watching who saw things as muddled as I did: 1) A herd is a group of packages, no more, no less. A package must be a member of at least one herd (since the herd entry is mandatory in metadata.xml, and metadata.xml is mandatory). 2) A package can belong to more than one herd. 3) A herd does not have an email address - it's not a person or group of people so an email address is nonsensical. 4) In the first instance, a package is maintained by those listed by maintainer entries in the package's metadata.xml 5) In the second instance, a package is maintained by the people indicated by the package's herd entry or entries at /gentoo/misc/herds.xml 6) The herd entry may specify directly a list of maintainers with optional roles, or may refer to projects or other herds to locate maintainers. Another way of looking at it; herds are a mechanism for locating maintainers for packages. Seems simple enough when written out like that - flame me if I have it wrong :) -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Thursday 27 April 2006 19:55, Henrik Brix Andersen wrote: > On Thu, Apr 27, 2006 at 07:11:33PM +0200, Paul de Vrieze wrote: > > The thing is, in most cases it doesn't really matter. But a herd is a > > group of packages. > > That may be how it was originally intended, but it seems to me - and > to others it seems - that the "herds" have evolved into what was > originally labeled "teams". > > I suggest we update the documentation to reflect this evolution, and > either rename "herds" to "teams" or vice versa. Using the word "team" > may have the benefit of improving the team spirit of the developer > community as a whole. At the mean time, I've just reworded the herds page to be a bit clearer. The difference between herds and teams is most in the fact that a team may easilly maintain multiple herds (but distinguish them for maintainability). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpIJwqsKlrfu.pgp Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 2006-04-27 at 14:14 -0400, Mike Frysinger wrote: > On Thursday 27 April 2006 10:54, Stuart Herbert wrote: > > I think the way forward would be to have this clarification (of herds > > vs teams) added to the metastructure document, and then for us to sort > > out the metadata.xml files on the back of that. > > imho, rather than "fixing" the people's understanding of > herds/teams/projects, > we "fix" the documents to reflect the meanings these terms have acquired As I said... I wouldn't have a problem with that. The only real issue I would see is do we really need 3 names for the same thing? I've always seen it as a team that maintains packages, and a project is an organizational unit (such as release engineering or infrastructure) that doesn't necessarily correlate to packages. Why not just s/herd/team/ and leave the project definition alone, as suggested earlier? Then we can quit discussing this and get back to breaking our new developer box. *grin* -- 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] Herds, Teams and Projects
On Thu, 2006-04-27 at 19:54 +0200, Kevin F. Quinn (Gentoo) wrote: > > Where? > > Two places. First, in the description of maintainer: > > "Besides being a member of a herd, a package can also be maintained > directly" > > which implies packages can be maintained by being a member of a herd and No, it doesn't. It *plainly* states that a package is a member of a herd, *or* it can also be maintained by a person. The problem is that there's nothing stating that a herd is maintained by a team or a project. > secondly where it says: > > "[herds] help manage the collection of ebuilds" > > I interpreted "manage" to include "maintain", since I couldn't think > of any other management that needs to be done. We read this differently. I read this as: manage the collection ... of ebuilds You read it as: manage the ... collection of ebuilds I can see where that can be confusing. Perhaps some better wording there would clear it up. > If we're to distinguish between herds and teams, and it seems that we > should, clearly something needs to define which teams maintain which > herds. Most are on the project pages, already. The biggest failure here is that there aren't project pages for all of the projects (or teams) out there maintaining packages. As an example, look at the output from the following piece of GuideXML from the http://www.gentoo.org/proj/en/desktop/games/index.xml page. This gives the following output on the page: 4. Herds The Games project maintains the following herds: Herd Members Description games Mr_Bones_, Tupone, genstef, vapier, wolf31o2 Gentoo Games Team This clearly shows the relationship of a project to a herd, yet *also* helps in confusing the issue by listing the developers responsible for the herd, as *members* of the herd. > I do think that metadata.xml should always indicate who maintains a > package, whether it's a single maintainer or a team of maintainers - > including who is the backup should the primary maintainer be > unavailable for an urgent change. If the herd is nothing to do with who > maintains a package, then the maintainer entry should be mandatory; > there can be multiple entries and it's easy enough to set up team mail > aliases. I also think it should be clear in metadata.xml who the > "backup" maintainers are if such exist - i.e. someone who can process > stuff in the absence of the primary maintainer. I'd tend to agree with you here. The main thing is that in most cases, the project/team maintaining the packages has the exact same name as the herd it maintains, which would make the extra data a bit redundant. After all, do we really need: games [EMAIL PROTECTED] The data is fairly redundant, in this case. Perhaps what we need more is a single location that maps the list of projects/teams to packages? > Maybe other people were assuming, like me, that if maintainer is > missing then the herd was the mail alias to write to. I can see from > what you're saying that the herd name is not a mail alias (since it > doesn't refer to people). I would venture a bet that in most, if not all cases in the tree, that you are absolutely correct. The herd name generally corresponds with the team name. I can think of a few exceptions to this rule, such as portage bugs go to dev-portage, rather than portage. There are also examples of project/team email aliases being listed as the maintainer, such as with catalyst or sandbox. > It definitely seems that we need to define somewhere which teams > maintain which herds. The games example is perhaps obvious, but in > general that won't be the case. It's listed on the games project page, as is the case in quite a few other projects, and should be the case in *all* projects/teams. > Perhaps for simplicity (and to save having to edit 6k+ metadata.xml > files), we could rule that if the maintainer entry is missing, and the > herd name is the same as a team name, that team is the maintainer for > the package. That would be fine and tends to match what we are currently using, meaning there's no change in behavior required. The only files that would/should need editing are ones where the herd name does not directly correspond with the project/team alias, such as my given portage example. > > > It would be useful to know how many people think herds are not > > > maintainers - if only a few people think this then I suggest it > > > would be better to accept the common interpretation of herd as a > > > group of people who can maintain a package. > > > > I definitely do not think that herds are maintainers. At the same > > time, I understand that many people do think this, so I'm willing to > > change *my* definition to match what the in practice definition ends > > up being, if necessary. > > So what are the herds supposed to achieve? It would be useful to see > some examples of what herds are/could be useful for. I'm happy to go > with the intended definition of herd, but it certainly could be clearer > in
Re: [gentoo-dev] Herds, Teams and Projects
Hi Mike, On 4/27/06, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Thursday 27 April 2006 10:54, Stuart Herbert wrote: > > I think the way forward would be to have this clarification (of herds > > vs teams) added to the metastructure document, and then for us to sort > > out the metadata.xml files on the back of that. > > imho, rather than "fixing" the people's understanding of herds/teams/projects, > we "fix" the documents to reflect the meanings these terms have acquired > -mike Quite possibly. Whatever the outcome, the document needs to reflect reality. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Thursday 27 April 2006 10:54, Stuart Herbert wrote: > I think the way forward would be to have this clarification (of herds > vs teams) added to the metastructure document, and then for us to sort > out the metadata.xml files on the back of that. imho, rather than "fixing" the people's understanding of herds/teams/projects, we "fix" the documents to reflect the meanings these terms have acquired -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 2006-04-27 at 15:54 +0100, Stuart Herbert wrote: > > A herd is a group of like *packages* > > A team is a bunch of people who share a common goal (sometimes to > > maintain a herd of packages). > > A herd is also a bunch of mindless beasts who follow each other. > > The metastructure document (which we voted in as our governing > document last year) uses the term 'project' instead of team, and makes > no mention of herds at all. Except the metastructure document actually has zero bearing in this, since it wasn't a proposal of how to maintain packages. It was a proposal on how we would try to organize ourselves. A herd plays no part in this organization, which is why it wasn't mentioned then, and shouldn't be mentioned now. > I think the way forward would be to have this clarification (of herds > vs teams) added to the metastructure document, and then for us to sort > out the metadata.xml files on the back of that. > > I guess any change to that document should be subject to a vote. I sincerely hope that we do not change that document, which was quite good at pertaining only to what was necessary, into trying to be some form of document to pertain to everything. -- 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] Herds, Teams and Projects
On Thu, Apr 27, 2006 at 07:11:33PM +0200, Paul de Vrieze wrote: > The thing is, in most cases it doesn't really matter. But a herd is a group > of > packages. That may be how it was originally intended, but it seems to me - and to others it seems - that the "herds" have evolved into what was originally labeled "teams". I suggest we update the documentation to reflect this evolution, and either rename "herds" to "teams" or vice versa. Using the word "team" may have the benefit of improving the team spirit of the developer community as a whole. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpOuyYIxzSQU.pgp Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 27 Apr 2006 10:27:12 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: > On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote: > > I must admit I've assumed that the herd entry in metadata.xml is a > > reasonable fall-back if the maintainer entry is missing or the > > listed maintainer is away/not responding. This is implied by > > http://www.gentoo.org/proj/en/metastructure/herds/index.xml which > > requires but not - also the description of > > says "Besides being a member of a herd, a package can > > also be maintained directly" which implies the herd is the default > > maintainer if maintainer is not present. > > Well, the herd listing shows what herd that it belongs to, not the > team that manages that herd. I think that this is the confusion. For > example, catalyst has livecd listed as its herd. However, there is > not a "livecd" project, nor team. Instead, the "livecd" herd is > maintained by myself, solely, except for genkernel and catalyst, that > have alternate maintainers. In the case of catalyst, an alias is > listed as the maintainer, since there *is* a catalyst team, albeit > small. > > > The herds project description says, "The herds project aims to > > ensure that the growing number of ebuilds do not overwelm (sic) the > > gentoo project. To this end the herds project aims for the > > development of infrastructure that will help manage the collection > > of ebuilds". This clearly indicates herds are supposed to have a > > maintainer role. > > Where? Two places. First, in the description of maintainer: "Besides being a member of a herd, a package can also be maintained directly" which implies packages can be maintained by being a member of a herd and secondly where it says: "[herds] help manage the collection of ebuilds" I interpreted "manage" to include "maintain", since I couldn't think of any other management that needs to be done. If we're to distinguish between herds and teams, and it seems that we should, clearly something needs to define which teams maintain which herds. > I can see how you can interpret it like that, but it is anything but > clear in stating it. In fact, it mentions nothing about maintaining > any packages, but rather to "manage the collection" of them, which > leads me to read it as it is there solely for creating a logical > grouping of specific packages, much like how categories work in the > tree itself. For example, look at openal. It is a package in the > "sound" herd, yet the sound *team* does not maintain it. I do. > > > A quick scan of the tree shows that some 6k+ packages have no > > maintainer entry. > > Well, ~700 of those are games, which belong to the games herd, and > have no specific maintainer. The games *team* maintains all packages > in the games herd that does not have a specific maintainer listed. > It just so happens that in *many* cases, the project (or team) has > the same name as the herd to which the package belongs. I think that > this has been the cause of the confusion, more than the definitions. I do think that metadata.xml should always indicate who maintains a package, whether it's a single maintainer or a team of maintainers - including who is the backup should the primary maintainer be unavailable for an urgent change. If the herd is nothing to do with who maintains a package, then the maintainer entry should be mandatory; there can be multiple entries and it's easy enough to set up team mail aliases. I also think it should be clear in metadata.xml who the "backup" maintainers are if such exist - i.e. someone who can process stuff in the absence of the primary maintainer. Maybe other people were assuming, like me, that if maintainer is missing then the herd was the mail alias to write to. I can see from what you're saying that the herd name is not a mail alias (since it doesn't refer to people). It definitely seems that we need to define somewhere which teams maintain which herds. The games example is perhaps obvious, but in general that won't be the case. Perhaps for simplicity (and to save having to edit 6k+ metadata.xml files), we could rule that if the maintainer entry is missing, and the herd name is the same as a team name, that team is the maintainer for the package. > > It would be useful to know how many people think herds are not > > maintainers - if only a few people think this then I suggest it > > would be better to accept the common interpretation of herd as a > > group of people who can maintain a package. > > I definitely do not think that herds are maintainers. At the same > time, I understand that many people do think this, so I'm willing to > change *my* definition to match what the in practice definition ends > up being, if necessary. So what are the herds supposed to achieve? It would be useful to see some examples of what herds are/could be useful for. I'm happy to go with the intended definition of herd, but it certainly could be clearer in the docum
Re: [gentoo-dev] Herds, Teams and Projects
On Thursday 27 April 2006 09:22, Kevin F. Quinn (Gentoo) wrote: > On Wed, 26 Apr 2006 20:29:32 -0400 > > Seemant Kulleen <[EMAIL PROTECTED]> wrote: > > To that end, it's been brought up that perhaps the metadata.xml files > > are partly to blame, in that they imply that the package is maintained > > by a herd. There is not maintainer-team listed, just a herd. > > > > So, I would like to propose that we make this distinction clearer in > > the metadata.xml files. I'm interested in thoughts that people have > > on this, but please do cc: me in your response to be assured that I > > read it. > > I must admit I've assumed that the herd entry in metadata.xml is a > reasonable fall-back if the maintainer entry is missing or the listed > maintainer is away/not responding. This is implied by > http://www.gentoo.org/proj/en/metastructure/herds/index.xml which > requires but not - also the description of > says "Besides being a member of a herd, a package can also > be maintained directly" which implies the herd is the default maintainer > if maintainer is not present. The package is a member of the herd, not the maintainer. It means that the herd maintainers are the default maintainers of a package. > > The herds project description says, "The herds project aims to ensure > that the growing number of ebuilds do not overwelm (sic) the gentoo > project. To this end the herds project aims for the development of > infrastructure that will help manage the collection of ebuilds". This > clearly indicates herds are supposed to have a maintainer role. You read it wrong (I wrote that text, so I should know). The idea is to have a group of people that manages (a group|groups) of packages. A group of packages is a herd. A group of people is a project or a team (an informal project). > > A quick scan of the tree shows that some 6k+ packages have no > maintainer entry. > > It would be useful to know how many people think herds are not > maintainers - if only a few people think this then I suggest it would > be better to accept the common interpretation of herd as a group of > people who can maintain a package. The thing is, in most cases it doesn't really matter. But a herd is a group of packages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbl4L9e9EoC.pgp Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
Hi Seemant, On 4/27/06, Seemant Kulleen <[EMAIL PROTECTED]> wrote: > > Hi All, > > Consider this both a rant and a GLEP pre-proposal. When we created the > idea of herds back in the day, there was a clear distinction between a > herd and a team (and a project). Over time, those definitions have > become blurry. I would like emphasise: > > A herd is a group of like *packages* > A team is a bunch of people who share a common goal (sometimes to > maintain a herd of packages). > A herd is also a bunch of mindless beasts who follow each other. The metastructure document (which we voted in as our governing document last year) uses the term 'project' instead of team, and makes no mention of herds at all. I think the way forward would be to have this clarification (of herds vs teams) added to the metastructure document, and then for us to sort out the metadata.xml files on the back of that. I guess any change to that document should be subject to a vote. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Thu, 2006-04-27 at 09:22 +0200, Kevin F. Quinn (Gentoo) wrote: > I must admit I've assumed that the herd entry in metadata.xml is a > reasonable fall-back if the maintainer entry is missing or the listed > maintainer is away/not responding. This is implied by > http://www.gentoo.org/proj/en/metastructure/herds/index.xml which > requires but not - also the description of > says "Besides being a member of a herd, a package can also > be maintained directly" which implies the herd is the default maintainer > if maintainer is not present. Well, the herd listing shows what herd that it belongs to, not the team that manages that herd. I think that this is the confusion. For example, catalyst has livecd listed as its herd. However, there is not a "livecd" project, nor team. Instead, the "livecd" herd is maintained by myself, solely, except for genkernel and catalyst, that have alternate maintainers. In the case of catalyst, an alias is listed as the maintainer, since there *is* a catalyst team, albeit small. > The herds project description says, "The herds project aims to ensure > that the growing number of ebuilds do not overwelm (sic) the gentoo > project. To this end the herds project aims for the development of > infrastructure that will help manage the collection of ebuilds". This > clearly indicates herds are supposed to have a maintainer role. Where? I can see how you can interpret it like that, but it is anything but clear in stating it. In fact, it mentions nothing about maintaining any packages, but rather to "manage the collection" of them, which leads me to read it as it is there solely for creating a logical grouping of specific packages, much like how categories work in the tree itself. For example, look at openal. It is a package in the "sound" herd, yet the sound *team* does not maintain it. I do. > A quick scan of the tree shows that some 6k+ packages have no > maintainer entry. Well, ~700 of those are games, which belong to the games herd, and have no specific maintainer. The games *team* maintains all packages in the games herd that does not have a specific maintainer listed. It just so happens that in *many* cases, the project (or team) has the same name as the herd to which the package belongs. I think that this has been the cause of the confusion, more than the definitions. > It would be useful to know how many people think herds are not > maintainers - if only a few people think this then I suggest it would > be better to accept the common interpretation of herd as a group of > people who can maintain a package. I definitely do not think that herds are maintainers. At the same time, I understand that many people do think this, so I'm willing to change *my* definition to match what the in practice definition ends up being, if necessary. -- 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] Herds, Teams and Projects
Kevin F. Quinn (Gentoo) wrote: >It would be useful to know how many people think herds are not >maintainers - if only a few people think this then I suggest it would >be better to accept the common interpretation of herd as a group of >people who can maintain a package. > > > I've always considered herd == maintainer. When a package is related to one of the herd I'm part of, I prefer setting it in metadata.xml instead of adding myself as the maintainer of the package. A herd should be more responsive than a single individual (depending on the size of the herd, of course). Also, it would mean less things to do when the maintainer leaves from Gentoo dev community. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds, Teams and Projects
On Wed, 26 Apr 2006 20:29:32 -0400 Seemant Kulleen <[EMAIL PROTECTED]> wrote: > To that end, it's been brought up that perhaps the metadata.xml files > are partly to blame, in that they imply that the package is maintained > by a herd. There is not maintainer-team listed, just a herd. > > So, I would like to propose that we make this distinction clearer in > the metadata.xml files. I'm interested in thoughts that people have > on this, but please do cc: me in your response to be assured that I > read it. I must admit I've assumed that the herd entry in metadata.xml is a reasonable fall-back if the maintainer entry is missing or the listed maintainer is away/not responding. This is implied by http://www.gentoo.org/proj/en/metastructure/herds/index.xml which requires but not - also the description of says "Besides being a member of a herd, a package can also be maintained directly" which implies the herd is the default maintainer if maintainer is not present. The herds project description says, "The herds project aims to ensure that the growing number of ebuilds do not overwelm (sic) the gentoo project. To this end the herds project aims for the development of infrastructure that will help manage the collection of ebuilds". This clearly indicates herds are supposed to have a maintainer role. A quick scan of the tree shows that some 6k+ packages have no maintainer entry. It would be useful to know how many people think herds are not maintainers - if only a few people think this then I suggest it would be better to accept the common interpretation of herd as a group of people who can maintain a package. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Herds, Teams and Projects
Mike Frysinger wrote: On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote: Daniel Goller wrote: I like the idea. (But i guess you figured that out already ;) To make it easy, we could just s/herd/team/. then you might as well just keep herd and discard team altogether Yeah, pretty much it would be saying "herds are now teams, but not all teams maintain packages." Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Wednesday 26 April 2006 22:38, Donnie Berkholz wrote: > Daniel Goller wrote: > > I like the idea. (But i guess you figured that out already ;) > > To make it easy, we could just s/herd/team/. then you might as well just keep herd and discard team altogether -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Daniel Goller wrote: I like the idea. (But i guess you figured that out already ;) To make it easy, we could just s/herd/team/. Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seemant Kulleen wrote: >> Is there a reason for this besides the definitions not falling into >> place as they should? I'm not seeing a benefit from this to be honest. >> People refer to teams as herds a lot of the time. It has become a >> statement over time that people understand. I'm not sure why we want to >> try and change that to something else, even if that was what it was >> supposed to mean to begin with. > > It's a niggling thing and nothing major as such. But ideas flow from > concepts. And the idea that developers are in herds is not a solid > concept from which to begin. > > While the Ciaran episode has come to an end, the circumstances that led > to that episode have not changed: mutual respect for fellow developers. > That is the idea. The concept should lay that down: a developer is not > a mindless follower, but a human being and a talented developer worthy > of respect. > > This is a very small issue in the scheme of things, and a small hole to > fill. I'd rather fill it in now :) > > Because it's supposed to be fun, too. > > Thanks, > > Seemant At the very least it carries an interesting message, and is so positive we could all think about it and maybe we could go "cool". I like the idea. (But i guess you figured that out already ;) Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUCVP/aM9DdBw91cRAhwZAJ9iZfCATRYUk6ApxuLaY+aNRIdfJQCeIXXI ZDX5NFtScuc07p8wG52IPYs= =EtMC -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
> Is there a reason for this besides the definitions not falling into > place as they should? I'm not seeing a benefit from this to be honest. > People refer to teams as herds a lot of the time. It has become a > statement over time that people understand. I'm not sure why we want to > try and change that to something else, even if that was what it was > supposed to mean to begin with. It's a niggling thing and nothing major as such. But ideas flow from concepts. And the idea that developers are in herds is not a solid concept from which to begin. While the Ciaran episode has come to an end, the circumstances that led to that episode have not changed: mutual respect for fellow developers. That is the idea. The concept should lay that down: a developer is not a mindless follower, but a human being and a talented developer worthy of respect. This is a very small issue in the scheme of things, and a small hole to fill. I'd rather fill it in now :) Because it's supposed to be fun, too. Thanks, Seemant -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
Seemant Kulleen <[EMAIL PROTECTED]> said: > Consider this both a rant and a GLEP pre-proposal. When we created the > idea of herds back in the day, there was a clear distinction between a > herd and a team (and a project). Over time, those definitions have > become blurry. I would like emphasise: > > A herd is a group of like *packages* > A team is a bunch of people who share a common goal (sometimes to > maintain a herd of packages). > A herd is also a bunch of mindless beasts who follow each other. > > > To that end, it's been brought up that perhaps the metadata.xml files > are partly to blame, in that they imply that the package is maintained > by a herd. There is not maintainer-team listed, just a herd. > > So, I would like to propose that we make this distinction clearer in the > metadata.xml files. I'm interested in thoughts that people have on > this, but please do cc: me in your response to be assured that I read > it. Is there a reason for this besides the definitions not falling into place as they should? I'm not seeing a benefit from this to be honest. People refer to teams as herds a lot of the time. It has become a statement over time that people understand. I'm not sure why we want to try and change that to something else, even if that was what it was supposed to mean to begin with. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpBsqIgO3rqh.pgp Description: PGP signature
