[gentoo-dev] overlay support current proposal?

[gentoo-dev] overlay support current proposal?

[Grant Goodyear]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

After reading through that fairly lengthy thread, I'm afraid that I can
no longer tell exactly what is being proposed.  Who has read access?
Who has write access?  Bugs are handled where, and by whom?  Are we
considering a fairly tightly controlled system, or a wild free-for-all?
 Exactly which problem are we proposing to solve here?

If someone could succinctly summarize the current schools of thought,
I'd be quite indebted.

Thanks,
g2boojum


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Grant Goodyear wrote:  [Fri Mar 24 2006, 02:35:34PM EST]
> After reading through that fairly lengthy thread, I'm afraid that I can
> no longer tell exactly what is being proposed.  Who has read access?
> Who has write access?  Bugs are handled where, and by whom?  Are we
> considering a fairly tightly controlled system, or a wild free-for-all?
>  Exactly which problem are we proposing to solve here?
> 
> If someone could succinctly summarize the current schools of thought,
> I'd be quite indebted.

I'll chime in, but with an additional request rather than a response.
Stuart said something about this not needing a GLEP, and maybe it
doesn't, but personally I'd rather see it go that route.  Writing
a GLEP formalizes the answers to these questions and helps to put us
all on the same page.

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Daniel Ostrow]

[-- Attachment #1: Type: text/plain, Size: 1950 bytes --]

On Friday 24 March 2006 14:35, Grant Goodyear wrote:
> After reading through that fairly lengthy thread, I'm afraid that I can
> no longer tell exactly what is being proposed.  Who has read access?
> Who has write access?  Bugs are handled where, and by whom?  Are we
> considering a fairly tightly controlled system, or a wild free-for-all?
>  Exactly which problem are we proposing to solve here?
>
> If someone could succinctly summarize the current schools of thought,
> I'd be quite indebted.
>

As I understand it...

o.g.o would be used to host developer and team based overlays that are owned 
an operated by existing Gentoo devs. Users would not be able to create their 
own overlays hosted on this system. The developer(s) who own the overlay 
would be able to control the granularity of access ranging from developers 
only, to developers plus a few trusted users, to full public ro access.

As far as I read it, who handles the bugs and by what means at this point is 
still up in the air as there seem to be some groups that would rather handle 
bugs through their own mechanisims, be that IRC, e-mail, trac whathaveyou and 
those that would like to be able to track bugs through bugs.g.o.

There is also the question of limiting the number of 'false' bug reports based 
uppon overlay usage, it seems that the best way to work through this is by 
augmenting the output of emerge --info. Things like a list of overridden 
eclasses in the output and the capability to add a package as an arguement to 
emerge --info in order to see if it is coming from an overlay seem to be good 
starting points.

On a less technical note there is also the question of using the o.g.o 
frontpage as a means to point to existing repositiories of user created 
overlays in order to promote them.

Hope that helps,

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Daniel Ostrow]

[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]

On Friday 24 March 2006 15:06, Daniel Ostrow wrote:
> On Friday 24 March 2006 14:35, Grant Goodyear wrote:
> > After reading through that fairly lengthy thread, I'm afraid that I can
> > no longer tell exactly what is being proposed.  Who has read access?
> > Who has write access?  Bugs are handled where, and by whom?  Are we
> > considering a fairly tightly controlled system, or a wild free-for-all?
> >  Exactly which problem are we proposing to solve here?
> >
> > If someone could succinctly summarize the current schools of thought,
> > I'd be quite indebted.
>
> As I understand it...
>
> o.g.o would be used to host developer and team based overlays that are
> owned an operated by existing Gentoo devs. Users would not be able to
> create their own overlays hosted on this system. The developer(s) who own
> the overlay would be able to control the granularity of access ranging from
> developers only, to developers plus a few trusted users, to full public ro
> access.
>
> As far as I read it, who handles the bugs and by what means at this point
> is still up in the air as there seem to be some groups that would rather
> handle bugs through their own mechanisims, be that IRC, e-mail, trac
> whathaveyou and those that would like to be able to track bugs through
> bugs.g.o.
>
> There is also the question of limiting the number of 'false' bug reports
> based uppon overlay usage, it seems that the best way to work through this
> is by augmenting the output of emerge --info. Things like a list of
> overridden eclasses in the output and the capability to add a package as an
> arguement to emerge --info in order to see if it is coming from an overlay
> seem to be good starting points.
>
> On a less technical note there is also the question of using the o.g.o
> frontpage as a means to point to existing repositiories of user created
> overlays in order to promote them.

Forgot one thing...

Even if an overlay doesn't have public access it's existance and a full 
Changelog would be available via the o.g.o frontpage to allow interested 
parties to contact the developer(s) who own the overlay to get involved. This 
would allow things like the Haskell overlay the ability to keep a small list 
of trusted contributers and promote the overlays existance to other potential 
users and developers.

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Stuart Herbert]

Thanks for the summary.  I think that's a fair assessment of where we are at.

The offered software will be trac, svn, and moinmoin.  I'm going to
look at darcs, and with the help of the haskell team and infra
determine if we can support it or not.  No-one has expressed a
preference for a different distributed VCS instead of darcs.

Just one more thing ...

On 3/24/06, Daniel Ostrow <dostrow@gentoo.org> wrote:
> On a less technical note there is also the question of using the o.g.o
> frontpage as a means to point to existing repositiories of user created
> overlays in order to promote them.

There are no plans to use the o.g.o frontpage in this manner.  The
frontpage will only point to overlays owned by Gentoo developers.

I'm not saying 'never'.  But this isn't something I'm going to roll
out in the initial deployment.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Alec Warner]

Stuart Herbert wrote:
> Thanks for the summary.  I think that's a fair assessment of where we are at.
> 
> The offered software will be trac, svn, and moinmoin.  I'm going to
> look at darcs, and with the help of the haskell team and infra
> determine if we can support it or not.  No-one has expressed a
> preference for a different distributed VCS instead of darcs.

bazaar-NG is distributed VCS, but requires only a web server so you
can't really 'prevent' it's use.

> 
> Just one more thing ...
> 
> On 3/24/06, Daniel Ostrow <dostrow@gentoo.org> wrote:
> 
>>On a less technical note there is also the question of using the o.g.o
>>frontpage as a means to point to existing repositiories of user created
>>overlays in order to promote them.
> 
> 
> There are no plans to use the o.g.o frontpage in this manner.  The
> frontpage will only point to overlays owned by Gentoo developers.
> 
> I'm not saying 'never'.  But this isn't something I'm going to roll
> out in the initial deployment.
> 
> Best regards,
> Stu
> 
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]

On Friday 24 March 2006 21:44, Stuart Herbert wrote:
> The offered software will be trac, svn, and moinmoin.  I'm going to
> look at darcs, and with the help of the haskell team and infra
> determine if we can support it or not.  No-one has expressed a
> preference for a different distributed VCS instead of darcs.
I haven't being following discussion, to be honest, as I don't really have 
time to read mailing lists lately, but I'm happy I've spotted this mail at 
least...

Although I don't know darcs at all in terms of use and feature, I would really 
suggest to _not_ use it. For a simple reason, actually: cvs has almost no 
cost added, as it's present on every major distribution, system and operating 
system, being well known and written in plain C with just a few dependencies; 
svn has a bit more costs, as it requires apr, berkdb and neon, but it's also 
available on a wide range of different system because it's also in C mainly.
Darcs, instead, is written in Haskell, which means you need architectures that 
supports Haskell, and in which it's stable enough to work... considering we 
have Gentoo/Alt, it's not that good to "cut" us off (yes I know I should be 
able to make Gentoo/FreeBSD and maybe other arches to have ghc, but that's 
not easy and not on my top priority list, while support for overlays can be 
useful.. for a while we needed java overlay to get kaffe, for example).

Also, the way ghc is bootstrapped (need a -bin and then build from sources) 
makes it not exactly painless to handle... and it's an extra language needed 
anyway.

I would be more in favour of GNU arch derived like bzr (bazaar-ng) or 
mercurial, that are written in Python. While we should know that 
saying "being interpreted means it runs anyway" doesn't fly, a working python 
is already a strict requirement (portage, anyone?) and it's way less pain 
that ghc, IMHO.

I'm also sure bzr works fine on FreeBSD, DragonFly and OSX as I've tried it 
myself..

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Duncan Coutts]

On Sat, 2006-03-25 at 03:31 +0100, Diego 'Flameeyes' Pettenò wrote:

> Darcs, instead, is written in Haskell, which means you need architectures that 
> supports Haskell, and in which it's stable enough to work... considering we 
> have Gentoo/Alt, it's not that good to "cut" us off (yes I know I should be 
> able to make Gentoo/FreeBSD and maybe other arches to have ghc,

We've got ghc working on ppc-osx and ghc of course works on FreeBSD
(it's in FreeBSD ports) so all it needs is a helper for Gentoo/FreeBSD.
I know you're busy of course but it doesn't need your time specifically,
anyone using Gentoo/FreeBSD could do it. We can walk them through the
process.

We're working on ia64 support. s390 support would be possible if we had
access to the hardware. The only arches we don't have much hope of
supporting are arm, mips and sh. (It works on mips on irix but we have
problems with GOT overflow on mips linux.)

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

On Saturday 25 March 2006 12:41, Duncan Coutts wrote:
> We've got ghc working on ppc-osx and ghc of course works on FreeBSD
> (it's in FreeBSD ports) so all it needs is a helper for Gentoo/FreeBSD.
NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris?

Really it's not a cheap dependency as it is now, especially when starting a 
new port, that might be quite interesting, if not to use already present 
overlays, to have an overlay itself.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

On Saturday 25 March 2006 12:49, Diego 'Flameeyes' Pettenò wrote:
> NetBSD, OpenBSD, GNU/kFreeBSD, GNU/Hurd, Solaris?

It's great that you and others are working on alternative platforms, but 
regarding decisions which tools we use, our main platforms are of interest. 
Everyone else should/has to make it work, imho. I don't think it's acceptable 
to base our decisions on platforms nearly no one is using. This is meant as a 
general remark, not especially regarding a distributed vcs.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Saturday 25 March 2006 16:08, Carsten Lohrke wrote:
> I don't think it's 
> acceptable to base our decisions on platforms nearly no one is using.
I'll try to avoid a flame reminding when Linux was really used only by a few 
geeks...
And I'm trying to avoid saying this, but the day was sucky and I don't feel 
like limiting myself this time.

This is the same line of thinking that makes people use flash or wmv "because 
it's the silly Linux users that has to adapt, Windows works fine" and 
similar.
So this is really a paradox for a project that should involve Free/Libre 
software.

But that's another thing/

> Thisis meant as a general remark, not especially regarding a distributed
> vcs.
In this particular case I'm asking for a solution that can accomodate more 
than just us. I'm positive that there are solutions as good as darcs that 
does not require Haskell, but of course if there's a killer requirement that 
makes darcs the only solution we'll work on make it available.

Of course doing like people using Flash to write a website that could have 
been built using plain HTML and animated GIF images, and using darcs only 
because it was the first idea while there are good alternatives that works 
for more people would be something that will a) piss me off quite a bit 
because of the paradox said above b) make the whole project laughtable by 
other Free Software projects finding the above analogy...

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 1524 bytes --]

On Saturday 25 March 2006 19:50, Diego 'Flameeyes' Pettenò wrote:
> This is the same line of thinking that makes people use flash or wmv
> "because it's the silly Linux users that has to adapt, Windows works fine"
> and similar.

It's not. Darcs is not proprietary, so you can make it work if you want/need 
it. And it's up to those who use a specific platform to make it flourish, but 
holding us back to use something because of some specific platform having not 
enough developers/users/steam to follow would be entirely stupid.

> > Thisis meant as a general remark, not especially regarding a distributed
> > vcs.
>
> In this particular case I'm asking for a solution that can accomodate more
> than just us. I'm positive that there are solutions as good as darcs that
> does not require Haskell, but of course if there's a killer requirement
> that makes darcs the only solution we'll work on make it available.

Once again, I did not say anything in favor of any vcs.

> Of course doing like people using Flash to write a website that could have
> been built using plain HTML and animated GIF images, and using darcs only
> because it was the first idea while there are good alternatives that works
> for more people would be something that will a) piss me off quite a bit
> because of the paradox said above b) make the whole project laughtable by
> other Free Software projects finding the above analogy...

The comparison to proprietary software is completely out of line.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Stephen P. Becker]

Carsten Lohrke wrote:
> On Saturday 25 March 2006 19:50, Diego 'Flameeyes' Pettenò wrote:
>> This is the same line of thinking that makes people use flash or wmv
>> "because it's the silly Linux users that has to adapt, Windows works fine"
>> and similar.
> 
> It's not. Darcs is not proprietary, so you can make it work if you want/need 
> it. And it's up to those who use a specific platform to make it flourish, but 
> holding us back to use something because of some specific platform having not 
> enough developers/users/steam to follow would be entirely stupid.

Actually, you are incorrent, and apparently haven't listened to at least
a couple of emails from dcoutts.  At this time, ghc is totally
unfeasable on mips, and therefore so is Darcs.  There is no reason to
screw over one arch when there are other VCS implementations which will
work.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

On Sat, 25 Mar 2006 03:31:34 +0100
"Diego 'Flameeyes' Pettenò" <flameeyes@gentoo.org> wrote:

> Although I don't know darcs at all in terms of use and feature, I
> would really suggest to _not_ use it. For a simple reason, actually:
> cvs has almost no cost added, as it's present on every major
> distribution, system and operating system, being well known and
> written in plain C with just a few dependencies; svn has a bit more
> costs, as it requires apr, berkdb and neon, but it's also available
> on a wide range of different system because it's also in C mainly.

If you're suggesting CVS as the second VCS (i.e. in addition to SVN)
then I don't see the point - SVN is simply a better CVS and clients
should be available on the alt platforms.

> Darcs, instead, is written in Haskell, which means you need
> architectures that supports Haskell, and in which it's stable enough
> to work... considering we have Gentoo/Alt, it's not that good to
> "cut" us off (yes I know I should be able to make Gentoo/FreeBSD and
> maybe other arches to have ghc, but that's not easy and not on my top
> priority list, while support for overlays can be useful.. for a while
> we needed java overlay to get kaffe, for example).

This is a valid issue, as ghc is only supplied upstream for linux (some
older versions available in mingw32).

> I would be more in favour of GNU arch derived like bzr (bazaar-ng) or 
> mercurial, that are written in Python. While we should know that 
> saying "being interpreted means it runs anyway" doesn't fly, a
> working python is already a strict requirement (portage, anyone?) and
> it's way less pain that ghc, IMHO.
> 
> I'm also sure bzr works fine on FreeBSD, DragonFly and OSX as I've
> tried it myself..

Language issues aside, it makes sense to support a distributed VCS in
addition to SVN, as that would provide a useful alternative.  There's a
quick comparison at http://bazaar-vcs.org/RcsComparisons.  Of the
alternatives to Bazaar-NG, Mercurial (at
http://www.selenic.com/mercurial/) looks most interesting, not least
because it claims fast local and network performance, which bazaar-ng
doesn't.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Duncan Coutts]

On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:

> This is a valid issue, as ghc is only supplied upstream for linux (some
> older versions available in mingw32).

I don't think this is right. All the recent ghc versions have been
supplied upstream on many OSs including installers for win32 and OSX.
The OpenBSD, FreeBSD & Darwin ports systems include ghc.

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Sat, 25 Mar 2006 11:46:58 +0000
Duncan Coutts <dcoutts@gentoo.org> wrote:

> On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
> 
> > This is a valid issue, as ghc is only supplied upstream for linux
> > (some older versions available in mingw32).
> 
> I don't think this is right. All the recent ghc versions have been
> supplied upstream on many OSs including installers for win32 and OSX.
> The OpenBSD, FreeBSD & Darwin ports systems include ghc.

Sorry, yes - I looked at the snapshot download pages where it's linux
and mingw32) instead of the release download pages (where it's linux
x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X
and AIX).

However the issue still remains for non-x86/ppc platforms; sparc in
particular is likely to be used as a dev platform by some.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Duncan Coutts]

On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote:
> On Sat, 25 Mar 2006 11:46:58 +0000
> Duncan Coutts <dcoutts@gentoo.org> wrote:
> 
> > On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
> > 
> > > This is a valid issue, as ghc is only supplied upstream for linux
> > > (some older versions available in mingw32).
> > 
> > I don't think this is right. All the recent ghc versions have been
> > supplied upstream on many OSs including installers for win32 and OSX.
> > The OpenBSD, FreeBSD & Darwin ports systems include ghc.
> 
> Sorry, yes - I looked at the snapshot download pages where it's linux
> and mingw32) instead of the release download pages (where it's linux
> x86, x86_64, ppc, ppc64 and windows, FreeBSD x86, OpenBSD x86, MacOS X
> and AIX).
> 
> However the issue still remains for non-x86/ppc platforms; sparc in
> particular is likely to be used as a dev platform by some.

I use ghc and darcs on my sparc box all the time. ghc-6.4.1-r2 is
currently marked stable on sparc. darcs is currently marked ~sparc.

I'm currently working on ghc for ia64 since Aron Griffis was interested
in using darcs on ia64. It's looking good so far.

As Flameeyes pointed out our main problem is with the various Gentoo/ALT
systems where we don't have quite enough developer time to allow ghc to
get near the top of the TODO list (though we do have it working with ppc
osx).

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Kevin F. Quinn (Gentoo)]

[-- Attachment #1: Type: text/plain, Size: 1783 bytes --]

On Sat, 25 Mar 2006 12:37:45 +0000
Duncan Coutts <dcoutts@gentoo.org> wrote:

> On Sat, 2006-03-25 at 13:32 +0100, Kevin F. Quinn (Gentoo) wrote:
> > On Sat, 25 Mar 2006 11:46:58 +0000
> > Duncan Coutts <dcoutts@gentoo.org> wrote:
> > 
> > > On Sat, 2006-03-25 at 12:42 +0100, Kevin F. Quinn (Gentoo) wrote:
> > > 
> > > > This is a valid issue, as ghc is only supplied upstream for
> > > > linux (some older versions available in mingw32).
> > > 
> > > I don't think this is right. All the recent ghc versions have been
> > > supplied upstream on many OSs including installers for win32 and
> > > OSX. The OpenBSD, FreeBSD & Darwin ports systems include ghc.
> > 
> > Sorry, yes - I looked at the snapshot download pages where it's
> > linux and mingw32) instead of the release download pages (where
> > it's linux x86, x86_64, ppc, ppc64 and windows, FreeBSD x86,
> > OpenBSD x86, MacOS X and AIX).
> > 
> > However the issue still remains for non-x86/ppc platforms; sparc in
> > particular is likely to be used as a dev platform by some.
> 
> I use ghc and darcs on my sparc box all the time. ghc-6.4.1-r2 is
> currently marked stable on sparc. darcs is currently marked ~sparc.

Ahem.  Sorry again - I still didn't look at the right page!

http://www.haskell.org/ghc/download_ghc_641.html

lists sparc, hppa, and also alpha, m68k & s390 on debian.

> I'm currently working on ghc for ia64 since Aron Griffis was
> interested in using darcs on ia64. It's looking good so far.
> 
> As Flameeyes pointed out our main problem is with the various
> Gentoo/ALT systems where we don't have quite enough developer time to
> allow ghc to get near the top of the TODO list (though we do have it
> working with ppc osx).
> 


-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Saturday 25 March 2006 12:42, Kevin F. Quinn (Gentoo) wrote:
> If you're suggesting CVS as the second VCS (i.e. in addition to SVN)
> then I don't see the point - SVN is simply a better CVS and clients
> should be available on the alt platforms.
No, I was just stating the fact that cvs in itself is cheap wrt dependencies. 
I try to avoid using it myself if I haven't to.

> Language issues aside, it makes sense to support a distributed VCS in
> addition to SVN, as that would provide a useful alternative.
Acknowledged. I find it useful myself, the only problem I see is, as I said, 
that darcs is not as cheap as cvs or svn, or even as bazaar-ng and mercurial, 
wrt dependencies.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]

Stuart Herbert <stuart.herbert@gmail.com> said:
> Thanks for the summary.  I think that's a fair assessment of where we are at.
> 
> The offered software will be trac, svn, and moinmoin.  I'm going to
> look at darcs, and with the help of the haskell team and infra
> determine if we can support it or not.  No-one has expressed a
> preference for a different distributed VCS instead of darcs.
> 
> Just one more thing ...

It sounds to me like the overlays would benefit of using git/cogito.
The Linux Kernel uses this DVCS to full affect. Pulling changes from
other repositories, and even receiving email patches pushed from
people not having their own official repository (or repository http or
ssh accessible).  Any git checkout is a branch, so its easy to stay up
to date with the mainline tree and still work on personal branches.

We need to pick one VCS and only one.  Having multiple systems
requires users to install multiple applications and learn each one.
Not all of them are easy to pick up.  Plus, it would be nice to be
able to merge from the overlays to the Portage trunk.

I think git/cogito might be the solution.  It works for a highly
distributed kernel development, which would be similar to the way the
overlays would work.  Gentoo User A would checkout the kde overlay,
make some changes, cg-commit them to their own overlay, and submit the
patches upstream via an email requesting a pull, or emailing them
patches directly with a git-mkmail command.

An alternative to git would be using subversion.  

*** The main portage tree should be switched away from CVS. ***
There are much better alternatives (svn or git) to use.

CVS is our bottleneck when it comes to development and our users too.
What I see is that the overlays are trying to create branches, when
they should not need to.  Making a PHP or Gnome v2000 overlay is
ridiculous, since a branch is almost free using subversion.  There are
more advantages, like making sure the rest of the tree doesn't break,
and when the branch is stable for package.mask or arch masking then
merge the branch to trunk.  The main tree could live within subversion
(or whatever VCS we choose) as a branch.  It would be easy to keep the
branch up to date with trunk, and then merge the changes to the live
branch.  Major changes to the tree need to be done in a branch where
it should be done.

Overlays should be used only for small additions/changes/or tests.  It
feels like the overlays are already trying to create branches, when in
fact, they would not have to if the main tree was _not_ in CVS.

There are advantages to subversion and advantages to git.  I propose
picking one (I vote for subversion) to use for the overlays.  I also
believe that CVS is now hindering us from reaching our goals as a
project.

Comments?

-Ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-dev] Re: overlay support current proposal?

[Duncan]

Ryan Phillips posted <20060325064751.GA8104@trolocsis.dyndns.org>,
excerpted below,  on Fri, 24 Mar 2006 22:47:51 -0800:

> We need to pick one VCS and only one.  Having multiple systems
> requires users to install multiple applications and learn each one.
> Not all of them are easy to pick up.  Plus, it would be nice to be
> able to merge from the overlays to the Portage trunk.

Keep in mind that due to the potential overlay overlap issues, most users
will likely only use one or two of the overlays and that would certainly
be the recommended approach. Thus, they'll merge and learn (if necessary)
whatever their chosen overlay is using, and not worry about the others. 
Advanced users and devs able to deal with the potential conflicts of
multiple overlays shouldn't have difficulty managing multiple version
control systems, and they'll be the only ones that have to worry about it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 4275 bytes --]

Ryan Phillips wrote:  [Sat Mar 25 2006, 01:47:51AM EST]
> It sounds to me like the overlays would benefit of using git/cogito.
> The Linux Kernel uses this DVCS to full affect. Pulling changes from
> other repositories, and even receiving email patches pushed from
> people not having their own official repository (or repository http
> or ssh accessible).  Any git checkout is a branch, so its easy to
> stay up to date with the mainline tree and still work on personal
> branches.

Most of the other DVCSs are easier to use than git, and just as
powerful or more.  IMHO git is used for Linux mostly because Linus
wrote it, rather than it being the best tool for the job.

I think any of mercurial, darcs or bazaar-ng is a better choice than
git.  Regarding cogito, I haven't looked at it in a while, but the
last time I did, it was underpowered and buggy.  AFAIK none of the
kernel developers use it, 'cause it doesn't hold up under serious use.

> We need to pick one VCS and only one.  Having multiple systems
> requires users to install multiple applications and learn each one.
> Not all of them are easy to pick up.  Plus, it would be nice to be
> able to merge from the overlays to the Portage trunk.

This would be pretty neat eventually, to switch portage itself over to
a DVCS so that all the overlays would simply be branches that could be
merged, etc.  At this point it would be biting off more than we can
chew, though...  Perhaps using various DVCS solutions for the overlays
might actually be a good testing ground for determining the successor
to cvs for the actual portage tree.

At any rate, I don't think it's necessary to limit ourselves to one.
You're right, developers will have to install multiple applications
and learn each one for the overlays they work on.  Probably it won't
be that many, though (overlays or applications) and r/o users will
likely just get an rsync'd copy instead of using the DVCS to access
the overlay (at least that's how I imagine it working...)

> I think git/cogito might be the solution.  It works for a highly
> distributed kernel development, which would be similar to the way
> the overlays would work.  Gentoo User A would checkout the kde
> overlay, make some changes, cg-commit them to their own overlay, and
> submit the patches upstream via an email requesting a pull, or
> emailing them patches directly with a git-mkmail command.

*shrug*  All possible with the other DVCSs, generally easier to use,
and harder to screw up your repo.

> An alternative to git would be using subversion.  
> 
> *** The main portage tree should be switched away from CVS. ***
> There are much better alternatives (svn or git) to use.

Have you followed the threads in the past regarding using other
version control systems for portage?  Some devs have done benchmarks
and found that there are blocking issues with subversion, particularly
because of its repo-wide revisions that prevent multiple commits from
happening simultaneously.

> CVS is our bottleneck when it comes to development and our users
> too.  What I see is that the overlays are trying to create branches,
> when they should not need to.  Making a PHP or Gnome v2000 overlay
> is ridiculous, since a branch is almost free using subversion.
> There are more advantages, like making sure the rest of the tree
> doesn't break, and when the branch is stable for package.mask or
> arch masking then merge the branch to trunk.  The main tree could
> live within subversion (or whatever VCS we choose) as a branch.  It
> would be easy to keep the branch up to date with trunk, and then
> merge the changes to the live branch.  Major changes to the tree
> need to be done in a branch where it should be done.
> 
> Overlays should be used only for small additions/changes/or tests.
> It feels like the overlays are already trying to create branches,
> when in fact, they would not have to if the main tree was _not_ in
> CVS.

I agree this sounds really nice and makes a lot of sense.  I think
that the overlay project is a step toward this, though, not a step
away.  The time isn't yet ripe for switching the portage tree to
different VCS.

> Comments?

I guess you asked... :-)

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

Aron Griffis wrote:  [Sat Mar 25 2006, 06:00:49PM EST]
> Ryan Phillips wrote:  [Sat Mar 25 2006, 01:47:51AM EST]
> > It sounds to me like the overlays would benefit of using git/cogito.
> > The Linux Kernel uses this DVCS to full affect. Pulling changes from
> > other repositories, and even receiving email patches pushed from
> > people not having their own official repository (or repository http
> > or ssh accessible).  Any git checkout is a branch, so its easy to
> > stay up to date with the mainline tree and still work on personal
> > branches.
> 
> Most of the other DVCSs are easier to use than git, and just as
> powerful or more.  IMHO git is used for Linux mostly because Linus
> wrote it, rather than it being the best tool for the job.

I should backpedal on that statement a bit...  While I think it's true
historically, git is doing a great job for kernel development, and it
can't be criticized lightly.  Nonetheless, similar power is available
in other DVCSs that are easier to use and less likely to cause
headaches.

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 550 bytes --]

On Sat, Mar 25, 2006 at 06:12:07PM -0500, Aron Griffis wrote:
> I should backpedal on that statement a bit...  While I think it's true
> historically, git is doing a great job for kernel development, and it
> can't be criticized lightly.  Nonetheless, similar power is available
> in other DVCSs that are easier to use and less likely to cause
> headaches.

Now my other mail doesn't make a lot of sense :)

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]

On Sat, Mar 25, 2006 at 06:00:49PM -0500, Aron Griffis wrote:
> Ryan Phillips wrote:  [Sat Mar 25 2006, 01:47:51AM EST]
> > It sounds to me like the overlays would benefit of using git/cogito.
> > The Linux Kernel uses this DVCS to full affect. Pulling changes from
> > other repositories, and even receiving email patches pushed from
> > people not having their own official repository (or repository http
> > or ssh accessible).  Any git checkout is a branch, so its easy to
> > stay up to date with the mainline tree and still work on personal
> > branches.
> 
> Most of the other DVCSs are easier to use than git, and just as
> powerful or more.  IMHO git is used for Linux mostly because Linus
> wrote it, rather than it being the best tool for the job.

Well, I find it easier to understand than many other DVCSs out there...
In fact I don't think it is difficult to use in any way. Maybe pre-1.1
versions had some syntax weirdnesses, but the 1.2 series are really easy
to use and understand...

> > I think git/cogito might be the solution.  It works for a highly
> > distributed kernel development, which would be similar to the way
> > the overlays would work.  Gentoo User A would checkout the kde
> > overlay, make some changes, cg-commit them to their own overlay, and
> > submit the patches upstream via an email requesting a pull, or
> > emailing them patches directly with a git-mkmail command.
> 
> *shrug*  All possible with the other DVCSs, generally easier to use,
> and harder to screw up your repo.

How would you screw your repo using normal Git commands ?

Cheers,
Ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

Fernando J. Pereda wrote:  [Sat Mar 25 2006, 06:18:52PM EST]
> Well, I find it easier to understand than many other DVCSs out there...
> In fact I don't think it is difficult to use in any way. Maybe pre-1.1
> versions had some syntax weirdnesses, but the 1.2 series are really easy
> to use and understand...

That is good to hear.  It's possible that my comments were misplaced,
and it would be worth my while to reinvestigate git.  Personally I use
mercurial daily (xen) and I've been very happy with it.

I'm under the impression that mercurial is easier to use than git,
mostly because of git's philosophy of providing the low-level
infrastructure and expecting other projects to build user-friendly
interfaces.  While that split sounds good in theory, it seems to
result in one interface that's powerful+complex, and other interfaces
that are weak+easy.  Again, that's an impression, not recent personal
experience.

> > *shrug*  All possible with the other DVCSs, generally easier to
> > use, and harder to screw up your repo.
> 
> How would you screw your repo using normal Git commands ?

I shouldn't have made that statement since I haven't done it
personally, only heard of it happening to other people, and not
recently.

Aron

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]

On Sat, Mar 25, 2006 at 07:57:43PM -0500, Aron Griffis wrote:
> Fernando J. Pereda wrote:  [Sat Mar 25 2006, 06:18:52PM EST]
> > Well, I find it easier to understand than many other DVCSs out there...
> > In fact I don't think it is difficult to use in any way. Maybe pre-1.1
> > versions had some syntax weirdnesses, but the 1.2 series are really easy
> > to use and understand...
> 
> That is good to hear.  It's possible that my comments were misplaced,
> and it would be worth my while to reinvestigate git.  Personally I use
> mercurial daily (xen) and I've been very happy with it.
> 
> I'm under the impression that mercurial is easier to use than git,
> mostly because of git's philosophy of providing the low-level
> infrastructure and expecting other projects to build user-friendly
> interfaces.  While that split sounds good in theory, it seems to
> result in one interface that's powerful+complex, and other interfaces
> that are weak+easy.  Again, that's an impression, not recent personal
> experience.

Definately that was the case some months ago. Now Git provides a
'porcelain' (user oriented) interface, and using the 'plumbing' (core)
tools directly is highly discouraged.

Also Cogito has improved a lot since then.

> > > *shrug*  All possible with the other DVCSs, generally easier to
> > > use, and harder to screw up your repo.
> > 
> > How would you screw your repo using normal Git commands ?
> 
> I shouldn't have made that statement since I haven't done it
> personally, only heard of it happening to other people, and not
> recently.

Again, might be the case with ancient versions, I screwed some of my
repos :) But definately not with post-1.0 versions.

Basically, I think you tried/heard about, ancient versions of Git and
Cogito, and yeah... the very first versions were a PITA sometimes.

Cheers,
Ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Greg KH]

On Sat, Mar 25, 2006 at 07:57:43PM -0500, Aron Griffis wrote:
> Fernando J. Pereda wrote:  [Sat Mar 25 2006, 06:18:52PM EST]
> > Well, I find it easier to understand than many other DVCSs out there...
> > In fact I don't think it is difficult to use in any way. Maybe pre-1.1
> > versions had some syntax weirdnesses, but the 1.2 series are really easy
> > to use and understand...
> 
> That is good to hear.  It's possible that my comments were misplaced,
> and it would be worth my while to reinvestigate git.  Personally I use
> mercurial daily (xen) and I've been very happy with it.
> 
> I'm under the impression that mercurial is easier to use than git,
> mostly because of git's philosophy of providing the low-level
> infrastructure and expecting other projects to build user-friendly
> interfaces.  While that split sounds good in theory, it seems to
> result in one interface that's powerful+complex, and other interfaces
> that are weak+easy.  Again, that's an impression, not recent personal
> experience.

Yeah, that's a lot of people's "impression" that haven't use git before,
and we need to get Linus to stop downplaying it all of the time.  But if
you've used it, you will quickly see how powerful and sane git is.  I
don't know of anyone who has used it that doesn't just absolutly love
it.

And it's come a long way recently and is much nicer and no extra
"user-friendly" helper tools are needed at all.  Don't be put off by the
70+ different git commands, just go through the tutorial and try it out
for yourself.

In short, I can't recommend git enough, it works wonderful for doing
things like storing my mbox archive, kernel development, shared
repository development of other projects with multiple developers, and
even handling system configuration files.

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Ryan Phillips]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Aron Griffis <agriffis@gentoo.org> said:
> Have you followed the threads in the past regarding using other
> version control systems for portage?  Some devs have done benchmarks
> and found that there are blocking issues with subversion, particularly
> because of its repo-wide revisions that prevent multiple commits from
> happening simultaneously.

In actuality, Subversion does 98% of the commit in an initial
transaction, and the blocking only occurs in the last 2% with the FSFS
filesystem.  It really isn't an issue and shouldn't prevent us from
adopting it.

-ryan

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Monday 27 March 2006 07:43, Ryan Phillips wrote:
> Aron Griffis <agriffis@gentoo.org> said:
> > Have you followed the threads in the past regarding using other
> > version control systems for portage?  Some devs have done benchmarks
> > and found that there are blocking issues with subversion,
> > particularly because of its repo-wide revisions that prevent multiple
> > commits from happening simultaneously.
>
> In actuality, Subversion does 98% of the commit in an initial
> transaction, and the blocking only occurs in the last 2% with the FSFS
> filesystem.  It really isn't an issue and shouldn't prevent us from
> adopting it.

Indeed, subversion first uploads the stuff, only then creates a new 
revision. In any case one does not want multiple commits at the same time 
in any case. For full portage the problems are more likely to be with svn 
update. One can expect there will be a lot more updates than commits. As 
the commits done are fairly small, those should not be an issue. Updates 
work on the whole tree however. Initial checkouts are worse, because they 
require the head to be reassembled (IIRC). Head checkout could be cached 
though (but I don't think that's done currently).

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

On Monday 27 March 2006 10:29, Paul de Vrieze wrote:
> On Monday 27 March 2006 07:43, Ryan Phillips wrote:
> > In actuality, Subversion does 98% of the commit in an initial
> > transaction, and the blocking only occurs in the last 2% with the FSFS
> > filesystem.  It really isn't an issue and shouldn't prevent us from
> > adopting it.
>
> Indeed, subversion first uploads the stuff, only then creates a new
> revision. In any case one does not want multiple commits at the same time
> in any case. For full portage the problems are more likely to be with svn
> update. One can expect there will be a lot more updates than commits. As
> the commits done are fairly small, those should not be an issue. Updates
> work on the whole tree however. Initial checkouts are worse, because they
> require the head to be reassembled (IIRC). Head checkout could be cached
> though (but I don't think that's done currently).

This thread [1] from subversion-users asked about update/checkout performance. 
The svn people answered that performance usually isn't constrained by 
reassembly time. Moreover, the older BDB repo format stores the complete 
latest revision, and checkouts aren't significantly faster than from FSFS.

(Of course, if SVN working copies didn't contain two complete copies of the 
stored data plus some fat metadata, then reassembly time would likely affect 
checkout time.)

[2] explains the SVN skip-deltas storage method.

Disclaimer, I haven't run any huge-repo benchmarks myself, just pointing to 
possibly relevant data.

[1] http://svn.haxx.se/users/archive-2005-04/0518.shtml
[2] http://svn.collab.net/repos/svn/trunk/notes/skip-deltas

-- 
Dan Armak
Gentoo Linux developer (KDE)
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Monday 27 March 2006 22:58, Dan Armak wrote:
> This thread [1] from subversion-users asked about update/checkout
> performance. The svn people answered that performance usually isn't
> constrained by reassembly time. Moreover, the older BDB repo format stores
> the complete latest revision, and checkouts aren't significantly faster
> than from FSFS.

That's interesting. If possible I think that a fsfs repository should be used. 
BDB repositories are too fragile in respect to berkeley db.

Of course we should perhaps just try things out.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Chris Bainbridge]

On 27/03/06, Ryan Phillips <rphillips@gentoo.org> wrote:
> Aron Griffis <agriffis@gentoo.org> said:
> > Have you followed the threads in the past regarding using other
> > version control systems for portage?  Some devs have done benchmarks
> > and found that there are blocking issues with subversion, particularly
> > because of its repo-wide revisions that prevent multiple commits from
> > happening simultaneously.
>
> In actuality, Subversion does 98% of the commit in an initial
> transaction, and the blocking only occurs in the last 2% with the FSFS
> filesystem.  It really isn't an issue and shouldn't prevent us from
> adopting it.

All svn commits are atomic, and that requires some kind of global
lock. I'd say the (slight) performance penalty is worth it for that
feature alone. I'd also point out that the KDE project have everything
in a single svn repository and can manage >10,000 commits per month
with no problems. There are various testimonials around from people
claiming to be running svn on multiple GB repositories with >17,000
commits a month.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]

On Mon, 2006-03-27 at 09:51 +0100, Chris Bainbridge wrote:
> On 27/03/06, Ryan Phillips <rphillips@gentoo.org> wrote:
> > Aron Griffis <agriffis@gentoo.org> said:
> > > Have you followed the threads in the past regarding using other
> > > version control systems for portage?  Some devs have done benchmarks
> > > and found that there are blocking issues with subversion, particularly
> > > because of its repo-wide revisions that prevent multiple commits from
> > > happening simultaneously.
> >
> > In actuality, Subversion does 98% of the commit in an initial
> > transaction, and the blocking only occurs in the last 2% with the FSFS
> > filesystem.  It really isn't an issue and shouldn't prevent us from
> > adopting it.
> 
> All svn commits are atomic, and that requires some kind of global
> lock. I'd say the (slight) performance penalty is worth it for that
> feature alone. I'd also point out that the KDE project have everything
> in a single svn repository and can manage >10,000 commits per month
> with no problems. There are various testimonials around from people
> claiming to be running svn on multiple GB repositories with >17,000
> commits a month.

Well, CIA seems to differ from your stats.

Gentoo: 8495 last month http://cia.navi.cx/stats/project/gentoo
KDE: 7523 last month http://cia.navi.cx/stats/project/KDE

Now, according to the stats, I would say that we have a similar commit
rate as KDE, though not all of ours are on the same repository and some
are on CVS and some are on SVN, so the stats aren't 100% accurate for
getting just the main portage tree.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Duncan Coutts]

On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote:

> We need to pick one VCS and only one.  Having multiple systems
> requires users to install multiple applications and learn each one.
> Not all of them are easy to pick up.  Plus, it would be nice to be
> able to merge from the overlays to the Portage trunk.

I'm not sure it is realistic at the moment to pick just one DVCS. Apart
from getting one that works on all systems, it's likely to be hard to
get everyone to agree.

There's a slight danger that the discussion of which VCS could distract
us from the important questions.

If we're going with the idea that at least at first these overlay are
going to be run by and for projects/teams/herds then perhaps the choice
of VCS is not so important. So long as it's feasible with infra of
course. Since we don't yet expect people to be using several of these
overlays at once it's probably that each developer or outside
contributer would not need to use more than one VCS (in addition to cvs
for portage).

As a plus side, this might give us some feedback on which (D)VCSs work
well for overlay development and might help inform our future decisions
on possible cvs replacements.

BTW I hope that with all my recent emails on the issue of which
arches/platforms can run darcs I've not been giving the impression that
I'm pushing for darcs to be the "one true" choice. I am certainly
interested in working with any arch team to get ghc and darcs ported but
that's a separate issue.

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Luca Barbato]

Duncan Coutts wrote:
> On Fri, 2006-03-24 at 22:47 -0800, Ryan Phillips wrote:
> 
>> We need to pick one VCS and only one.  Having multiple systems
>> requires users to install multiple applications and learn each one.
>> Not all of them are easy to pick up.  Plus, it would be nice to be
>> able to merge from the overlays to the Portage trunk.
> 
> I'm not sure it is realistic at the moment to pick just one DVCS. Apart
> from getting one that works on all systems, it's likely to be hard to
> get everyone to agree.
> 
> There's a slight danger that the discussion of which VCS could distract
> us from the important questions.
> 
> If we're going with the idea that at least at first these overlay are
> going to be run by and for projects/teams/herds then perhaps the choice
> of VCS is not so important. So long as it's feasible with infra of
> course. Since we don't yet expect people to be using several of these
> overlays at once it's probably that each developer or outside
> contributer would not need to use more than one VCS (in addition to cvs
> for portage).
> 
> As a plus side, this might give us some feedback on which (D)VCSs work
> well for overlay development and might help inform our future decisions
> on possible cvs replacements.
> 
> BTW I hope that with all my recent emails on the issue of which
> arches/platforms can run darcs I've not been giving the impression that
> I'm pushing for darcs to be the "one true" choice. I am certainly
> interested in working with any arch team to get ghc and darcs ported but
> that's a separate issue.
> 

given that darcs can export and import git with ease and mercurial can 
do the same up to a degree, we could use those three.

(since they are all documented people could implement them in other 
language if they wish)

darcs : ghc
mercurial : python
git : c+bash (and optional perl/python for some merge scripts)

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Sun, Mar 26, 2006 at 06:39:15AM +0200, Luca Barbato wrote:
> git : c+bash (and optional perl/python for some merge scripts)

Just for clarifying things:

A strict server doesn't need perl or python (not even bash) though bash
is highly recommended.

A client NEEDS python because the 'recursive' (default and best) merge
strategy is written in python.

Cheers,
Ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Patrick McLean]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Fernando J. Pereda wrote:
> On Sun, Mar 26, 2006 at 06:39:15AM +0200, Luca Barbato wrote:
>> git : c+bash (and optional perl/python for some merge scripts)

I think git is probably the best choice, I have played with it a little
myself and it is _very_ powerful, it also has a very simple dependency
set (all it's deps are in the Gentoo core system, and are either
available or installed by default on every *NIX I know of).

I agree with Flameeyes that it would be best if we use a DVCS that
doesn't have too many deps that might or might not work on other
platforms/systems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEKWRPWt/XSf2CZdkRArDgAJ4mQx/cnxQSBpKpL2o+N9/jnTqR1QCeMG4L
yJzx6zyCEUJpv2Db4h6iX5s=
=UgNs
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Stuart Herbert]

Is there a concensus out of this thread, on the topic of a distributed
VCS? :)  Preferrably from devs who will actually want overlays? :)

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

Stuart Herbert wrote: [Thu Mar 30 2006, 07:40:47AM EST]
> Is there a concensus out of this thread, on the topic of
> a distributed VCS? :)  Preferrably from devs who will actually want
> overlays? :)

I don't think there's a consensus really, but here's what I'd suggest
based on what people have said:

In a nutshell, all three of darcs, git and mercurial are powerful and
suited to the task.  Darcs is clearly controversial.  It has momentum
because it's already used by the haskell team's overlay.  But its
reliance on ghc, which doesn't work on mips and is a non-system
dependency, means that it's not favored for more general overlays.

I think we might be best to try three revision control systems to
start: darcs, git and subversion.  Three seems like a lot, but each
has its reason, and we can anticipate darcs being used primarily by
the haskell team rather than for overlays in general.

Regarding the question of mercurial vs. git, I previously recommended
mercurial over git.  At this point other devs have made the case for
git, so I'm happy to give it a try.

How does this go over? :-)

Aron
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Stuart Herbert]

Hi Aron,

On 3/30/06, Aron Griffis <agriffis@gentoo.org> wrote:
> I think we might be best to try three revision control systems to
> start: darcs, git and subversion.  Three seems like a lot, but each
> has its reason, and we can anticipate darcs being used primarily by
> the haskell team rather than for overlays in general.

Many thanks for the summary.  I'll find some time to look at how we
can support darcs and git, and I'll post some news when I have some :)

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Fernando J. Pereda]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote:
> Hi Aron,
> 
> On 3/30/06, Aron Griffis <agriffis@gentoo.org> wrote:
> > I think we might be best to try three revision control systems to
> > start: darcs, git and subversion.  Three seems like a lot, but each
> > has its reason, and we can anticipate darcs being used primarily by
> > the haskell team rather than for overlays in general.
> 
> Many thanks for the summary.  I'll find some time to look at how we
> can support darcs and git, and I'll post some news when I have some :)

Feel free to contact me if you need help with Git.

- ferdy

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] overlay support current proposal?

[Duncan Coutts]

On Fri, 2006-03-31 at 10:24 +0200, Fernando J. Pereda wrote:
> On Fri, Mar 31, 2006 at 09:16:17AM +0100, Stuart Herbert wrote:
> > Hi Aron,
> > 
> > On 3/30/06, Aron Griffis <agriffis@gentoo.org> wrote:
> > > I think we might be best to try three revision control systems to
> > > start: darcs, git and subversion.  Three seems like a lot, but each
> > > has its reason, and we can anticipate darcs being used primarily by
> > > the haskell team rather than for overlays in general.
> > 
> > Many thanks for the summary.  I'll find some time to look at how we
> > can support darcs and git, and I'll post some news when I have some :)
> 
> Feel free to contact me if you need help with Git.

And likewise, free to contact me if you need help with Darcs.


Current keyword status of darcs, git and mercurial:

all are ok on alpha, amd64, ppc and x86.
darcs and mercurial are ok on ia64
darcs and git are ok on ppc64 and sparc
git is ok on hppa and mips

hppa should be easy, ghc already works there. We're working on getting
ghc working on mips (it works fine on Irix) but no promises.

-- 
Duncan Coutts : Gentoo Developer (Haskell herd team lead)
email         : dcoutts at gentoo dot org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Nguyễn Thái Ngọc Duy]

On 3/28/06, Patrick McLean <chutzpah@gentoo.org> wrote:
> I think git is probably the best choice, I have played with it a little
> myself and it is _very_ powerful, it also has a very simple dependency
> set (all it's deps are in the Gentoo core system, and are either
> available or installed by default on every *NIX I know of).
I prefer git too. However has anyone tried git with the current tree?
Some practical numbers would be appreciated.
--
Bi Cờ Lao

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Luca Barbato]

Stuart Herbert wrote:
> Thanks for the summary.  I think that's a fair assessment of where we are at.
> 
> The offered software will be trac, svn, and moinmoin.  I'm going to
> look at darcs, and with the help of the haskell team and infra
> determine if we can support it or not.  No-one has expressed a
> preference for a different distributed VCS instead of darcs.
> 

Please consider git and mercurial proxies, maybe nobody proposed it yet
but is relatively easy to provide it and it would be great since gives
you most of the goods from darks w/out the pain related of building it.

lu
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Aron Griffis]

Luca Barbato wrote:  [Sat Mar 25 2006, 05:16:57AM EST]
> Please consider git and mercurial proxies, maybe nobody proposed it
> yet but is relatively easy to provide it and it would be great since
> gives you most of the goods from darks w/out the pain related of
> building it.

Could you point to some references?

Aron
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] overlay support current proposal?

[Luca Barbato]

Aron Griffis wrote:
> Luca Barbato wrote:  [Sat Mar 25 2006, 05:16:57AM EST]
>> Please consider git and mercurial proxies, maybe nobody proposed it
>> yet but is relatively easy to provide it and it would be great since
>> gives you most of the goods from darks w/out the pain related of
>> building it.
> 
> Could you point to some references?
> 
> Aron

sure:

http://www.darcs.net/DarcsWiki/Tailor

http://www.selenic.com/mercurial/wiki/index.cgi/ConvertingRepositories

http://darcs.net/DarcsWiki/DarcsGit

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list