Re: [gentoo-dev] Status of sparc-fbsd, amd64-fbsd
On 01/28/2011 09:31 AM, Torsten Veller wrote: Arch teams handle KEYWORDREQ bugs too. I have masked the only dev-lang/perl version keyworded for sparc-fbsd 3 weeks ago. No user, no dev complained by now (#288028). So I think this arch (as much as amd64-fbsd) is unsupported/dead but repoman's dependencies check reports a lot of warnings due to the dev status of their profiles. Do we want to: - move sparc-fbsd-profiles to exp or kill it? I tried to remove ~sparc-fbsd like year ago, when there was nobody to keyword dev-lang/python requirement dev-libs/libffi and... There is at least one user out there, with a remote server using it. That same user gave me and aballier access to it. Unfortunately, since then, I've lost my logins and don't know if the server is still up. So I think your own chance is to contact aballier, ask if he still has access (or ask for renewed opinion for the killing)
Re: [gentoo-dev] Private SVN repository for live-ebuild
On 11:55 Thu 27 Jan , Zac Medico wrote: On 01/27/2011 11:08 AM, Matthew Summers wrote: One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special? Well, I've never tried it, so I don't have any recommendation atm other than to make sure FEATURES=userpriv is not enabled. Moving forward, maybe it would make sense to have a notion of a configurable fetcher home that package managers and live/vcs eclasses would use for the HOME variable only when fetching. For example, the user could configure this by setting a FETCHER_HOME variable. This might be useful in other scenarios besides fetching that just haven't occurred to us yet. Perhaps we should treat the portage user as a regular user with a regular home directory that can be configured as desired, and flip in and out of that user on demand. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpw94VbQQOSR.pgp Description: PGP signature
Re: [gentoo-dev] Private SVN repository for live-ebuild
On Friday 28 of January 2011 15:26:27 Donnie Berkholz wrote: On 11:55 Thu 27 Jan , Zac Medico wrote: On 01/27/2011 11:08 AM, Matthew Summers wrote: One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special? Well, I've never tried it, so I don't have any recommendation atm other than to make sure FEATURES=userpriv is not enabled. Moving forward, maybe it would make sense to have a notion of a configurable fetcher home that package managers and live/vcs eclasses would use for the HOME variable only when fetching. For example, the user could configure this by setting a FETCHER_HOME variable. This might be useful in other scenarios besides fetching that just haven't occurred to us yet. Perhaps we should treat the portage user as a regular user with a regular home directory that can be configured as desired, and flip in and out of that user on demand. Having SCM distfiles in user directory is not new 'market demand'. Below there's subversion eclass enhancement request I opened some time ago which I used to work around so far by denying emerge write access to distfiles. https://bugs.gentoo.org/show_bug.cgi?id=277976 -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Private SVN repository for live-ebuild
On 01/28/2011 06:26 AM, Donnie Berkholz wrote: On 11:55 Thu 27 Jan , Zac Medico wrote: On 01/27/2011 11:08 AM, Matthew Summers wrote: One question though. Since the 'portage' user has its $home set by default to /var/tmp/portage how would you recommend handling the ssh key situation since that directory is somewhat special? Well, I've never tried it, so I don't have any recommendation atm other than to make sure FEATURES=userpriv is not enabled. Moving forward, maybe it would make sense to have a notion of a configurable fetcher home that package managers and live/vcs eclasses would use for the HOME variable only when fetching. For example, the user could configure this by setting a FETCHER_HOME variable. This might be useful in other scenarios besides fetching that just haven't occurred to us yet. Perhaps we should treat the portage user as a regular user with a regular home directory that can be configured as desired, and flip in and out of that user on demand. Well, the problem that I see with having a common $HOME for execution of _all_ ebuilds is that it will be likely to accumulate all sorts of junk from the various programs that are executed by ebuilds, and this can lead to all sorts of bugs that may or may not be reproducible based on the state of this directory on a given user's system. Currently, portage always sets $HOME to a private temporary directory which is a sibling of other private temporary directories such as $WORKDIR, $T, and $D. This has the advantage of providing a clean slate for each ebuild, ensuring reproducible results and no accumulation of junk. This is why I suggested that we used a separate $HOME that is only for fetching purposes, in order to minimize the risk of junk accumulation and resulting problems with reproducibility. -- Thanks, Zac
[gentoo-dev] Glep 48 update (as nominated for next meeting)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, first off i would like to apologize for not sending this mail sooner (helluva week). So draft we would like to have implemented as Glep update is this diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff Please comment and help us improve the english of the whole document so it gets accepted :) Cheers Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DMQIACgkQHB6c3gNBRYdXPgCgu0/rITuXTPLkngR/CMVVjXs3 hx0AnAxONMKBw1fRR27V1RdA5Hx/rk4/ =xSmN -END PGP SIGNATURE-
[gentoo-dev] FYI: Moving packages from dev-php5 to dev-php
Hi all, this is a quick note that the php team (well, Ole and me) has decided to kill of the dev-php5 category. We think it's confusing and the distinction of which packages go where isn't as clear as it should be. I find myself regularly looking in dev-php instead of dev-php5. As php extensions (which should be in dev-php5 now) may now break on minor versions changes of php, the dev-php5 name is not as appropiate as it was with php4 still around. So we're going to remove it. This will not be an overnight change. We intend to move packages from dev-php5 to dev-php starting this weekend (29./30.1.) and be finished sometime next month. Packages pending a revision or version bump will go first. You can post all issues (if any) to our tracker bug #324665. Any advice and feedback welcome. EOM signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)
2011/1/28 Tomáš Chvátal scarab...@gentoo.org: So draft we would like to have implemented as Glep update is this diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff Please comment and help us improve the english of the whole document so it gets accepted :) My only general comments are: 1. It makes sense that in the event that a Rogue developer is wreaking havoc on the tree that QA can get infra to suspend their commit rights. That's safeguarding the tree in the face of imminent harm. This should generally be limited to serious issues (people running scripts to mass-update packages, bad changes to system packages, etc), and not because there is some dispute over whether some obscure package should or should-not be masked. 2. I don't think it makes sense for QA to discipline developers permanently in these cases. They should suspend access pending Devrel resolution of the issue. Devrel should of course strongly consider the input of QA. If Devrel is not adequately doing its job then this should be escalated to the Devrel lead, or if necessary to the council (who can step in if truly necessary). In the face of imminent harm QA can always get a temporary ban on commits from infra. If this goes back and forth (QA banning, Devrel unbanning) then I'm sure the council will step in. So, in a nutshell here is how it works: 1. Developer starts messing something up (some crazy script is committing junk to the tree, or dev is making some change to critical package, or whatever). 2. QA notices, or is told, or whatever. 3. QA tries to ping dev - with severity of problem dictating how long they should wait to resolve directly. 4. QA determines that dev is unwilling to resolve a critical issue, or cannot be reached and the matter can't wait. 5. QA contacts infra, and infra suspends commit access to contain the damage. 6a. QA initiates repairs (whatever this takes - they don't need to personally do the work, etc). 6b. QA logs complaint with DevRel. 7. Devrel follows their process to resolve issue. Developer remains banned until Devrel feels they can be unbanned, or dismissed. Devrel takes input from QA. If the issue here is that the Devrel and QA leads differ as to some matter of policy or whatever, the council should be asked to resolve. While the QA and Devrel teams may tend to self-govern, I don't think the intent is that we end up having three Gentoos - the one ruled by Devrel, the one ruled by QA, and the one ruled by the Council (not to mention the Trustees). In practice I haven't really seen any situations where we're really having problems over this, so I don't want to start a war over something that isn't even a problem. In any case, the solution for developers is simple: 1. Don't do stupid stuff to the tree such that you tick EVERYBODY off. 2. If you want to do something to the tree that you think is right but which might tick a lot of people off (whether they are QA or not), post notice of it in -dev first. 3. If you and QA can't work it out before you do it, then work it out with the council or something. 4. Generally act like an adult. :) Ok, that was probably overly verbose. I don't see any issues with the wording in the diff - this is more a matter of which is the right policy. Finally, if Devrel, QA, and the Council have already talked this out and agree that QA is in the best place to police technical commit issues, then pipe this email to /dev/null... Rich
Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 28.1.2011 23:42, Rich Freeman napsal(a): 2011/1/28 Tomáš Chvátal scarab...@gentoo.org: So draft we would like to have implemented as Glep update is this diff: http://dev.gentoo.org/~scarabeus/glep-0048.diff Please comment and help us improve the english of the whole document so it gets accepted :) My only general comments are: Wow what a nice and long reply, thanks :) 1. It makes sense that in the event that a Rogue developer is wreaking havoc on the tree that QA can get infra to suspend their commit rights. That's safeguarding the tree in the face of imminent harm. This should generally be limited to serious issues (people running scripts to mass-update packages, bad changes to system packages, etc), and not because there is some dispute over whether some obscure package should or should-not be masked. 2. I don't think it makes sense for QA to discipline developers permanently in these cases. They should suspend access pending Devrel resolution of the issue. Devrel should of course strongly consider the input of QA. QA is not to discipline any developers. Everyone of us can cause breakage, heck even i killed profiles once :) Only case where we don't want Devrel interfere with QA decision at all is when someone Intentionaly breaks main tree. Seriously if someone really hit this issue i don't actually want him to apologize to another team and pretend like it never happened, i would prefer him long gone in a place far far away :) We really just want keep control over removing access for people that does breakage to main tree just for the breakage itself, aka it can't be excused in any way. Lets say you have this change for eclass which affects large part of the tree and on -dev ml people including QA members told you not to do so, yet you still proceed with the commit thus breaking part of the main tree in effect. In this situation normal accidental breakage or uneducated commit can't count in cause you were told of that it is not the way you should do it. So only way it can be described is deliberate act of main tree destruction. Since QA team is responsible for overall quality of main tree it is obvious we as team can't trust such person while he (or she) does not listen to us. So we would like to be the ones who decide that they should not be permitted to do direct commits to main tree. (they for sure can stay developers and write documentation and help in other areas they want to) If Devrel is not adequately doing its job then this should be escalated to the Devrel lead, or if necessary to the council (who can step in if truly necessary). In the face of imminent harm QA can always get a temporary ban on commits from infra. If this goes back and forth (QA banning, Devrel unbanning) then I'm sure the council will step in. So, in a nutshell here is how it works: 1. Developer starts messing something up (some crazy script is committing junk to the tree, or dev is making some change to critical package, or whatever). 2. QA notices, or is told, or whatever. 3. QA tries to ping dev - with severity of problem dictating how long they should wait to resolve directly. 4. QA determines that dev is unwilling to resolve a critical issue, or cannot be reached and the matter can't wait. 5. QA contacts infra, and infra suspends commit access to contain the damage. 6a. QA initiates repairs (whatever this takes - they don't need to personally do the work, etc). 6b. QA logs complaint with DevRel. 7. Devrel follows their process to resolve issue. Developer remains banned until Devrel feels they can be unbanned, or dismissed. Devrel takes input from QA. You actually pretty well described how we work when somebody breaks main tree without its primary intention to nuke it off. Which is still in effect with this update :) (everyone can make typo or forget to ask about something and accidentally do something disasterous :P) +* In case a particular developer persistently causes breakage, the QA + lead may request commit rights of given developer to be suspended by + the Infra team. Devrel should then proceed to evaluate the situation, by + finding a compromise or permanently revoking those rights. If the issue here is that the Devrel and QA leads differ as to some matter of policy or whatever, the council should be asked to resolve. While the QA and Devrel teams may tend to self-govern, I don't think the intent is that we end up having three Gentoos - the one ruled by Devrel, the one ruled by QA, and the one ruled by the Council (not to mention the Trustees). In practice I haven't really seen any situations where we're really having problems over this, so I don't want to start a war over something that isn't even a problem. In any case, the solution for developers is simple: 1. Don't do stupid stuff to the tree such that you tick EVERYBODY off. 2. If you want to do something to
Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)
On 2011.01.28 23:03, Tomáš Chvátal wrote: [snip] Only case where we don't want Devrel interfere with QA decision at all is when someone Intentionaly breaks main tree. Seriously if someone really hit this issue i don't actually want him to apologize to another team and pretend like it never happened, i would prefer him long gone in a place far far away :) We really just want keep control over removing access for people that does breakage to main tree just for the breakage itself, aka it can't be excused in any way. [snip] Its not QAs decision, if the breakage was intentional or not. A single body, in this case, QA, cannot be both the police and the judicary. QA can and should be capable of finding wrongs, preventing further damage and causing the problem to get fixed. Thats damage limitaion. If preventing further damage involves revoking commit rights pending full investigation, thats fine by me. Determining the root cause, and determining long term prevention takes some investigation. QA may present evidence but its Devrels job to weigh the evidence and pass sentence. Tom -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgpFLUpGEZkmr.pgp Description: PGP signature
Re: [gentoo-dev] Glep 48 update (as nominated for next meeting)
On Sat, 29 Jan 2011 00:05:48 + Roy Bamford neddyseag...@gentoo.org wrote: Its not QAs decision, if the breakage was intentional or not. A single body, in this case, QA, cannot be both the police and the judicary. QA can and should be capable of finding wrongs, preventing further damage and causing the problem to get fixed. Thats damage limitaion. If preventing further damage involves revoking commit rights pending full investigation, thats fine by me. Determining the root cause, and determining long term prevention takes some investigation. QA may present evidence but its Devrels job to weigh the evidence and pass sentence. Thank you for that. What in the recent past has perspired is that QA has its place, after the fact, and that whoever feels to be in place to deal out QA (and I think this has gone wrong a few times recently) is required to: 1) state and/or explain policy specifically where it is being not adhered to; 2) offer alternatives where policy is not adhered to. There should be no way that someone in the QA team could be above any /other/ developer. Anyone who is a developer is one, and anyone in the QA team still has the same hierarchical place. If there are QA issues, then logical and technical arguing should suffice - not some perceived hierarchy derived from being in some team. Thank you. jer
