Re: [gentoo-dev] Re: amd64 help
On Mon, 29 Jan 2007 08:15:18 +0100 (MET) Christian Faulhammer [EMAIL PROTECTED] wrote: Ciaran McCreesh [EMAIL PROTECTED]: On Sun, 28 Jan 2007 19:17:35 +0100 (MET) Christian Faulhammer [EMAIL PROTECTED] wrote: | As we all notice from time to time, amd64 team is lacking behind a | bit, due to various reasons. a) manpower, b) a lot of keywording. | Java team asked arch teams if they object when Java team marks stable | generation-2 ebuilds on their own, due to the long time it takes and | to the amount of ebuilds to be stabilised. | So, maybe we can discuss here another helping hand for amd64. Devs | that work with a given software (not necessarily the maintainer) on | amd64 architecture and when there is a keywording bug open, then said | devs can keyword the ebuild. For a short period of time this could be | allowed to all devs. | Any objections? Why not just extend the amd64 team to include people who will only work on Java stuff? Other arch teams have no problems with developers being onboard only for a few particular packages. Because it was meant for every package and I only talk about keywording ~amd64, not stabling. The latter is handled by the team in a timely manner, but keywording is put aside (it leads to even more stabling, once it is keyworded). Java was only mentioned, as they came up with an idea to help amd64 in special and arch teams in general. AFAIK that has been the (unofficial?) policy of the AMD64 team for as long as I can remember. Marius -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
On Sun, Jan 28, 2007 at 02:24:49PM -0800, Mike Doty wrote: 1. re-elect a whole new council. Seems to be overkill to me. 2. elect a new member at a reduced term to fill the vacancy. Personally i'd rather go with #3, but the GLEP also states: If a council member who has been marked a slacker misses any further meeting (or their appointed proxy doesn't show up), they lose their position and a new election is held to replace that person. The newly elected council member gets a 'reduced' term so that the yearly elections still elect a full group. Seems to be the closest case to a member simply resigning with the slacker regulation. 3. take the 8th spot from the last election. Seems to be the best - and least complicated - version to me. 4. The position stays empty until the next election (As long the number of council members doesn't drop below a certain number, let's say 5. Just adding this as it may be an option, too. The spirit of the GLEP would indicate option 2, but it's never spelled out. Speak out now if you have a opinion on the subject. Agreed, personally i'd go with #2. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp9Wk3Aft4Vi.pgp Description: PGP signature
Re: [gentoo-dev] Topic for Feb council meeting
On Monday 29 of January 2007 12:46:33 Wernfried Haas wrote: 4. The position stays empty until the next election (As long the number of council members doesn't drop below a certain number, let's say 5. I think we need odd no. of members to have a casting vote. Btw. I vote for #3. -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
For what its worth, I think option #2 is the best. I think option #1 is out of the question and I think that #3 is flawed because the 8th spot developer's situation or commitment to the project may have changed since the last vote and in any case that developer would be free to partake in the running vote with #2. Cheers -Rob On 29/01/07, Wernfried Haas [EMAIL PROTECTED] wrote: On Sun, Jan 28, 2007 at 02:24:49PM -0800, Mike Doty wrote: 1. re-elect a whole new council. Seems to be overkill to me. 2. elect a new member at a reduced term to fill the vacancy. Personally i'd rather go with #3, but the GLEP also states: If a council member who has been marked a slacker misses any further meeting (or their appointed proxy doesn't show up), they lose their position and a new election is held to replace that person. The newly elected council member gets a 'reduced' term so that the yearly elections still elect a full group. Seems to be the closest case to a member simply resigning with the slacker regulation. 3. take the 8th spot from the last election. Seems to be the best - and least complicated - version to me. 4. The position stays empty until the next election (As long the number of council members doesn't drop below a certain number, let's say 5. Just adding this as it may be an option, too. The spirit of the GLEP would indicate option 2, but it's never spelled out. Speak out now if you have a opinion on the subject. Agreed, personally i'd go with #2. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- /** * Gentoo Forensics Team * GPG : 0x2217D168 */
Re: [gentoo-dev] Topic for Feb council meeting
On Mon, 29 Jan 2007 13:39:05 +0100 Rob C [EMAIL PROTECTED] wrote: For what its worth, I think option #2 is the best. I think option #1 is out of the question and I think that #3 is flawed because the 8th spot developer's situation or commitment to the project may have changed since the last vote and in any case that developer would be free to partake in the running vote with #2. Cheers -Rob Then it should be offered to the 8th person, at which point either he/she will then refuse the nomination and it's offered to the 9th. Rinse and repeat. If we run out of nominees then we'll need another election. Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
On Sun, 28 Jan 2007 18:03:49 +0100
Christian Heim [EMAIL PROTECTED] wrote:
On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote:
Raúl Porcel wrote:
# Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007)
# Masked for removal 26 Feb 2007, bug 135257, security issues
# Replaced by www-client/seamonkey[-bin]
www-client/mozilla
www-client/mozilla-bin
How about not breaking the tree?
!!! All ebuilds that could satisfy www-client/mozilla have been
masked. !!! One of the following masked packages is required to
complete your request:
- www-client/mozilla-1.7.13 (masked by: package.mask)
What about the rest of the portage error ? At least it could be used,
to fix (well sort of) it :)
I think he just has www-client/mozilla in his world file. From what
I see, nothing in tree still depends on www-client/mozilla{,-bin}.
There's just a block against it by www-client/seamonkey.
--
Mike Kelly
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
On Mon, 2007-01-29 at 14:46 +, Roy Marples wrote: On Mon, 29 Jan 2007 13:39:05 +0100 Rob C [EMAIL PROTECTED] wrote: For what its worth, I think option #2 is the best. I think option #1 is out of the question and I think that #3 is flawed because the 8th spot developer's situation or commitment to the project may have changed since the last vote and in any case that developer would be free to partake in the running vote with #2. Cheers -Rob Then it should be offered to the 8th person, at which point either he/she will then refuse the nomination and it's offered to the 9th. Rinse and repeat. If we run out of nominees then we'll need another election. Agreed. #3 From my POV having a new election potentially over and over is a waste of time and resources. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
Mike Kelly wrote:
On Sun, 28 Jan 2007 18:03:49 +0100
Christian Heim [EMAIL PROTECTED] wrote:
On Saturday, 27. January. 2007 13:22:56 Petteri Räty wrote:
Raúl Porcel wrote:
# Raúl Porcel [EMAIL PROTECTED] (27 Jan 2007)
# Masked for removal 26 Feb 2007, bug 135257, security issues
# Replaced by www-client/seamonkey[-bin]
www-client/mozilla
www-client/mozilla-bin
How about not breaking the tree?
!!! All ebuilds that could satisfy www-client/mozilla have been
masked. !!! One of the following masked packages is required to
complete your request:
- www-client/mozilla-1.7.13 (masked by: package.mask)
What about the rest of the portage error ? At least it could be used,
to fix (well sort of) it :)
I think he just has www-client/mozilla in his world file. From what
I see, nothing in tree still depends on www-client/mozilla{,-bin}.
There's just a block against it by www-client/seamonkey.
No. I used reverse dependencies scanning tools to find that and posted
that as a mail. The issue was since resolved because I pointed it out.
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: www-client/mozilla[-bin]
Delayed until we fix some depends on it. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: DB vs SCM (was Re: [RFC] Some sync control)
Donnie Berkholz wrote: The idea of restricting access to specific parts of gentoo-x86 has come up many times. It doesn't fix anything and actually makes some things worse. Committers still have access to wherever they can commit, so they can work whatever evil they want there without needing the rest of the tree. If we trust people to commit anywhere, we should trust them to commit everywhere. If we don't trust them to commit, why do they have commit access? This implies a basic lack of trust within our development team, which means it can never be a true team. Makes sense. I was just under the impression that devs were snowed under, and that the team is understandably wary of giving commit access to the whole tree. It's not about trust as much as human error, and I thought it made sense to limit people's scope for error. No biggy, just wondered at the model, especially in terms of bringing new people in as ebuild devs. But as you imply, much damage can be done in a single ebuild since it runs as root. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: DB vs SCM (was Re: [RFC] Some sync control)
Marius Mauch wrote: I'm a bit confused about all the portage tree stuff. There's just under 25,000 ebuilds, which are maintained by about 100 devs (not sure of exact number, taken from a forum post.) I guess what I'm asking is why this isn't just a database. Please define database. OK, I accept that the existing setup can be called a database. As I'm sure you guessed, I meant a database application in the sense of a standard RDMBS, with finer grained control over permissions (ie per cp for new devs, per category or whole tree access for more experienced.) If it's a bad idea, no probs. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: DB vs SCM (was Re: [RFC] Some sync control)
Petteri Räty wrote: Please note, I'm not talking about applications like portage or pkgcore, just the ebuild text files, which I understand have one maintainer? Many ebuilds are in maintained by a bunch of people via herds. That's not really an issue for a db app. I appreciate that source control is needed to maintain files over a period of time and to roll back changes. Does that happen with ebuilds? Rolling back changes does not happen that often but a history is useful. Sure, that's why I mentioned having a svn backend if an archive table is not considered acceptable. I'm thinking in any case that a db app can save old revisions or use a svn backend. I'm looking at this from a workflow perspective, in terms especially of the security issue around giving commit access to the whole tree. If the individual maintainer only has permission for those ebuilds s/he is responsible for, it might make it easier to allow new people write access. I fail to see any benefit from a layer above svn. svn has good access control if we want use that built in. So? Fair enough then. Sorry if this has all been discussed before. Most likely the access control has been discusses some times before. To summarize having access to everything is quite useful. I can understand that; I'm not convinced that giving every dev access to the whole thing is necessary or desirable, but it may well be how gentoo likes to operate, and i have no quarrel with that. (Please note: I'm not discussing the mechanisms by which software might be installed for the end-user, rather the back-end which you devs use, of which I admittedly have no experience.) So please let people who actually use/know how source control work discuss the issue. Um, I do understand source control and have used it for other stuff. It just doesn't seem an ideal fit for this purpose. This really was motivated by a desire to lessen the workload for existing devs, but clearly it doesn't fit with the way gentoo works. No probs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
Ned Ludd wrote: [Mon Jan 29 2007, 09:50:28AM CST] Then it should be offered to the 8th person, at which point either he/she will then refuse the nomination and it's offered to the 9th. Rinse and repeat. If we run out of nominees then we'll need another election. Agreed. #3 From my POV having a new election potentially over and over is a waste of time and resources. My only qualm with this approach is whether or not we then risk promoting a candidate who was resoundingly defeated during the actual election to a Council position because only a handful of people ran for the position. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgphDsgw6xilV.pgp Description: PGP signature
Re: [gentoo-dev] Topic for Feb council meeting
On Mon, 2007-29-01 at 14:01 -0600, Grant Goodyear wrote: Ned Ludd wrote: [Mon Jan 29 2007, 09:50:28AM CST] Then it should be offered to the 8th person, at which point either he/she will then refuse the nomination and it's offered to the 9th. Rinse and repeat. If we run out of nominees then we'll need another election. Agreed. #3 From my POV having a new election potentially over and over is a waste of time and resources. My only qualm with this approach is whether or not we then risk promoting a candidate who was resoundingly defeated during the actual election to a Council position because only a handful of people ran for the position. Don't we have a re-open nominations item in our electoral process? If so, we can decide to consider only candidates who are above that threshold. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] tr1 dependencies
[ Background: tr1 is a set of extensions to the C++ Standard Library giving various useful things like hash tables and smart pointers. There are partial implementations included in g++-4.1 and boost and full implementations available from Dinkumware. It is likely that a lot of C++ apps will start using it in the not too distant future. ] What is the best way to handle packages that require parts of tr1? The options appear to be: * Hard dep upon boost. This sucks for g++-4.1 users. * Hard dep upon g++-4.1, which isn't available for all archs. This doesn't even work because there's no guarantee that =4.1 is being used even if it's installed. * || ( ) deps, and hope that if the user has 4.1 installed then they're using it. Since library implementations aren't runtime switchable, this will lead to breakages if users upgrade gcc and then remove boost. None of these are particularly nice... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: What is the best way to handle packages that require parts of tr1? The options appear to be: * have the application bundle a static implementation and switch to system on at configure time as done for other libs? lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tr1 dependencies
On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | What is the best way to handle packages that require parts of tr1? | The options appear to be: | | | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] tr1 dependencies
Ciaran McCreesh wrote: On Tue, 30 Jan 2007 08:30:40 +0100 Luca Barbato [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | What is the best way to handle packages that require parts of tr1? | The options appear to be: | | | * have the application bundle a static implementation and switch to | system on at configure time as done for other libs? At something like five megs of code per application? fine by me. (5mb if you use everything, less if you use just certain bits I hope) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
