[gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Hi, Since this is a different question which got buried in the other discussion, I appreciate it should be a new thread: 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 note, I'm not talking about applications like portage or pkgcore, just the ebuild text files, which I understand have one maintainer? 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? 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. Sorry if this has all been discussed before. (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.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Steve Long wrote: Hi, 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. 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. 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. 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. (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. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
On Sat, 27 Jan 2007 13:11:07 + Steve Long [EMAIL PROTECTED] wrote: Hi, Since this is a different question which got buried in the other discussion, I appreciate it should be a new thread: 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. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] DB vs SCM (was Re: [RFC] Some sync control)
Steve Long wrote: 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. 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. Thanks, Donnie signature.asc Description: OpenPGP digital signature
