Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: SCM choices
Date: Tue, 03 Apr 2007 14:14:01
Message-Id: 1175609463.8202.29.camel@inertia.twi-31o2.org
In Reply to: [gentoo-dev] Re: SCM choices by "Marijn Schouten (hkBst)"
1 On Sat, 2007-03-31 at 11:52 +0200, Marijn Schouten (hkBst) wrote:
2 > So in light of all that I don't think it is wasteful to restart this discussion.
3
4 I do.
5
6 Want to bring it back up? Go perform some tests and report back with
7 some data if you feel prior efforts weren't done properly or
8 reproducible. My *entire* point was that *discussion* of this issue is
9 worthless compared to numbers and data. I see no need to hear 300+
10 people tell everyone else their *opinion* on what they *think* is
11 better. Seeing some actual data, though, should be definitely
12 encouraged.
13
14 > 1) get commit access to the repository and start a branch in there. Merging may not be too hard, I
15 > don't really know. However CVS commit access is not something that is given lightly. It would vice
16 > versa also mean that you would have commit access to my stuff, which I might not like.
17
18 Release Engineering has its own space for officially-released and
19 in-progress media. Your stuff wouldn't really fall under that category,
20 so there's no need for you to have commit access to the repository.
21 Release Engineering holds final say on all changes and they need to go
22 through Release Engineering for testing before they will be accepted.
23 This is how all of our changes work and it's worked pretty well for us.
24
25 > 2) file bugs with patches attached. But maybe you just want to forget about releases until 2007.1
26 > comes along once 2007.0 is finished.
27
28 You are correct. Release Engineering is not concerned with the interim
29 state of the tree, and therefore has no need for constantly updating the
30 spec files. We focus our attention on the release snapshots and make
31 changes based on said snapshot, not on the current state of the tree.
32 We all have better things we would like to do than constantly update
33 spec files. Now, if you're talking about working with Release
34 Engineering during release times, that would be grand, but anything
35 off-cycle wouldn't be of much interest for us. Also, remember that
36 there's really no point in refreshing media on a constant basis. I
37 could see refreshing it after a new kernel version goes stable, and
38 that's about it. Anything else seems like a terrible waste of time and
39 resources for minimal gain. In most cases, your CD wouldn't change at
40 all from day to day. For QA purposes, I run builds year-round. I just
41 don't release them because I don't test them thoroughly.
42
43 > 3) fork the code or convert the repository into a repo of my own. Even if I choose to use the same
44 > kind of repo (CVS in this case), then how hard will merging be? Again, this goes both ways.
45
46 You don't merge. You would file a bug with the changes and we would
47 either accept or deny the changes on a case-by-case basis.
48
49 > I hope I missed something here, but of the three the third looks the most appealing and likely with
50 > me forking into darcs probably. I don't think this issue would be here if the code were in a
51 > distributed SCM, but maybe by the time 2007.1 is due I will have amassed enough interesting changes
52 > that it is easier for you to then just clone my distributed repo ;P.
53
54 Again, it is *very* unlikely. If you look at the changes in the minimal
55 CD set between releases, you will see that it is extremely minimal, if
56 changes are even made. We simply don't change things that work. The
57 only changes that really go in are bug fixes. Are you saying that
58 you're going to be tracking all of the release bugs and fixing only
59 those? Are you planning on adding features? The former would be
60 helpful to Release Engineering, the latter would not be nearly as useful
61 to us unless they were absolutely compelling.
62
63 > So can we please discuss what distributed SCM is best for the tree or likely to be in the future and
64 > what hard data obtained with what tests should be gathered to rank SCMs and what feature differences
65 > there are and how much we should care about them?
66
67 I don't get why you discuss a distributed SCM, then proceed to talk
68 about minimal CD + releases stuff which has nothing to do with the main
69 tree. We keep our spec files in CVS, but it isn't the same repository
70 as the tree. If you're talking about changing the tree, then yes, you
71 should be filing bugs and getting them fixed in the tree.
72
73 I'm honestly not sure what exactly it is that you're trying to
74 accomplish. Some additional explanation would be great.
75
76 Again, if you want to see the tree converted to something else, you need
77 to show compelling reasons and data *why* it should be done. Discussing
78 it doesn't really show those things and lends itself to giving only
79 beliefs, political or personal, about given SCM software. I honestly
80 don't care what anybody *thinks* about any particular SCM. I am
81 interested in the facts and numbers. I don't have much preference
82 myself other than that I already know CVS/SVN. If we were to make a
83 change, even to SVN, I'd like to see some well-thought-out reasons why
84 and some numbers to back it up.
85
86 --
87 Chris Gianelloni
88 Release Engineering Strategic Lead
89 Alpha/AMD64/x86 Architecture Teams
90 Games Developer/Council Member/Foundation Trustee
91 Gentoo Foundation

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] Re: SCM choices "Marijn Schouten (hkBst)" <hkBst@g.o>