[gentoo-dev] Brainstorming how to collaboratively work on kernels

[gentoo-dev] Brainstorming how to collaboratively work on kernels

[Brian Jackson]

So one of my big goals for my time as kernel tlp manager is to come up with a 
way to have more than one person responsible for each Gentoo kernel. It's 
been to the point in the past where a Gentoo kernel wasn't actively 
maintained. That shouldn't happen in a project this size. I've finally gotten 
some more kernel devs coming on board, so now all I have to do is come up 
with a way to allow them to do their jobs.

The main problem is I can't come up with a way to handle this well.

We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel 
trees would introduce. Subversion isn't an option (and I'd assume that arch, 
and others isn't either).

So, I come to you to help me brainstorm. Any good ideas, let me know.

--Iggy

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Chris Gianelloni]

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

On Sat, 2004-01-24 at 19:36, Brian Jackson wrote:
> So one of my big goals for my time as kernel tlp manager is to come up with a 
> way to have more than one person responsible for each Gentoo kernel. It's 
> been to the point in the past where a Gentoo kernel wasn't actively 
> maintained. That shouldn't happen in a project this size. I've finally gotten 
> some more kernel devs coming on board, so now all I have to do is come up 
> with a way to allow them to do their jobs.
> 
> The main problem is I can't come up with a way to handle this well.
> 
> We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel 
> trees would introduce. Subversion isn't an option (and I'd assume that arch, 
> and others isn't either).
> 
> So, I come to you to help me brainstorm. Any good ideas, let me know.

How much abuse do you think it would honestly be?  Would it be worth
setting up a kernel.gentoo.org cvs repository just for you guys?  I tend
to think that the kernels are a very important item for Gentoo, and
something you probably hear the most complaining about when they fall
even the slightest bit behind in version.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a pengiun?

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Robin H. Johnson]

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

On Sat, Jan 24, 2004 at 06:36:39PM -0600, Brian Jackson wrote:
> We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel 
> trees would introduce. Subversion isn't an option (and I'd assume that arch, 
> and others isn't either).
What about BK?
BK works much better than CVS/Subversion for kernels, and don't see any
major reasons not to use it.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Jon Portnoy]

On Sat, Jan 24, 2004 at 07:11:26PM -0800, Robin H. Johnson wrote:
> On Sat, Jan 24, 2004 at 06:36:39PM -0600, Brian Jackson wrote:
> > We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel 
> > trees would introduce. Subversion isn't an option (and I'd assume that arch, 
> > and others isn't either).
> What about BK?
> BK works much better than CVS/Subversion for kernels, and don't see any
> major reasons not to use it.
> 

The major reason not to use it is that it would rip apart the project.

A significant number of devs and users would be fairly likely to depart 
if we were relying on bitkeeper. The license terms are _highly_ 
authoritarian and controversial. I refuse to deal with the mess (and 
nasty PR) it would leave, personally.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Robin H. Johnson]

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

On Sat, Jan 24, 2004 at 10:15:26PM -0500, Jon Portnoy wrote:
> A significant number of devs and users would be fairly likely to depart 
> if we were relying on bitkeeper. The license terms are _highly_ 
> authoritarian and controversial. I refuse to deal with the mess (and 
> nasty PR) it would leave, personally.
I'm suggesting BK only for keeping the kernel trees managable. Users
will not see them in any form as they will only ever be downloading
tarballs/patches from the gentoo mirrors.

The upstream linux kernel itself is already in BK, so the point of users
caring about something coming from BK isn't really valid. If the
developers working on the kernel have no objections to trying BK, it
could at least be given a chance for testing.

The only really nasty license terms are 3.d. and 3.e. (which are
basically that you can't develop a competitor to BK and use BK).

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Jon Portnoy]

On Sat, Jan 24, 2004 at 07:49:27PM -0800, Robin H. Johnson wrote:
> On Sat, Jan 24, 2004 at 10:15:26PM -0500, Jon Portnoy wrote:
> > A significant number of devs and users would be fairly likely to depart 
> > if we were relying on bitkeeper. The license terms are _highly_ 
> > authoritarian and controversial. I refuse to deal with the mess (and 
> > nasty PR) it would leave, personally.
> I'm suggesting BK only for keeping the kernel trees managable. Users
> will not see them in any form as they will only ever be downloading
> tarballs/patches from the gentoo mirrors.
> 

Users don't have to see the mainline kernel in BK, either, but there's 
still a BK flamewar there every two months or so.

> The upstream linux kernel itself is already in BK, so the point of users
> caring about something coming from BK isn't really valid. If the
> developers working on the kernel have no objections to trying BK, it
> could at least be given a chance for testing.

Sure it is. Check the lkml archives.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[tom_gall]

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


On Saturday, January 24, 2004, at 09:15 PM, Jon Portnoy wrote:

> On Sat, Jan 24, 2004 at 07:11:26PM -0800, Robin H. Johnson wrote:
>> What about BK?
>> BK works much better than CVS/Subversion for kernels, and don't see 
>> any
>> major reasons not to use it.
>>
>
> The major reason not to use it is that it would rip apart the project.
>
> A significant number of devs and users would be fairly likely to depart
> if we were relying on bitkeeper. The license terms are _highly_
> authoritarian and controversial. I refuse to deal with the mess (and
> nasty PR) it would leave, personally.

For instance, if you work for a company that sells products that compete
with bitmover ... you must purchase a bk license which is several 
thousand
USD.

It doesn't matter if you don't personally work on it, it doesn't matter 
if you
in your own time work on open source software. Heck if you work on CVS
you can't use bk without buying a license.

bk is nice in some respects, but personally I think cvs could and should
be actively worked on to add function that even subversion and bk
doesn't have.

As an example I think it would be quite handy to have n branches in a 
cvs
tree but allow for "common" changes to pushed across a set of branches 
all
at once in a single commit.   Or allow for a patch to start in one 
branch but
then allow a developer to push the patch to other branches but marked
as experimental. So a normal cvs co / update of that branch it was 
pushed
to would not get the patch BUT a maintainer / developer type could
get a list of these pending 'experimental' patches, selectively apply 
them
and then "promote" them so they are commited to the branch so a
cvs co -r thatbranch  would then have that "promoted" patch, otherwise
to get the experimental pending patches one would have to do something
like cvs co -r thatbranch --experimental.

Call me crazy but I think cvs needs some lovin'.

Tom Gall
gentoo -- God started with stage 1, shouldn't you?
tgall aatt uberh4x0r.org
tom_gall aatt mac.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFAE0IeNM6ZoaBWhQkRAgcKAJ9yki/OfbeZKOaw1AfPgZfe20qx5ACeKNWc
Bgda6HL/YN5gjYWmOz2Qb1U=
=R6/f
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Matthew Kennedy]

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

tom_gall@mac.com writes:

[...]

> It doesn't matter if you don't personally work on it, it doesn't
> matter if you in your own time work on open source software. Heck if
> you work on CVS you can't use bk without buying a license.

What does "work on CVS" mean exactly? If you're maintaining a port of
CVS/Arch/RCS/Subversion/etc. in Portage, does that qualify?  It seems
it would.

Matt
-- 
Matthew Kennedy
Gentoo Linux Developer

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Andrew P. Lentvorski, Jr.]

On Sat, 24 Jan 2004, Brian Jackson wrote:

> We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel
> trees would introduce. Subversion isn't an option (and I'd assume that arch,
> and others isn't either).

Once you decide to dump CVS, backward compability and user familiarity are
removed as relevant problems.  What are the other obstacles to using
Subversion or arch?

At the very least, consider Perforce before Bitkeeper.  Several of the
FreeBSD developers seem to use Perforce behind the scenes, and it hasn't
seemed to provoke even a fraction of the animosity that Bitkeeper does.

-a

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Jon Portnoy]

On Sun, Jan 25, 2004 at 03:33:57AM -0600, Matthew Kennedy wrote:
> tom_gall@mac.com writes:
> 
> [...]
> 
> > It doesn't matter if you don't personally work on it, it doesn't
> > matter if you in your own time work on open source software. Heck if
> > you work on CVS you can't use bk without buying a license.
> 
> What does "work on CVS" mean exactly? If you're maintaining a port of
> CVS/Arch/RCS/Subversion/etc. in Portage, does that qualify?  It seems
> it would.
> 

Considering that so much as making a suggestion about different phrasing 
in documentation qualifies according to McVoy, I bet it would.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Matthew Kennedy]

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

"Andrew P. Lentvorski, Jr." <bsder@allcaps.org> writes:

[...]

> At the very least, consider Perforce before Bitkeeper.  Several of the
> FreeBSD developers seem to use Perforce behind the scenes, and it hasn't
> seemed to provoke even a fraction of the animosity that Bitkeeper does.


    "Gentoo Linux will never depend upon a piece of software unless it
    conforms to the GNU General Public License, GNU Lesser General
    Public License or some other license approved by the Open Source
    Initiative (OSI.)" -- http://www.gentoo.org/main/en/contract.xml

I think we can cross Preforce/Bitkeeper off the list based on that.

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[James Harlow]

>     "Gentoo Linux will never depend upon a piece of software unless it
>     conforms to the GNU General Public License, GNU Lesser General
>     Public License or some other license approved by the Open Source
>     Initiative (OSI.)" -- http://www.gentoo.org/main/en/contract.xml
> 
> I think we can cross Preforce/Bitkeeper off the list based on that.

Both p4 and BK can export to open-source formats, like CVS. The fact 
that some kernel developers (like linus) use bk, and other developers 
don't have to, suggests that Gentoo could do the same thing.

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Jon Portnoy]

On Sun, Jan 25, 2004 at 02:41:42PM -0600, Matthew Kennedy wrote:
> "Andrew P. Lentvorski, Jr." <bsder@allcaps.org> writes:
> 
> [...]
> 
> > At the very least, consider Perforce before Bitkeeper.  Several of the
> > FreeBSD developers seem to use Perforce behind the scenes, and it hasn't
> > seemed to provoke even a fraction of the animosity that Bitkeeper does.
> 
> 
>     "Gentoo Linux will never depend upon a piece of software unless it
>     conforms to the GNU General Public License, GNU Lesser General
>     Public License or some other license approved by the Open Source
>     Initiative (OSI.)" -- http://www.gentoo.org/main/en/contract.xml
> 
> I think we can cross Preforce/Bitkeeper off the list based on that.
> 
> Matt
> 

I agree.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Marius Mauch]

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

On 01/25/04  James Harlow wrote:

> >     "Gentoo Linux will never depend upon a piece of software unless
> >     it conforms to the GNU General Public License, GNU Lesser
> >     General Public License or some other license approved by the
> >     Open Source Initiative (OSI.)" --
> >     http://www.gentoo.org/main/en/contract.xml
> > 
> > I think we can cross Preforce/Bitkeeper off the list based on that.
> 
> Both p4 and BK can export to open-source formats, like CVS. The fact 
> that some kernel developers (like linus) use bk, and other developers 
> don't have to, suggests that Gentoo could do the same thing.

Does the kernel have a social contract ?
I'm not really biased to any of the options, but the discussion about
moving the forums from phpBB to a commercial product should be
considered in the decision as I expect the user reactions will be
simlilar.

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.

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

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Jon Portnoy]

On Sun, Jan 25, 2004 at 11:02:41PM +0100, Marius Mauch wrote:
> On 01/25/04  James Harlow wrote:
> 
> > >     "Gentoo Linux will never depend upon a piece of software unless
> > >     it conforms to the GNU General Public License, GNU Lesser
> > >     General Public License or some other license approved by the
> > >     Open Source Initiative (OSI.)" --
> > >     http://www.gentoo.org/main/en/contract.xml
> > > 
> > > I think we can cross Preforce/Bitkeeper off the list based on that.
> > 
> > Both p4 and BK can export to open-source formats, like CVS. The fact 
> > that some kernel developers (like linus) use bk, and other developers 
> > don't have to, suggests that Gentoo could do the same thing.
> 
> Does the kernel have a social contract ?
> I'm not really biased to any of the options, but the discussion about
> moving the forums from phpBB to a commercial product should be
> considered in the decision as I expect the user reactions will be
> simlilar.
> 
> Marius
> 

I see the forums as relatively peripherial and nonessential when 
compared to the kernel. While Gentoo doesn't, strictly speaking, depend 
on the forums, it does depend on the kernels provided. Managing them 
with a proprietary tool sends a very negative message.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[James Harlow]

On Sun, Jan 25, 2004 at 11:02:41PM +0100, Marius Mauch wrote:
> > Both p4 and BK can export to open-source formats, like CVS. The fact 
> > that some kernel developers (like linus) use bk, and other developers 
> > don't have to, suggests that Gentoo could do the same thing.
> 
> Does the kernel have a social contract ?

I'm not sure how this is relevant - my point is that if BK disappeared
tomorrow, no source would be lost, and the kernel source (the "product")
wouldn't have to be changed. Contrast that with, for example, if RedHat
built its packages with ICC - if ICC was to disappear tomorrow, RedHat
would certainly have to change their packages next time they rebuilt -
thus, they would have been dependent on it.

Personally, I think the social contract is desperately ambiguous, and
I'd like to see "depend upon" changed to "use", but I don't think that
(as it stands) the kernel developers using BK but exporting CVS is
contrary to it.

If I write ebuilds with TextPad, is that a breach of the SC?

-- 
When a true genius appears in the world, you may know him by this sign, that the dunces are all in confederacy against him. - Jonathan Swift

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Issues with using Subversion or arch for kernel development

[Andrew P. Lentvorski, Jr.]

On Sun, 25 Jan 2004, Andrew P. Lentvorski, Jr. wrote:

> On Sat, 24 Jan 2004, Brian Jackson wrote:
>
> > We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel
> > trees would introduce. Subversion isn't an option (and I'd assume that arch,
> > and others isn't either).
>
> Once you decide to dump CVS, backward compability and user familiarity are
> removed as relevant problems.  What are the other obstacles to using
> Subversion or arch?

I really am interested in seeing the technical merits and failures of some
of the systems discussed without reference to the political issues.

What are the failures of Subversion and/or arch?

To my mind, the web server dependency of subversion was a negative because
I was always dealing with small projects.  However, I could see where
bundling this stuff up into a webserver could be a bonus for a large
project who already maintains their own web server.

arch used to have the problem of some absolutely abysmal performance
because it was just a bunch of shell scripts.  However, it has evolved
quite a bit and had some C code rewrites.  What other issues are there
with using it?

-a


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Kevyn Shortell]

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

On Sun, 2004-01-25 at 14:12, Jon Portnoy wrote:
> 
> I see the forums as relatively peripherial and nonessential when 
> compared to the kernel. While Gentoo doesn't, strictly speaking, depend 
> on the forums, it does depend on the kernels provided. Managing them 
> with a proprietary tool sends a very negative message.

While I agree it just seems rather amusing to see people complaining
about managing the kernel with a tool, that the Linus and other linux
kernel developers are using to manage the kernel src. =)

trance
-- 
trance @ irc.freenode.net #gentoo-ppc
Kevyn Shortell <trance@gentoo.org>
Gentoo PPC Operational Manager / PPC dev

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

Re: [gentoo-dev] Issues with using Subversion or arch for kernel development

[Ævar Arnfjörð Bjarmason]

Andrew P. Lentvorski, Jr. wrote:
> On Sun, 25 Jan 2004, Andrew P. Lentvorski, Jr. wrote:
> 
> 
>>On Sat, 24 Jan 2004, Brian Jackson wrote:
>>
>>
>>>We can't really subject cvs.gentoo.org to the kind of abuse that 5 kernel
>>>trees would introduce. Subversion isn't an option (and I'd assume that arch,
>>>and others isn't either).
>>
>>Once you decide to dump CVS, backward compability and user familiarity are
>>removed as relevant problems.  What are the other obstacles to using
>>Subversion or arch?
> 
> 
> I really am interested in seeing the technical merits and failures of some
> of the systems discussed without reference to the political issues.
> 
> What are the failures of Subversion and/or arch?

svn: a bit slower is the only argument i've found against it (use it myself) 
and of course "it isnt CVS"

> To my mind, the web server dependency of subversion was a negative because
> I was always dealing with small projects.  However, I could see where
> bundling this stuff up into a webserver could be a bonus for a large
> project who already maintains their own web server.

Subversion DOES NOT, have a webserver dependency, alot of people think this is 
true and vote against it based on that (actually the webserver arrangement 
totally kicks ass) but if you dont like it just use what you currently use with 
  CVS, subversion over ssh or svn+ssh:// not http(s)://, you can even use the 
standalone svnd but you are far fron required to do so, its optional but nobody 
says you have to, the reson most people do it because its simply the best way 
to do it.

> arch used to have the problem of some absolutely abysmal performance
> because it was just a bunch of shell scripts.  However, it has evolved
> quite a bit and had some C code rewrites.  What other issues are there
> with using it?
> 
> -a
> 
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Issues with using Subversion or arch for kernel development

[Brian Jackson]

On Sunday 25 January 2004 07:00 pm, Andrew P. Lentvorski, Jr. wrote:
> On Sun, 25 Jan 2004, Andrew P. Lentvorski, Jr. wrote:
> > On Sat, 24 Jan 2004, Brian Jackson wrote:
> > > We can't really subject cvs.gentoo.org to the kind of abuse that 5
> > > kernel trees would introduce. Subversion isn't an option (and I'd
> > > assume that arch, and others isn't either).
> >
> > Once you decide to dump CVS, backward compability and user familiarity
> > are removed as relevant problems.  What are the other obstacles to using
> > Subversion or arch?
>
> I really am interested in seeing the technical merits and failures of some
> of the systems discussed without reference to the political issues.
>
> What are the failures of Subversion and/or arch?

Not really any failures keeping it from being considered. The infrastructure 
team wants to support cvs and only cvs.

>
> To my mind, the web server dependency of subversion was a negative because
> I was always dealing with small projects.  However, I could see where
> bundling this stuff up into a webserver could be a bonus for a large
> project who already maintains their own web server.

That isn't a dependency any longer, you don't even need to run any extra 
service to use it. It can work perfectly well with just ssh.

>
> arch used to have the problem of some absolutely abysmal performance
> because it was just a bunch of shell scripts.  However, it has evolved
> quite a bit and had some C code rewrites.  What other issues are there
> with using it?

I tried playing with arch when I first started toying with this idea. I didn't 
get very far, mostly because I couldn't find any good docs, and it's a 
complicated piece of software.

--Iggy

>
> -a

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Issues with using Subversion or arch for kernel development

[Andrew Cowie]

On Mon, 2004-01-26 at 12:00, Andrew P. Lentvorski, Jr. wrote:
> To my mind, the web server dependency of subversion

Does not exist. 

*One* way you can use it is by accessing the repository through a web
server (http:// and https://) - which makes all the network access stuff
virtually transparent. 

But an equally valid way of accessing a subversion repository is via
their internal protocol (svn://), which can be seamlessly and
effortlessly tunnelled over ssh (svn+ssh://). Or you can neglect a
network layer entirely and just use a repository local to your project
(file://)

The ebuild does more or less assume you're building it to have the
http[s] capability, and so it becomes fairly complex, but there's
nothing that says you have to go that way.

Read for yourself:

http://svnbook.red-bean.com/

AfC

-- 
Andrew Frederick Cowie
Operational Dynamics Consulting Pty Ltd

Australia: +61 2 9977 6866  North America: +1 646 472 5054

http://www.operationaldynamics.com/

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Brainstorming how to collaboratively work on kernels

[Grant Goodyear]

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

> Once you decide to dump CVS, backward compability and user familiarity are
> removed as relevant problems.  What are the other obstacles to using
> Subversion or arch

The last time we seriously tested svn we found that svn choked on a
repository the size of the portage tree.  The problem w/ arch (and w/
metacvs, which would be my preference), is that neither system has a
good migration utility from cvs.  The history of changes that is kept in
our cvs tree is extremely valuable, and thus any new system that does
not allow us to keep that history is a non-starter.

-g2boojum-
-- 
Grant Goodyear <g2boojum@gentoo.org>

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

[gentoo-dev] Re: Brainstorming how to collaboratively work on kernels

[Denys Duchier]

Grant Goodyear <g2boojum@gentoo.org> writes:

> The last time we seriously tested svn we found that svn choked on a
> repository the size of the portage tree.  The problem w/ arch (and w/
> metacvs, which would be my preference), is that neither system has a
> good migration utility from cvs.  The history of changes that is kept in
> our cvs tree is extremely valuable, and thus any new system that does
> not allow us to keep that history is a non-starter.

arch has cscvs to migrate the full history stored in a CVS archive to
an arch (changeset-based) archive.

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Issues with using Subversion or arch for kernel development

[Kurt Lieber]

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

On Sun, Jan 25, 2004 at 07:21:16PM -0600 or thereabouts, Brian Jackson wrote:
> Not really any failures keeping it from being considered. The infrastructure 
> team wants to support cvs and only cvs.

Not entirely accurate.  If there are compelling reasons to use another
solution instead of CVS, we are certainly willing to look at other
solutions.  "Because I like it better" or "because it works better for me"
is generally not a good reason.

We would prefer to support only one version control system, be it CVS,
BitKeeper, Subversion or whatever.  We don't really have the resources,
time or inclination to support multiple version control systems.  If there
are strong, clearly articulated reasons why Gentoo, as a project, cannot
progress without supporting multiple version control systems, then we're
certainly willing to look at that, too.

Anyone developer wishing to change over to a new system should probably
start with a GLEP.

--kurt

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

Re: [gentoo-dev] Re: Brainstorming how to collaboratively work on kernels

[Luca Barbato]

Denys Duchier wrote:
> Grant Goodyear <g2boojum@gentoo.org> writes:
> 
> 
>>The last time we seriously tested svn we found that svn choked on a
>>repository the size of the portage tree.  The problem w/ arch (and w/
>>metacvs, which would be my preference), is that neither system has a
>>good migration utility from cvs.  The history of changes that is kept in
>>our cvs tree is extremely valuable, and thus any new system that does
>>not allow us to keep that history is a non-starter.
> 
> 
> arch has cscvs to migrate the full history stored in a CVS archive to
> an arch (changeset-based) archive.
> 
> Cheers,
> 
I found

http://wiki.sourcecontrol.net/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree

something that may be interesting if we want move to use arch/tla.

lu

-- 
Luca Barbato
Developer
Gentoo Linux				http://www.gentoo.org/~lu_zero



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Issues with using Subversion or arch for kernel development

[Paul de Vrieze]

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

On Monday 26 January 2004 02:00, Andrew P. Lentvorski, Jr. wrote:
>
> What are the failures of Subversion and/or arch?

Subversion is in general not really good with really big repositories like the 
portage tree. Checking in an out a whole tree takes too much time for 
example, and there are wories (not researched) about whether it will allow 
concurrent access (concurrent read access is no problem). In general 
subversion is not ready to support the portage tree in our point.

> To my mind, the web server dependency of subversion was a negative because
> I was always dealing with small projects.  However, I could see where
> bundling this stuff up into a webserver could be a bonus for a large
> project who already maintains their own web server.

You don't need to use it, but it is great if you have to deal with braindead 
admins that only let you use internet through a proxy because that would be 
safer. (As if I can't sent everything I want over CONNECT)

Paul

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

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