Mailing List Archive: DB vs SCM (was Re: [RFC] Some sync control)

DB vs SCM (was Re: [RFC] Some sync control)

Jun 17, 2008, 1:15 AM

Post #1 of 7 (186 views)

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: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

betelgeuse at gentoo

Jan 27, 2007, 6:21 AM

Post #2 of 7 (188 views)

Permalink

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.

Re: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

genone at gentoo

Jan 27, 2007, 11:09 AM

Post #3 of 7 (187 views)

Permalink

On Sat, 27 Jan 2007 13:11:07 +0000
Steve Long <slong@rathaus.eclipse.co.uk> 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.

Re: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

dberkholz at gentoo

Jan 27, 2007, 1:42 PM

Post #4 of 7 (189 views)

Permalink

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

Re: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

slong at rathaus

Jun 17, 2008, 1:15 AM

Post #5 of 7 (188 views)

Permalink

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

Re: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

slong at rathaus

Jun 17, 2008, 1:15 AM

Post #6 of 7 (189 views)

Permalink

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

Re: DB vs SCM (was Re: [RFC] Some sync control) [ In reply to ]

slong at rathaus

Jun 17, 2008, 1:15 AM

Post #7 of 7 (185 views)

Permalink

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

Mailing List Archive

Attached Files:

Attached Files:

Attached Files: