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-devgentoo.org mailing list

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.

On Sat, 27 Jan 2007 13:11:07 +0000
Steve Long <slongrathaus.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.geno
ne.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.

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