[gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Thilo Bangert]

robbat2 wrote:
> Donnie had a list of everybody that's been interested in the subject,
> and I've subscribed all of you.

well - count me in.

it appears drobbins has beat us wrt providing portage as a git tree. no 
history though...
http://blog.funtoo.org/2008/09/more-git-madness.html

personally, i dont see the necessity of providing all of our cvs history 
in a git repo, but then again i am not much opposed to the idea either.

robin: did you have the CVS master files laying around somewhere? 

are there any other serious candidates apart from git?

speak up!
thanks
Thilo

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Robin H. Johnson]

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

On Wed, Oct 01, 2008 at 10:57:13PM +0200, Thilo Bangert wrote:
> personally, i dont see the necessity of providing all of our cvs history 
> in a git repo, but then again i am not much opposed to the idea either.
The main reason for having having is being able to review old content
without having to look at two systems, which also means that we'd have
to keep the old CVS tree around and live still.

> robin: did you have the CVS master files laying around somewhere? 
What do you mean by master? If you want all of the ,v files, look at the
bottom of http://anoncvs.gentoo.org/.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

[gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Thilo Bangert]

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

dberkholz wrote:
> > 4.
> > Doing more test migrations, and having a test-plan for comparing them
> > directly, as well as against other SCMs.

> The OpenSolaris link above is quite useful for comparisons, and the 
> "Repository Formats Matter" post from Keith Packard is helpful for 
> understanding one good reason why git might be the best choice.

reading "Repository Formats Matter" again, finally made me try git a 
little more thoroughly. but honestly - all i care about, is that we 
switch away from CVS. no other VCS is that bad...

> Same as above, what are our requirements and what doesn't matter? Here's 
> the OpenSolaris list: 
> http://opensolaris.org/os/community/tools/scm/dscmreqdoc/

> Important
>  - Fast branching (This will make it possible for new styles of 
>    development in Gentoo.)
>  - Fast committing (This will encourage more atomic commits from a 
>    functional POV.)
>  - Reliable (Repository format & committing process guarantee no
>    corruption.)
>  - Usability (This can be either discoverable or through good 
>    documention, found elsewhere or produced by us.)
>  - Modifiable (Written in a reasonably common language. Read: Python, C 
>    or shell. git and bzr qualify, darcs doesn't.)
>  - Active upstream (Getting modifications into upstream code, 
>    requesting features)
>  - Hooks (Implement custom checks upon commit to your or main 
>    repository.)
>
> Optional
>  - Partial checkouts. They aren't useful enough to be a requirement, in 
>    my view, because I have yet to hear a good reason they're needed. A 
>    gig or two of disk space is cheap.
>  - Integration into popular text editors
>  - CVS gateway (people can still commit using CVS)
>  - Shallow checkouts (Only getting partial history to reduce size. git 
>    supports grafting two repositories together, not sure about other 
>    SCMs. Not sure how to do the initial splice. Explore 
>    'git-filter-branch'?)

AFAICT git fits the bill for all important and most optional points. 

> Another point I'd like to get into is how we should architect this. 
> Should we stick with the single repository for the whole thing, or 
> should we break it down so that each package has its own repository? If 
> we go with the latter, we need to figure out a way to easily check out & 
> update the whole repo.

thinking about repository changes may drag the conversion to another VCS 
out indefintively. for that reason we should limit our selves to 
currently just picking a new VCS and then later discuss the changes we 
may want to do to the repository layout (the ebuild dir comes to mind)...

..but lets get the ball rolling. drobbins is already publishing a git tree 
and we should make sure we dont get overtaken from left AND right... :)

best regards
Thilo

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Alec Warner]

On Sun, Oct 5, 2008 at 2:59 PM, Thilo Bangert <bangert@gentoo.org> wrote:
> dberkholz wrote:
>> > 4.
>> > Doing more test migrations, and having a test-plan for comparing them
>> > directly, as well as against other SCMs.
>
>> The OpenSolaris link above is quite useful for comparisons, and the
>> "Repository Formats Matter" post from Keith Packard is helpful for
>> understanding one good reason why git might be the best choice.
>
> reading "Repository Formats Matter" again, finally made me try git a
> little more thoroughly. but honestly - all i care about, is that we
> switch away from CVS. no other VCS is that bad...
>
>> Same as above, what are our requirements and what doesn't matter? Here's
>> the OpenSolaris list:
>> http://opensolaris.org/os/community/tools/scm/dscmreqdoc/
>
>> Important
>>  - Fast branching (This will make it possible for new styles of
>>    development in Gentoo.)
>>  - Fast committing (This will encourage more atomic commits from a
>>    functional POV.)
>>  - Reliable (Repository format & committing process guarantee no
>>    corruption.)
>>  - Usability (This can be either discoverable or through good
>>    documention, found elsewhere or produced by us.)
>>  - Modifiable (Written in a reasonably common language. Read: Python, C
>>    or shell. git and bzr qualify, darcs doesn't.)
>>  - Active upstream (Getting modifications into upstream code,
>>    requesting features)
>>  - Hooks (Implement custom checks upon commit to your or main
>>    repository.)
>>
>> Optional
>>  - Partial checkouts. They aren't useful enough to be a requirement, in
>>    my view, because I have yet to hear a good reason they're needed. A
>>    gig or two of disk space is cheap.
>>  - Integration into popular text editors
>>  - CVS gateway (people can still commit using CVS)
>>  - Shallow checkouts (Only getting partial history to reduce size. git
>>    supports grafting two repositories together, not sure about other
>>    SCMs. Not sure how to do the initial splice. Explore
>>    'git-filter-branch'?)
>
> AFAICT git fits the bill for all important and most optional points.
>
>> Another point I'd like to get into is how we should architect this.
>> Should we stick with the single repository for the whole thing, or
>> should we break it down so that each package has its own repository? If
>> we go with the latter, we need to figure out a way to easily check out &
>> update the whole repo.
>
> thinking about repository changes may drag the conversion to another VCS
> out indefintively. for that reason we should limit our selves to
> currently just picking a new VCS and then later discuss the changes we
> may want to do to the repository layout (the ebuild dir comes to mind)...

Except some VCS are more usable with different repo layouts; how do
you intend to reconcile these differences?

>
> ..but lets get the ball rolling. drobbins is already publishing a git tree
> and we should make sure we dont get overtaken from left AND right... :)
>
> best regards
> Thilo
>

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Thilo Bangert]

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

"Alec Warner" <antarus@gentoo.org> said:
> Except some VCS are more usable with different repo layouts; how do
> you intend to reconcile these differences?

we dont. having a decent VCS now is infinitly more valuable than spending 
2 years discussing the perfect repo layout. also, switching to a 
decentralised VCS may/will spawn modes of operation that we dont even 
know about yet, possibly making the so thoughtful established repo layout 
changes obsolete faster than the time it took to come up with them.

i am not opposed to the idea of layout changes; its just not my personal 
itch (right now). and quite frankly - i dont see anybody else here, whose 
itch it is...

our current VCS is inhibiting development and innovation. our repo layout 
is not!

absolute worst case is, that we switch again. though that is a risk we 
still encounter if we do repo layout changes now. 

best regards
Thilo

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Alec Warner]

On Mon, Oct 6, 2008 at 2:50 AM, Thilo Bangert <bangert@gentoo.org> wrote:
> "Alec Warner" <antarus@gentoo.org> said:
>> Except some VCS are more usable with different repo layouts; how do
>> you intend to reconcile these differences?
>
> we dont. having a decent VCS now is infinitly more valuable than spending
> 2 years discussing the perfect repo layout. also, switching to a
> decentralised VCS may/will spawn modes of operation that we dont even
> know about yet, possibly making the so thoughtful established repo layout
> changes obsolete faster than the time it took to come up with them.
>
> i am not opposed to the idea of layout changes; its just not my personal
> itch (right now). and quite frankly - i dont see anybody else here, whose
> itch it is...

It is mine ;)

>
> our current VCS is inhibiting development and innovation. our repo layout
> is not!

I would say it is (exherbo is a half-decent example of something I
think is better).

>
> absolute worst case is, that we switch again. though that is a risk we
> still encounter if we do repo layout changes now.

True.

>
> best regards
> Thilo
>

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Ryan Hill]

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

On Mon, 6 Oct 2008 08:41:43 -0700
"Alec Warner" <antarus@gentoo.org> wrote:

> On Mon, Oct 6, 2008 at 2:50 AM, Thilo Bangert <bangert@gentoo.org>
> wrote:
> > i am not opposed to the idea of layout changes; its just not my
> > personal itch (right now). and quite frankly - i dont see anybody
> > else here, whose itch it is...
> 
> It is mine ;)

* Raises hand *

Probably the best, if only, time we could make major changes to the
tree structure without major disruption would be during a VCS change.


-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Robert Buchholz]

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

On Monday 06 October 2008, Alec Warner wrote:
> On Mon, Oct 6, 2008 at 2:50 AM, Thilo Bangert <bangert@gentoo.org> 
wrote:
> > i am not opposed to the idea of layout changes; its just not my
> > personal itch (right now). and quite frankly - i dont see anybody
> > else here, whose itch it is...
>
> It is mine ;)
>
> > our current VCS is inhibiting development and innovation. our repo
> > layout is not!
>
> I would say it is (exherbo is a half-decent example of something I
> think is better).

What problems are we trying to solve?
Why is the exherbo approach better?

More specific questions:
* How fine-grained do you want the repositories to be?
* Who controls access?
* How is QA being done?
* Who defines what is "officially supported"
  (right now it is "in the tree, not p.masked")
* What about global data (the non-cache files in metadata, eclasses)?

Robert

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Ciaran McCreesh]

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

On Mon, 6 Oct 2008 19:10:58 +0200
Robert Buchholz <rbu@gentoo.org> wrote:
> > > our current VCS is inhibiting development and innovation. our repo
> > > layout is not!
> >
> > I would say it is (exherbo is a half-decent example of something I
> > think is better).
> 
> What problems are we trying to solve?
> Why is the exherbo approach better?

The Exherbo approach relies upon the package manager being good at
dealing with larger numbers of interdependent repositories. Unless
you've got a way of making Portage support things like repository deps,
unavailable-format repositories [1] and multiple repositories with
multiple dependencies, switching is going to make things pretty much
unusable for anyone using Portage...

[1]: http://ciaranm.wordpress.com/2008/06/12/dealing-with-lots-of-repositories/

-- 
Ciaran McCreesh

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

[gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Thilo Bangert]

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

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> said:
> On Mon, 6 Oct 2008 19:10:58 +0200
>
> Robert Buchholz <rbu@gentoo.org> wrote:
> > > > our current VCS is inhibiting development and innovation. our
> > > > repo layout is not!
> > >
> > > I would say it is (exherbo is a half-decent example of something I
> > > think is better).
> >
> > What problems are we trying to solve?
> > Why is the exherbo approach better?
>
> The Exherbo approach relies upon the package manager being good at
> dealing with larger numbers of interdependent repositories. Unless
> you've got a way of making Portage support things like repository deps,
> unavailable-format repositories [1] and multiple repositories with
> multiple dependencies, switching is going to make things pretty much
> unusable for anyone using Portage...

which is a perfect example for why the repo layout discussion should not 
be dragged into this. lets switch to something better now (a better VCS) 
and then to something even better (a nicer repo layout) afterwards. if we 
take up the repo layout discussion we will be going nowhere...

yes - i want pink ponies too. but for now, i'll settle for purple ones...

> [1]:
> http://ciaranm.wordpress.com/2008/06/12/dealing-with-lots-of-repositori
>es/

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Thilo Bangert]

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

Ryan Hill <dirtyepic@gentoo.org> said:
> On Mon, 6 Oct 2008 08:41:43 -0700
>
> "Alec Warner" <antarus@gentoo.org> wrote:
> > On Mon, Oct 6, 2008 at 2:50 AM, Thilo Bangert <bangert@gentoo.org>
> >
> > wrote:
> > > i am not opposed to the idea of layout changes; its just not my
> > > personal itch (right now). and quite frankly - i dont see anybody
> > > else here, whose itch it is...
> >
> > It is mine ;)
>
> * Raises hand *
>

thats great. i guess, in some perverse way that makes it my itch then as 
well.

> Probably the best, if only, time we could make major changes to the
> tree structure without major disruption would be during a VCS change.

you dont give any arguments, so we'll have to take your word on it. 

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

Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS

[Alec Warner]

On Mon, Oct 6, 2008 at 10:10 AM, Robert Buchholz <rbu@gentoo.org> wrote:
> On Monday 06 October 2008, Alec Warner wrote:
>> On Mon, Oct 6, 2008 at 2:50 AM, Thilo Bangert <bangert@gentoo.org>
> wrote:
>> > i am not opposed to the idea of layout changes; its just not my
>> > personal itch (right now). and quite frankly - i dont see anybody
>> > else here, whose itch it is...
>>
>> It is mine ;)
>>
>> > our current VCS is inhibiting development and innovation. our repo
>> > layout is not!
>>
>> I would say it is (exherbo is a half-decent example of something I
>> think is better).
>
> What problems are we trying to solve?

1) People commiting things into a shared space that are not widely utilized.
2) People commiting personal ebuilds into a shared space because it is
easier to use (syncs by default; no overlays).  2 is a specific subset
of 1; but 2 really pisses me off (moreso because I have done it and
felt shitty afterward).
3) People commiting things into a shared space that they have no real
intention of maintaining.

> Why is the exherbo approach better?

Mostly they are good at telling people to fuck off.  I like that.
I think a tree with 13000 packages in it is less useful when only a
small percentage are maintained well.

If you want poorly maintained ebuilds you can look to the community
for that often enough.

>
> More specific questions:
> * How fine-grained do you want the repositories to be?

I expect this to evolve over time.

> * Who controls access?

In one proposal; Gentoo.  Gentoo-x86 would be a combination of a
number of smaller repositories.  Anything in gentoo-x86 would be
'officially supported.'  Running QA tests on the smaller repositories
presents a problem as well as cross-repo dependencies (most developers
would need the repositories for their deps installed.  I cannot say
that this is a very good approach but it avoids the whole 'portage
doesn't have repository support' argument.

In another proposal; Gentoo.  Gentoo-x86 would be one of many
repositories and the package manager would provide management
capability.  Repositories provided by default by gentoo would be
'officially supported' in this scheme.

> * How is QA being done?

repoman?  gentoo-commits?  I would imagine similar to now.

> * Who defines what is "officially supported"
>  (right now it is "in the tree, not p.masked")

See the above.

> * What about global data (the non-cache files in metadata, eclasses)?

In the former scheme it would need to be shared across all repos that
are being integrated into gentoo-x86 (possibly its own repo for
profiles/).

In the other scheme each repo would be on its own (mucho duplication).

>
> Robert
>