Mailing List Archive

implementation details for GLEP 41
Ignoring the yellow star issue, there are a few implementation
concerns/impossibilities with GLEP 41 in its current form.

For instance, the way GLEP 41 suggests doing r/o cvs is not going to work.
It suggests using a single account and placing an SSH key for each arch
tester in that account's ~/.ssh/authorized_keys file.

There are no provisions for key management and I cannot see an easy way to
handle it. It's easy to add new keys, but how do we clean out old keys for
retired arch testers? (including arch testers that "retire" without ever
informing us) SSH doesn't log key ID as near as I can tell, so we have no
way of tracking what keys are used and how often. Also, how do we
definitively correlate an SSH key with an arch tester?

Now, the same question for email -- how do we manage aliases, especially
for inactive, retired and semi-retired arch testers? We could track usage
in logs, but between mailing list subscriptions, bugzilla notifications and
all sorts of other automated emails, that's not an accurate representation
of whether an email alias is actively used or not.

I talked to Lance and neither he nor I were consulted about this GLEP and
how feasible the implementation is. We both are quite concerned about the
issues that I've outlined above as well as others.

This isn't a "we're refusing to implement this GLEP" email, btw, though I'm
sure some of you will take it as such. It is, however, a "we were never
consulted regarding implementation details, so there are still issues that
need to be worked out before this GLEP can go anywhere" email.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kurt Lieber schrieb:
| Ignoring the yellow star issue, there are a few implementation
| concerns/impossibilities with GLEP 41 in its current form.
|
| For instance, the way GLEP 41 suggests doing r/o cvs is not going to work.
| It suggests using a single account and placing an SSH key for each arch
| tester in that account's ~/.ssh/authorized_keys file.
|
| There are no provisions for key management and I cannot see an easy way to
| handle it. It's easy to add new keys, but how do we clean out old
keys for
| retired arch testers? (including arch testers that "retire" without ever
| informing us) SSH doesn't log key ID as near as I can tell, so we have no
| way of tracking what keys are used and how often. Also, how do we
| definitively correlate an SSH key with an arch tester?
Do we have to? Nobody has to track how often an Arch Tester uses RO
access to CVS, as you don't need that information. RO CVS access is a
service to the ATs. Their work is pretty much outside CVS...

| Now, the same question for email -- how do we manage aliases, especially
| for inactive, retired and semi-retired arch testers? We could track usage
| in logs, but between mailing list subscriptions, bugzilla
notifications and
| all sorts of other automated emails, that's not an accurate representation
| of whether an email alias is actively used or not.
Afaik the gentoo.org address is only a forward to their normal adress,
so one can hardly speak 'active usage'. You simply can't actively use
it! On the other hand, tracking down how active/inactive a AT/HT is
falls under the project the AT/HT is associated with, or the AT/HT
Project (hparker) as last resort. So if he says 'AT foo is inactive',
he's to be removed from email forwarding and CVS RO Access. I really
don't see the problem here.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDf2eVaVNL8NrtU6IRAoyTAJ0ey3mRDulIHz2KMtZjCM0zWEOKWwCffHsx
pcnKGFfZ9OoXBRV2RhKKAOU=
=vTjI
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 06:57:41PM +0100 or thereabouts, Danny van Dyk wrote:
> | There are no provisions for key management and I cannot see an easy way to
> | handle it. It's easy to add new keys, but how do we clean out old keys for
> | retired arch testers? (including arch testers that "retire" without ever
> | informing us) SSH doesn't log key ID as near as I can tell, so we have no
> | way of tracking what keys are used and how often. Also, how do we
> | definitively correlate an SSH key with an arch tester?
>
> Do we have to? Nobody has to track how often an Arch Tester uses RO
> access to CVS, as you don't need that information. RO CVS access is a
> service to the ATs. Their work is pretty much outside CVS...

Yes, we have to. If someone retires, their access needs to be revoked.

> | Now, the same question for email -- how do we manage aliases, especially
> | for inactive, retired and semi-retired arch testers? We could track usage
> | in logs, but between mailing list subscriptions, bugzilla
> notifications and
> | all sorts of other automated emails, that's not an accurate representation
> | of whether an email alias is actively used or not.
> Afaik the gentoo.org address is only a forward to their normal adress,
> so one can hardly speak 'active usage'. You simply can't actively use
> it! On the other hand, tracking down how active/inactive a AT/HT is
> falls under the project the AT/HT is associated with, or the AT/HT
> Project (hparker) as last resort. So if he says 'AT foo is inactive',
> he's to be removed from email forwarding and CVS RO Access. I really
> don't see the problem here.

Because, in practice, this doesn't happen. Accounts (or, in this case,
email addresses) stay around until someone gets enough of a bee under their
bonnet to do somethig about it. Since there's no pain or cost for the
AT/HT project lead, there's no reason for them to be vigilant about
tracking activity. Plus, assuming we have a large number of these testers,
how are people going to know whether or not one specific arch tester is
active? That's not an acceptable solution.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
Kurt Lieber wrote:
> Because, in practice, this doesn't happen. Accounts (or, in this case,
> email addresses) stay around until someone gets enough of a bee under their
> bonnet to do somethig about it. Since there's no pain or cost for the
> AT/HT project lead, there's no reason for them to be vigilant about
> tracking activity. Plus, assuming we have a large number of these testers,
> how are people going to know whether or not one specific arch tester is
> active? That's not an acceptable solution.

Uhm, does that implicitly mean there is such a tracking method for devs (where
dev = dev/staff/whatever)? There are devs who don't have commit permissions to
any cvs repo, how is their activity tracked?

In the AT case it wouldn't be so hard to check their activity. !seen on IRC and
a bugzilla query printing out bugs where they made a comment should be enough, IMHO.

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 05:06:15PM +0000, Kurt Lieber wrote:
> For instance, the way GLEP 41 suggests doing r/o cvs is not going to work.
> It suggests using a single account and placing an SSH key for each arch
> tester in that account's ~/.ssh/authorized_keys file.
text in question

"Get read-only access to the gentoo-x86 repository. This doesn't have
to be individual accounts, a single account, without a shell, with all
of their keys will be sufficiant."

Note the "doesn't have to be" and "will be sufficient", it's left open
to how y'all want to implement it.

> There are no provisions for key management and I cannot see an easy way to
> handle it. It's easy to add new keys, but how do we clean out old keys for
> retired arch testers? (including arch testers that "retire" without ever
> informing us) SSH doesn't log key ID as near as I can tell, so we have no
> way of tracking what keys are used and how often. Also, how do we
> definitively correlate an SSH key with an arch tester?
>
> Now, the same question for email -- how do we manage aliases, especially
> for inactive, retired and semi-retired arch testers? We could track usage
> in logs, but between mailing list subscriptions, bugzilla notifications and
> all sorts of other automated emails, that's not an accurate representation
> of whether an email alias is actively used or not.
>
> I talked to Lance and neither he nor I were consulted about this GLEP and
> how feasible the implementation is. We both are quite concerned about the
> issues that I've outlined above as well as others.
>
> This isn't a "we're refusing to implement this GLEP" email, btw, though I'm
> sure some of you will take it as such. It is, however, a "we were never
> consulted regarding implementation details, so there are still issues that
> need to be worked out before this GLEP can go anywhere" email.

Cvs concerns above are all based upon doing single account for cvs ro;
again, it's stated as an option (iow, the option is left up to y'all).

It's not mandating anything on you for cvs, reread it if you don't
believe me. It's stating the base, that they only need the users to
have cvs ro access...

Either way, it's word games, and yes, it's kind of retarded.
~harring
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 05:06:15PM +0000, Kurt Lieber wrote:
> Now, the same question for email -- how do we manage aliases, especially
> for inactive, retired and semi-retired arch testers? We could track usage
> in logs, but between mailing list subscriptions, bugzilla notifications and
> all sorts of other automated emails, that's not an accurate representation
> of whether an email alias is actively used or not.

Isn't this an issue that also exists for the Gentoo developers in general?

Wkr,
Sven Vermeulen


--
Gentoo Foundation Trustee | http://foundation.gentoo.org
Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp
Gentoo Council Member

The Gentoo Project <<< http://www.gentoo.org >>>
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 08:03:55PM +0100 or thereabouts, Sven Vermeulen wrote:
> On Sat, Nov 19, 2005 at 05:06:15PM +0000, Kurt Lieber wrote:
> > Now, the same question for email -- how do we manage aliases, especially
> > for inactive, retired and semi-retired arch testers? We could track usage
> > in logs, but between mailing list subscriptions, bugzilla notifications and
> > all sorts of other automated emails, that's not an accurate representation
> > of whether an email alias is actively used or not.
>
> Isn't this an issue that also exists for the Gentoo developers in general?

Not as much since we can track things like last cvs commit, last login to
toucan, etc. But it does exist to some extent.

That does not, however, make it acceptable to further exacerbate the
problem. We're working towards improving the procedures and controls we
have in place today. We're not going to implement something that will move
us backwards.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 07:14:03PM +0000, Kurt Lieber wrote:
> On Sat, Nov 19, 2005 at 08:03:55PM +0100 or thereabouts, Sven Vermeulen wrote:
> > Isn't this an issue that also exists for the Gentoo developers in general?
>
> Not as much since we can track things like last cvs commit, last login to
> toucan, etc. But it does exist to some extent.
>
> That does not, however, make it acceptable to further exacerbate the
> problem. We're working towards improving the procedures and controls we
> have in place today. We're not going to implement something that will move
> us backwards.

I'll again point out that the glep doesn't actually mandate it, states
it's the lowest common denominator that's acceptable.

Stop pointing at one interpretation of it that sucks, when the glep
_does_ leave it open to you how to implement it. It's a waste of
people's time and bandwidth, and is a bit disenguous.
~harring
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 01:51:15PM -0600 or thereabouts, Brian Harring wrote:
> I'll again point out that the glep doesn't actually mandate it, states
> it's the lowest common denominator that's acceptable.

And I'll point out that there's more than one issue that we're concerned
with here.

> Stop pointing at one interpretation of it that sucks, when the glep
> _does_ leave it open to you how to implement it. It's a waste of
> people's time and bandwidth, and is a bit disenguous.

I'm trying to find a solution to the issues as I see them. Telling me I'm
wasting people's time and bandwidth doesn't seem conducive to working
together towards a resolution to this all. If you're going to say, "it was
passed, you guys just have to find a way to implement it. now please stop
bothering us" then I'm going to come up with an implementation plan that
looks something like the following:

* all SSH keys and email addresses for arch testers will auto-expire after
60 days. If an arch tester needs to have continued access, a gentoo dev
will have to re-submit the key and recreate the alias for that arch
tester every 60 days.

That meets the requirements of the GLEP down to the letter and also
satisfies infra concerns around key management. However, it's a crappy
solution.

So, I'd much rather work together towards finding a better one.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 22:03 +0000, Kurt Lieber wrote:
> I'm going to come up with an implementation plan that
> looks something like the following:
>
> * all SSH keys and email addresses for arch testers will auto-expire after
> 60 days. If an arch tester needs to have continued access, a gentoo dev
> will have to re-submit the key and recreate the alias for that arch
> tester every 60 days.

Just a thought, auto-expire after 60 days of non-use. That only applies
to ro CVS access, but perhaps a resonable implimentation.

Email is a different issue, which I do not have a 'firm' opinion on.

--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 10:03:58PM +0000, Kurt Lieber wrote:
> On Sat, Nov 19, 2005 at 01:51:15PM -0600 or thereabouts, Brian Harring wrote:
> > Stop pointing at one interpretation of it that sucks, when the glep
> > _does_ leave it open to you how to implement it. It's a waste of
> > people's time and bandwidth, and is a bit disenguous.
>
> I'm trying to find a solution to the issues as I see them. Telling me I'm
> wasting people's time and bandwidth doesn't seem conducive to working
> together towards a resolution to this all. If you're going to say, "it was
> passed, you guys just have to find a way to implement it. now please stop
> bothering us" then I'm going to come up with an implementation plan that
> looks something like the following:
>
> * all SSH keys and email addresses for arch testers will auto-expire after
> 60 days. If an arch tester needs to have continued access, a gentoo dev
> will have to re-submit the key and recreate the alias for that arch
> tester every 60 days.
>
> That meets the requirements of the GLEP down to the letter and also
> satisfies infra concerns around key management. However, it's a crappy
> solution.
>
> So, I'd much rather work together towards finding a better one.

Simple solution, that I've repeatedly pointed at. Use the existing
ldap setup. It's not infra's responsibility to add their accounts nor
disable them (that is left in the air as stated, although I'd expect
it'll fall on devrels head). Infra doesn't even do retirement beyond
when _devrel_ asks them to. If that process is slow, ask for help and
someone will chip in and improve it (mainly to minimize bottleneck
involved).

A simple script handling a pull from ldap sshPubKey attribute
updating $USER/.ssh/authorized_keys on lark, you've got the cvs ro
issue licked. Doesn't require anything crazy/new, and could be
implemented in no time- no infra overhead beyond an initial setup cost
for cvs, which I would be willing to implement myself.

It's minor to do it within existing framework, which is why I've
stated it's daft pointing at the minimal requirement as admin hell.
~harring
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote:
> For instance, the way GLEP 41 suggests doing r/o cvs is not going to work.

So, in the interests of trying to find a solution to this particular
problem...

As I understand the GLEP, the main requirement here is to give the arch
testers faster access to the ebuilds in CVS. Is this accurate?

If so, is there any reason we have to use CVS? Lance and I are both
concerned about the extra load that another 50-100 people (extrapolating
from the 20 folks that amd64 says they have currently) will place on
cvs.g.o and I'd rather break this out onto a separate server.

One proposal being discussed is setting up a dedicated rsync server for
this purpose that a) syncs from CVS more frequently and b) has no ban
limits imposed on it. Arch testers would have some way of authenticating
to the box and being able to sync as frequently as they wanted to. Current
goal is to have all data in this new repository within 30 minutes of it
hitting CVS. (current average is about 1 hour)

If the requirement is for r/o CVS access to the same CVS server that the
pure-blooded developers use (sorry, couldn't resist) then it may require
upgrades to our existing server and/or purchasing a new server.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
On 11/19/05, Kurt Lieber <klieber@gentoo.org> wrote:
> On Sat, Nov 19, 2005 at 05:06:15PM +0000 or thereabouts, Kurt Lieber wrote:
> > For instance, the way GLEP 41 suggests doing r/o cvs is not going to work.
>
> So, in the interests of trying to find a solution to this particular
> problem...
>
> As I understand the GLEP, the main requirement here is to give the arch
> testers faster access to the ebuilds in CVS. Is this accurate?

This is the main idea behind it I believe.
>
> If so, is there any reason we have to use CVS? Lance and I are both
> concerned about the extra load that another 50-100 people (extrapolating
> from the 20 folks that amd64 says they have currently) will place on
> cvs.g.o and I'd rather break this out onto a separate server.

Funy, I was just pondering that myself... is authenticated rsync
really possible? I was thinking about some sort of on-the-fly access
list updating based on a daemon running on AT's computers, that sent
current IP.. but that sounded kind of messy, I suppose you are better
at figuring this out than I am, though :)

The only downside to this that I can see would be the lack of
history... FEX an upgraded -rX ebuild breaks something, I could test
against previous -rX's in turn to find out exactly which broke it, and
other history like stuff. This may or may not be necessary/helpful,
hard to say without it having happened :)

Thanks for coming back and thinking about the implementation,
reguardless of which way its done.
>
> One proposal being discussed is setting up a dedicated rsync server for
> this purpose that a) syncs from CVS more frequently and b) has no ban
> limits imposed on it. Arch testers would have some way of authenticating
> to the box and being able to sync as frequently as they wanted to. Current
> goal is to have all data in this new repository within 30 minutes of it
> hitting CVS. (current average is about 1 hour)
>
> If the requirement is for r/o CVS access to the same CVS server that the
> pure-blooded developers use (sorry, couldn't resist) then it may require
> upgrades to our existing server and/or purchasing a new server.
>
> --kurt
>
>
>

--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 04:30:53PM -0600 or thereabouts, Brian Harring wrote:
> Infra doesn't even do retirement beyond when _devrel_ asks them to. If
> that process is slow, ask for help and someone will chip in and improve
> it (mainly to minimize bottleneck involved).

OK, fine. Devrel does not have an established track record of retiring
devs who are otherwise inactive. Please fix this. Please also get an
agreement from them that they're going to be willing to take on the
additional load of these arch testers. Then please articulate the process
that will be followed to ensure they're actively tracked and retired
if/when they fall off the map.

Thanks.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 10:47:37PM +0000, Kurt Lieber wrote:
> On Sat, Nov 19, 2005 at 04:30:53PM -0600 or thereabouts, Brian Harring wrote:
> > Infra doesn't even do retirement beyond when _devrel_ asks them to. If
> > that process is slow, ask for help and someone will chip in and improve
> > it (mainly to minimize bottleneck involved).
>
> OK, fine. Devrel does not have an established track record of retiring
> devs who are otherwise inactive. Please fix this. Please also get an
> agreement from them that they're going to be willing to take on the
> additional load of these arch testers. Then please articulate the process
> that will be followed to ensure they're actively tracked and retired
> if/when they fall off the map.

Devrel doesn't have much issues in actually retiring a dev from where
I'm sitting.

The problem is in detection- an infra issue that could be solved by
either allowing normal devrel people to run the detection scripts
themselves (rather then asking infra to do so), or in modifying the
commit hooks so it pushes info into ldap (which we can access).

Again... setup cost (something I'm more then willing to implement).
~harring
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 05:44:41PM -0500 or thereabouts, Dan Meltzer wrote:
> Funy, I was just pondering that myself... is authenticated rsync
> really possible?

Yes, it has its own auth mechanism. We actually use it for some automated
cron jobs that we have.

> The only downside to this that I can see would be the lack of
> history... FEX an upgraded -rX ebuild breaks something, I could test
> against previous -rX's in turn to find out exactly which broke it, and
> other history like stuff. This may or may not be necessary/helpful,
> hard to say without it having happened :)

So, can other arch testers please pitch in with their $.02? If we gave you
rsync instead of CVS, would that be sufficient? Or do you need the
revision history, etc. of CVS?

And, any objections to a ~30 minute delay between CVS<->this solution?

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
On 11/19/05, Kurt Lieber <klieber@gentoo.org> wrote:
> On Sat, Nov 19, 2005 at 05:44:41PM -0500 or thereabouts, Dan Meltzer wrote:
> > Funy, I was just pondering that myself... is authenticated rsync
> > really possible?
>
> Yes, it has its own auth mechanism. We actually use it for some automated
> cron jobs that we have.
>
> > The only downside to this that I can see would be the lack of
> > history... FEX an upgraded -rX ebuild breaks something, I could test
> > against previous -rX's in turn to find out exactly which broke it, and
> > other history like stuff. This may or may not be necessary/helpful,
> > hard to say without it having happened :)
>
> So, can other arch testers please pitch in with their $.02? If we gave you
> rsync instead of CVS, would that be sufficient? Or do you need the
> revision history, etc. of CVS?
>
> And, any objections to a ~30 minute delay between CVS<->this solution?
30 minutes is much better than 24 hours :)
>
> --kurt
>
>
>

--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
Sorry for two mails in a row.. but out of curiosity, instead of using
30 minute rsync, why not 30 minute mirror of cvs? KDE does this fairly
well, they even have it something like every 5 minutes, is there any
reason mirrored cvs is not possible//feasible? is this something svn
has gotten better at?

On 11/19/05, Kurt Lieber <klieber@gentoo.org> wrote:
> On Sat, Nov 19, 2005 at 05:44:41PM -0500 or thereabouts, Dan Meltzer wrote:
> > Funy, I was just pondering that myself... is authenticated rsync
> > really possible?
>
> Yes, it has its own auth mechanism. We actually use it for some automated
> cron jobs that we have.
>
> > The only downside to this that I can see would be the lack of
> > history... FEX an upgraded -rX ebuild breaks something, I could test
> > against previous -rX's in turn to find out exactly which broke it, and
> > other history like stuff. This may or may not be necessary/helpful,
> > hard to say without it having happened :)
>
> So, can other arch testers please pitch in with their $.02? If we gave you
> rsync instead of CVS, would that be sufficient? Or do you need the
> revision history, etc. of CVS?
>
> And, any objections to a ~30 minute delay between CVS<->this solution?
>
> --kurt
>
>
>

--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 22:47 +0000, Kurt Lieber wrote:
> OK, fine. Devrel does not have an established track record of retiring
> devs who are otherwise inactive. Please fix this. Please also get an
> agreement from them that they're going to be willing to take on the
> additional load of these arch testers. Then please articulate the process
> that will be followed to ensure they're actively tracked and retired
> if/when they fall off the map.

I don't know about retiring devs but the AT's should fall under the
jurisdiction of the Head/lead/strategic lead/whatever the dude in charge
of the AT's for a platform calls themselves. For amd64 that is hparker,
dang, blubb, and maybe another one or two developers.

> Thanks.
>
> --kurt
--
Tres Melton
IRC & Gentoo: RiverRat
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 04:52:08PM -0600 or thereabouts, Brian Harring wrote:
> Devrel doesn't have much issues in actually retiring a dev from where
> I'm sitting.

Then I guess we'll disagree on this.

> The problem is in detection- an infra issue that could be solved by
> either allowing normal devrel people to run the detection scripts
> themselves (rather then asking infra to do so)

First I've heard of this request. Has a bug been submitted for it? It's
easy enough to set up some cron jobs to run scripts and email output to an
alias or mailing list.

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
Tres Melton wrote:
> On Sat, 2005-11-19 at 22:47 +0000, Kurt Lieber wrote:
>
>>OK, fine. Devrel does not have an established track record of retiring
>>devs who are otherwise inactive. Please fix this. Please also get an
>>agreement from them that they're going to be willing to take on the
>>additional load of these arch testers. Then please articulate the process
>>that will be followed to ensure they're actively tracked and retired
>>if/when they fall off the map.
>
>
> I don't know about retiring devs but the AT's should fall under the
> jurisdiction of the Head/lead/strategic lead/whatever the dude in charge
> of the AT's for a platform calls themselves. For amd64 that is hparker,
> dang, blubb, and maybe another one or two developers.

I see this as something that devrel would take care of since they
already do this for developers. They already have the tools/access to
the places for such things. Would rather not have another set of folks
with that access.

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, Nov 19, 2005 at 05:59:46PM -0500 or thereabouts, Dan Meltzer wrote:
> Sorry for two mails in a row.. but out of curiosity, instead of using
> 30 minute rsync, why not 30 minute mirror of cvs? KDE does this fairly
> well, they even have it something like every 5 minutes, is there any
> reason mirrored cvs is not possible//feasible? is this something svn
> has gotten better at?

We have a well-established rsync infrastructure in place and rsync has its
own authentication that will support per-user auth (something that we
require) I'm not opposed to using cvs, but unless there's a strong need
for it, I'd rather stick with rsync. (which is why I'm asking here to see
what the need for it is)

--kurt
Re: implementation details for GLEP 41 [ In reply to ]
Lance Albertson wrote:
> I see this as something that devrel would take care of since they
> already do this for developers. They already have the tools/access to
> the places for such things. Would rather not have another set of folks
> with that access.

So do I. Hint: Homer Parker is a devrel member ;)

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
--
gentoo-dev@gentoo.org mailing list
Re: implementation details for GLEP 41 [ In reply to ]
On Sat, 2005-11-19 at 22:56 +0000, Kurt Lieber wrote:
> So, can other arch testers please pitch in with their $.02? If we gave you
> rsync instead of CVS, would that be sufficient? Or do you need the
> revision history, etc. of CVS?
>
> And, any objections to a ~30 minute delay between CVS<->this solution?
>
> --kurt

I personally do not need Revision histories, I can't speak for other
ATs. Rsync with 30min delay is a noted improvement over the standard
rsync policy. Does this also allow us to sync to main rotation mirroes
is that already overstressed? I ask because IIRC it may take ~30min for
all the mirrors to sync up to the 'Latest' revision, therefore the sync
that I do _may_ be up to 60min old (worstcase). so main rotation mirror
access would be nice.

Feasable? I know not.

Later Days
--
Lares Moreau <lares.moreau@gmail.com> | LRU: 400755 http://counter.li.org
Gentoo x86 Arch Tester | ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Prefered
Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E
Re: implementation details for GLEP 41 [ In reply to ]
Lares Moreau wrote:

> I personally do not need Revision histories, I can't speak for other
> ATs. Rsync with 30min delay is a noted improvement over the standard
> rsync policy. Does this also allow us to sync to main rotation mirroes
> is that already overstressed? I ask because IIRC it may take ~30min for
> all the mirrors to sync up to the 'Latest' revision, therefore the sync
> that I do _may_ be up to 60min old (worstcase). so main rotation mirror
> access would be nice.

They aren't overstressed. The delay is just a function of the
implementation we have. Now, to make this work better, we could do a
direct sync again cvs with the --exclude-cvs option. The down side of
this is that it doesn't include any metadata or glsa files. Basically,
any of the regen process we run on the public tree wouldn't be done if
we did the direct rsync. If files are all you need, then this approach
would probably be the best. I can see problems using the current rsync
mirrors because of the lag time.

Reason being, there's going to be at least a 25-55 minute delay from
when a developer commits something and the time it hits a mirror on
rsync.g.o. The flow works as this:

1) CVS is updated/regen'd at :05/:35 on the master box
2) rsync.g.o syncs at :00/:30

So, if I commit something at say :07, users won't see that file until
the next :00 rsync from the mirrors. But, if I committed something at
:01, the user will see it in 29 minutes. If we have a dedicated box that
does a direct sync, we can reduce that time to 30min. Is that needed, or
is the 25-55 minute lag good enough?

--
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key: <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

1 2  View All