1:29 p.m.
One of the things that I'd like to have before doing that is a
CVS ACL implementation that allows us to put ACLS on branches.
The one we use internally allows us to lock down a repository
to certain developers, but I'd really like, for example, to allow
package developers to lock down CVS HEAD on their packages but
still let other developers do work on a branch, and then the
main developer(s) for that package merge the work down to CVS
HEAD when they think it's appropriate.
Anyone interested in working on that?
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:04 p.m.
In message <20031030142945.E8407(a)devserv.devel.redhat.com>, "Michael K.
Johnson
" writes:
One of the things that I'd like to have before doing that is a
CVS ACL implementation that allows us to put ACLS on branches.
The one we use internally allows us to lock down a repository
to certain developers, but I'd really like, for example, to allow
package developers to lock down CVS HEAD on their packages but
still let other developers do work on a branch, and then the
main developer(s) for that package merge the work down to CVS
HEAD when they think it's appropriate.
Anyone interested in working on that?
There's actually a couple projects which
are providing ACLs for CVS.
http://cvsacl.sourceforge.net/
http://cvs-nserver.sourceforge.net/
I don't know which is more mature or whether or not either is working with
the main CVS folks to ensure integration. But they're probably worth looking
into.
Jeff
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
2:17 p.m.
On Thu, 2003-10-30 at 22:04, law(a)redhat.com wrote:
In message <20031030142945.E8407(a)devserv.devel.redhat.com>,
"Michael K. Johnson
" writes:
>One of the things that I'd like to have before doing that is a
>CVS ACL implementation that allows us to put ACLS on branches.
[...]
>
>Anyone interested in working on that?
There's actually a couple projects which are providing ACLs for CVS.
Don't forget /usr/share/cvs/contrib/cvs_acls.
2:27 p.m.
On Thu, Oct 30, 2003 at 10:17:45PM +0200, Ville Skyttä wrote:
Don't forget /usr/share/cvs/contrib/cvs_acls.
That's the version we're using now, internally, FWIW.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
3:13 p.m.
On Thu, Oct 30, 2003 at 10:52:43PM +0200, Ville Skyttä wrote:
But it already supports ACLs on branches, no?
Well, whaddya know? Already done.
The version we're using internally is an older version of that
script that didn't support ACLs on branches. I just missed that
they had been added in that version.
That was easy, thanks! :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:22 p.m.
On Thu, Oct 30, 2003 at 01:04:39PM -0700, law(a)redhat.com wrote:
In message <20031030142945.E8407(a)devserv.devel.redhat.com>,
"Michael K. Johnson
" writes:
>One of the things that I'd like to have before doing that is a
>CVS ACL implementation that allows us to put ACLS on branches.
>The one we use internally allows us to lock down a repository
>to certain developers, but I'd really like, for example, to allow
>package developers to lock down CVS HEAD on their packages but
>still let other developers do work on a branch, and then the
>main developer(s) for that package merge the work down to CVS
>HEAD when they think it's appropriate.
>
>Anyone interested in working on that?
There's actually a couple projects which are providing ACLs for CVS.
http://cvsacl.sourceforge.net/
http://cvs-nserver.sourceforge.net/
I don't know which is more mature or whether or not either is working with
the main CVS folks to ensure integration. But they're probably worth looking
into.
Well, at least the one we use now just hooks into the commitinfo
hook, so no explicit integration is necessary. I think that adding
per-branch acls to the script we have probably wouldn't be too hard
for a perl programmer. What we have is 101 lines of perl, including
comments.
If we want to control reading as well as writing, we'd need more
direct integration, such as the two patches above. Dealing with
security issues that might be worthwhile, but there are other
ways to do that.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:38 p.m.
In message <20031030152247.A19060(a)devserv.devel.redhat.com>, "Michael K.
Johnso
n" writes:
Well, at least the one we use now just hooks into the commitinfo
hook, so no explicit integration is necessary. I think that adding
per-branch acls to the script we have probably wouldn't be too hard
for a perl programmer. What we have is 101 lines of perl, including
comments.
I'm always amazed at what folks manage to do with perl. If we can do
it with commitinfo hooks rather than going to a totally different CVS
server codebase then I'm all for doing it with commitinfo hooks. My
experience with commitinfo hooks was that, yes, you can do almost
anything, but that it got rather ugly pretty quick.
If we want to control reading as well as writing, we'd need more
direct integration, such as the two patches above. Dealing with
security issues that might be worthwhile, but there are other
ways to do that.
I'm not terribly concerned about shutting down read access to
branches,
I don't think that's all that interesting of an issue for a public project
such as Fedora.
What I want to see is the ability to sandbox developers. Hell, whatever
we end up using for Fedora may be useful for the GCC project since we're
branch-happy these days :-)
jeff
3:05 a.m.
On Thu, 30 Oct 2003 law(a)redhat.com wrote:
What I want to see is the ability to sandbox developers. Hell,
whatever
we end up using for Fedora may be useful for the GCC project since we're
branch-happy these days :-)
Have you tried arch?
http://savannah.gnu.org/projects/gnu-arch/
It's very difficult to summarize in a few words all it can do, but
basically:
-you don't deal with patches of every file, you have patchsets that
include whole sets of changes
-it handles renames
-you can have your own repository locally without any special server
-you can easyly branch projects and merge back and forth among
branches with conflict
resolution
-branching is cheap, immediate
-developement style encourages creating branches for features
-development isenouraed because worknig in one's own branch freely,
without taboos, conflicts and problems let's you concentrate in what you
really want to do. And you know htat getting your work upstreamed will be
only a matter of telling the owners of the project to pick up your
patchsets (or sending them in patch format that i'ts also possible)
-it's written in C and very fast
-savannah.gnu.org will offer arch hosting too
I don't want to make you lose more time. If you feel like it could fit
your needs, that CVS is a bit limited, just try it. Or if you have any
questions, just let me know :)
Pau
2:29 p.m.
New subject: x86_64 issues, etc.
As we get closer to Release, and hopefully and x86_64 FC1 release, I would
like to offer a few things.
First, bugzilla tickets referencing x86_64 arch for fedora packages, if
you can assign them to 64bit_Fedora(a)comcast.net I will look over them and
see if I can field them in an effort to reduce load. I have a feeling
many of them will be less code issues, and more integration issues which I
should be able to easily address, and then forward on if they are code
related, or cross arch. This should help reduce the strain of supporting
another arch.
Second, I am setting up another AMD64 system to use for builds, etc for
packages where people do not have the hardware to build or test on. Just
let me know where the SRPM is and I will build and QA against AMD64 to
ensure the platform is well supported with not just core but extras.
If there is anything else I can do to assist, please let me know via email
or irc.
There has been quite a bit of interest in this platform, and with AMD
pushing it as a home user system as well, I think that interest will
continue to grow.
Thanks,
Justin M. Forbes
9:48 a.m.
New subject: x86_64 issues, etc.
Justin M. Forbes wrote:
Second, I am setting up another AMD64 system to use for builds, etc for
packages where people do not have the hardware to build or test on. Just
let me know where the SRPM is and I will build and QA against AMD64 to
ensure the platform is well supported with not just core but extras.
May I recommend trying to get vserver kernel patch working on the AMD64
kernel, that way you can securely give root access to other developers,
and each would have their own independent chroot where they can use yum
to add/remove packages... a very necessary part in the process of
developing packages. Apache can be running in another vserver instance
locally to act as a local yum source.
Give the developer vservers a different IP address and use iptables to
lockdown network access, so nothing can get out except packets belonging
to their incoming SSH connection. (Prevent any chance of abuse.)
Warren
10:54 a.m.
New subject: x86_64 issues, etc.
I would love to, but would have to work out the logistics... I am an
individual, with regular cable net access to this system, so it is DHCP
and I only get one address. In the meantime I can take existing SRPMs and
do the build for AMD64 on this system without problem. Hopefully at some
point I can look at giving others access, etc.
Justin
On Fri, 31 Oct 2003, Warren Togami wrote:
Justin M. Forbes wrote:
>
> Second, I am setting up another AMD64 system to use for builds, etc for
> packages where people do not have the hardware to build or test on. Just
> let me know where the SRPM is and I will build and QA against AMD64 to
> ensure the platform is well supported with not just core but extras.
May I recommend trying to get vserver kernel patch working on the AMD64
kernel, that way you can securely give root access to other developers,
and each would have their own independent chroot where they can use yum
to add/remove packages... a very necessary part in the process of
developing packages. Apache can be running in another vserver instance
locally to act as a local yum source.
Give the developer vservers a different IP address and use iptables to
lockdown network access, so nothing can get out except packets belonging
to their incoming SSH connection. (Prevent any chance of abuse.)
Warren
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
10:28 a.m.
New subject: x86_64 issues, etc.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 30 October 2003 12:29, Justin M. Forbes wrote:
If there is anything else I can do to assist, please let me know via
email or irc.
There has been quite a bit of interest in this platform, and with AMD
pushing it as a home user system as well, I think that interest will
continue to grow.
Justin, you totally rock! If you really make a go at it, I'll include
amd64 packages through the Legacy system.
- --
Jesse Keating RHCE MCSE (http://geek.j2solutions.net)
Fedora Legacy Team (http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/oo2W4v2HLvE71NURArQVAKCt1E/RmPE/XqBOXpAqxpISrZ9UJwCdGH1D
OSU1YbExhhRGdm6kmk/nUcU=
=ZtdI
-----END PGP SIGNATURE-----
7476
days inactive
7477
days old
12 comments
7 participants
participants (7)
-
Jeffrey A Law -
Jesse Keating -
Justin M. Forbes -
Michael K. Johnson -
Pau Aliagas -
Ville Skyttä -
Warren Togami