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 |