[gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Richard Fish posted [EMAIL PROTECTED], excerpted below, on Wed, 26 Apr 2006 22:10:27 -0700: So maybe this could be satisified by allowing user-defined categories of packages beyond system and world? Something like world, system, fragile, non-fragile? Actually, that's called set support, and it's actively planned for a future portage. I haven't been tracking it to the point where I know what the implementation status is, but it's very likely in portage-core (aka savior aka portage-ng, portage folks correct me if I'm simply confused) to some extent now. Again, portage-devel would be the preferred place for discussions. (As used to be common courtesy with groups/lists, reading up on the last few weeks to 3 months worth of existing messages before posting something that will then be understood to be a FAQ, is nice, but the devs don't usually bite too hard if you don't. =8^) I think you could probably implement something like this yourself with a bit of trickery with the /var/lib/portage/world list. You could copy world to non-fragile, remove anything that you consider fragile from it, and then do an automatic update with: cp /var/lib/portage/world /var/lib/portage/world.bak cp /var/lib/portage/non-fragile /var/lib/portage/world emerge -DNuv world cp /var/lib/portage/world.bak /var/lib/portage/world A similar script for the fragile packages would let you update those as a group, obviously using the -p and/or --ask options as you like. Actually, the idea is slightly more complicated at one step, and slightly less at another, but very workable with existing portage. You can't simply begin with the world file, as that by definition won't necessarily include stuff in system. Rather, begin with the world file, then add the stuff in system. (The best way is probably to walk your profile tree following the parent nodes, and include what you find in packages.) Or, start generate the initial list with an emerge --pretend --emptytree newpkglist Note that the latter, however, will include trunk and branch packages as well as the leaf packages normally found in world. This would therefore require the use of --oneshot with any emerge based on the list, so as to prevent stuffing world with unnecessary dependencies. Those dependencies can also change over time, one of the reasons you /don't/ want them in world (and why an occasional emerge --depclean --pretend is recommended as routine system hygiene on a Gentoo system, generating a list to either be added to world or unmerged as necessary, read the docs for more information if you aren't already doing this as part of your normal routine). Due to this change over time, if you use this generation method, you'll also wish to regenerate the list periodically. OTOH, it'll give you a more accurate list to start with, if you consider any of the dependencies especially fragile or robust, since they'd not be directly handled using the first generation method, only treated as dependencies. In any case, once you get your list and weed out the stuff you /don't/ want on it, rather than doing that copy trickery, try this: emerge -NuDv $(cat /path/to/listfile) Again, the usual pretend/ask situation applies, and --oneshot should be added since you are updating specific packages from the command line. Also consider the effect of the -D and -N flags, as depending on your exact needs, --newuse and --deep may or may not be suitable. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
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 herd but not maintainer - also the description of maintainer 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
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
[gentoo-dev] SHA256 digest issues
As reported in bug 131293 a pycrypto bug caused a lot of digest and Manifest files to be created with bogus sha256 hashes. A fixed pycrypto (2.0.1-r5) was committed to the tree. This means the following: - If you run ~arch portage and the latest pycrypto you will hit digest failures. You will hit fewer digest failures as packages are fixed. - If you run ~arch portage and do not upgrade pycrypto you will hit more and more digest issues as stuff is fixed. - If you run stable portage you are not affected. If you commit to the tree with an unfixed pycrypto you can add new broken digests, so please do not do that. We (portage project) are fixing known broken Manifests/digests. If you come across any broken SHA256 digests feel free to fix them though: the package is basically unusable with ~arch portage until it is fixed, and fixing it twice does not really hurt :) Apologies for the inconvenience. -- Marien. pgpOBtdXlWs8r.pgp Description: PGP signature
Re: [gentoo-dev] SHA256 digest issues
On Thu, 27 Apr 2006 12:50:02 +0200 Marien Zwart [EMAIL PROTECTED] wrote: | We (portage project) are fixing known broken Manifests/digests. If you | come across any broken SHA256 digests feel free to fix them though: | the package is basically unusable with ~arch portage until it is | fixed, and fixing it twice does not really hurt :) If you're looking to avoid downloading too much... All source tarballs whose file size (mod 64) is 55 are the ones affected, which would suggest that somewhere very roughly in the region of one package in sixty four with SHA256 digests is h0rked. There's a good testsuite which would have caught this at [1]. [1]: http://csrc.nist.gov/cryptval/shs.htm -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
On 4/27/06, Duncan [EMAIL PROTECTED] wrote: In any case, once you get your list and weed out the stuff you /don't/ want on it, rather than doing that copy trickery, try this: Yeah, much smarter than my cp tricks. Although using emerge to generate the package list will have a problem in that it contains the versions, which is not what you want for this. But we seem to have going completely off-topic for -dev now... -Richard -- 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 herd but not maintainer - also the description of maintainer 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
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 herd but not maintainer - also the description of maintainer 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
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 herd but not maintainer - also the description of maintainer 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 documentation. -- Kevin F. Quinn -- Kevin F. Quinn signature.asc
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
[gentoo-dev] Which license?
Im working on an ebuild for a package and Im not sure what license to use. The package is Copyright Company X but has this underneath: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. ## ## There is no warranty or other guarantee of fitness of this software. ## It is provided solely as is. The author(s) disclaim(s) all ## responsibility and liability with respect to this software's usage ## or its effect upon hardware, computer systems, other software, or ## anything else. ## Last time I looked, there were some 800 or so files in /usr/portage/license/ - so which one would I use? -- Aj -- 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 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] Which license?
A. Khattri wrote: Im working on an ebuild for a package and Im not sure what license to use. The package is Copyright Company X but has this underneath: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. I grepped /usr/portage/licenses/ for the typo in this license -- non-commerical -- and came up with /usr/portage/licenses/XAnim, which very closely resembles this one. The only difference is the addition of and unmodified.. which I think is implied by intact. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
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 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. herd name=games/ 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: herdgames/herd maintainer[EMAIL PROTECTED]/maintainer 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 the documentation. Well,
Re: [gentoo-dev] Which license?
On Thu, 2006-04-27 at 14:21 -0400, A. Khattri wrote: Im working on an ebuild for a package and Im not sure what license to use. The package is Copyright Company X but has this underneath: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. ## ## There is no warranty or other guarantee of fitness of this software. ## It is provided solely as is. The author(s) disclaim(s) all ## responsibility and liability with respect to this software's usage ## or its effect upon hardware, computer systems, other software, or ## anything else. ## Last time I looked, there were some 800 or so files in /usr/portage/license/ - so which one would I use? I'd go for AS-IS. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Which license?
On Thu, Apr 27, 2006 at 02:21:38PM -0400, A. Khattri wrote: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. Last time I looked, there were some 800 or so files in /usr/portage/license/ - so which one would I use? free-noncomm looks like a good match. -- - [EMAIL PROTECTED] | finger me for my pgp key. --- pgpIvSqoCKVRn.pgp Description: PGP signature
Re: [gentoo-dev] Which license?
A. Khattri wrote: Im working on an ebuild for a package and Im not sure what license to use. The package is Copyright Company X but has this underneath: ## This software may be freely copied, modified and redistributed ## without fee for non-commerical purposes provided that this license ## remains intact and unmodified with any distribution. ## ## There is no warranty or other guarantee of fitness of this software. ## It is provided solely as is. The author(s) disclaim(s) all ## responsibility and liability with respect to this software's usage ## or its effect upon hardware, computer systems, other software, or ## anything else. ## Last time I looked, there were some 800 or so files in /usr/portage/license/ - so which one would I use? LICENSE=as-is ? IANAL signature.asc Description: OpenPGP digital 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] Re: Wishlist: an automated package upgrade system with fine-tunable sysadmin control
Thank you both for your detailed replies. I've got quite a list of additional notions now for trying to implement this idea myself, and I'm very grateful for the thoughtful suggestions. I also have a better understanding of current portage capabilities, so I appreciate the additional commentary on that. If I explore this idea with any further discussion, I'll be sure to follow the suggestions here about another list and reading past messages on that list. -Kevin -- gentoo-dev@gentoo.org mailing list
Re: [OT] [gentoo-dev] Version bumps, keywords and you
Jason Wever wrote: In the really off chance that you've just had a run-in with a Vorgon poetry session Isn't it a *Vogon* poetry? Cheers, -jkt -- cd /local/pub more beer /dev/mouth -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo, Google's Summer of Code, and You
As many of you know by now, Gentoo has been chosen to fill one of the last spaces in this year's Google Summer of Code. This is a great opportunity for developers and users to interact and help out Gentoo as well as the OSS community. For those of you who haven't heard of Google's Summer of Code, here is a quick overview. Google's SoC is an initiative whereby Google funds the development of a selected number of OSS projects. This year, only students are allowed to do actual development for Google's SoC. But anyone who is a Gentoo developer can mentor a Student on one of the projects for which Gentoo is the Mentoring Organization. The role of a Mentor is as someone who has knowledge in the project domain and can assist the student in a strategic development role, as opposed to actually writing code. Mentors are involved in evaluating the work of the student and monitoring the project's progress, and is also instrumental in enabling the student to complete the project by providing the student with the tools needed to complete the project (think about someone who needs read-only cvs access to the tree, for example). Prospective Mentors: All Gentoo developers should have received the mail sent to -core about Gentoo's acceptance into Google SoC. The information and links to sign up as a Mentor for Gentoo are enclosed in that mail, whose message ID has been provided for your reference [1]. If you are interested please see the -core e-mail for details, as well as the Mentor FAQ[6]. You cannot be both a Mentor and a Student in SoC. Please choose carefully which role you will play. Those who are not Gentoo developers may stll apply for the role of Mentor on behalf of Gentoo. If you are not a Gentoo developer but are interested in applying, please stop by the IRC[4] channel or send mail to Gentoo User Relations[7]. Please have a few projects in mind when applying for Mentorship. The Gentoo SoC team is hoping to have more Mentors than projects; backup Mentors are encourage by Google. Attention Gentoo developers: You cannot be both a Mentor and a Student, so please be aware that you must work on a proposal that is different from your normal Gentoo work if you are looking to participate in SoC as a Student. Mentors, if you have applied and have not yet heard back please contact the Gentoo SoC project leads for the outcome of your application[2]. Prospective Students: If you are interested in participating as a student with Gentoo for the SoC, please take a look at our current project list[2]. Note that it is undergoing continuous improvement as we add proposals, Mentors, etc. All interested students should refer to Google's Student FAQ[3] to check whether they are eligible to participate in the SoC with Gentoo. For Gentoo developers who are also Students, you are probably eligible to work on SoC for Gentoo provided you work on a proposal that is in a different area than your normal Gentoo developer work. Once again please check the Student FAQ[3] for more details. Student applications are open May 1st through the 8th. The URL for the student application is not yet known. The project page will be updated with the link as soon as we receive it from Google. Project Ideas/Discussion: Anyone can submit project ideas and contribute to the discussion of existing project ideas. Those who have new ideas or comments on existing ideas for Gentoo's SoC, please submit them via E-mail to the Gentoo SoC mailing list[4] or on IRC[5]. If you are unsure of your idea or wish to ask questions you may do so via the same means. As always, feel free to ask any questions using those two avenues of communication to ensure that the correct people receive your thoughts. Thanks, The Gentoo Summer Of Code Project [1] Message-ID: [EMAIL PROTECTED] [2] http://www.gentoo.org/proj/en/devrel/user-relations/summerofcode/index.xml [3] http://code.google.com/soc/studentfaq.html [4] [EMAIL PROTECTED] [5] #gentoo-soc @ irc.freenode.net [6] http://code.google.com/soc/mentorfaq.html [7] [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
