1 |
On Wednesday 25 June 2003 07.47, Jon Portnoy wrote: |
2 |
> On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote: |
3 |
> > On Wednesday 25 June 2003 06.04, Jon Portnoy wrote: |
4 |
> > > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote: |
5 |
> > > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote: |
6 |
> > > |
7 |
> > > [snip] |
8 |
> > > |
9 |
> > > > 1. What is Gentoo 1.4. What it may have been intended to be in |
10 |
> > > > January is probably not what it is going to be now. Before you |
11 |
> > > > recruit all and sundry you have to define this as if it isn't defined |
12 |
> > > > everything will fall down and chaos will return. Some basic things I |
13 |
> > > > see is that it needs to be are: gcc3.3 based |
14 |
> > > > glibc2.3.2 |
15 |
> > > > openssl0.9.7 |
16 |
> > > |
17 |
> > > We can do this if you want to wait another couple of months. |
18 |
> > > |
19 |
> > > Unfortunately, there are some requests to have 1.4 ready for LWESF at |
20 |
> > > the beginning of Augusy |
21 |
> > |
22 |
> > This is just classical, happens everyday type stuff in |
23 |
> > electronics/software companies, espically ones who don't know what they |
24 |
> > are building with clear goals. Marketing keeps moving the requirements |
25 |
> > and dates aren't met. Some deadline finally gets set and a patch work |
26 |
> > job happens to meet THE DATE. |
27 |
> |
28 |
> We know what we're building and have clear goals. Those goals have been |
29 |
> specified on this list by Daniel in the past. |
30 |
past day, week, month, year? He has had about 4 posts here in the last 6 |
31 |
months. Why isn't the QA guy demanding a list of packages to be included? |
32 |
> |
33 |
> With minor exceptions, _those goals are met_. |
34 |
|
35 |
What exceptions? Why the sudden panic then? |
36 |
> |
37 |
> However, you're now suggesting _entirely new_ goals that _do not fit_ |
38 |
> with the schedule already in mind. Marketing is irrelevant - a few |
39 |
> people said "Do you think we'll be ready for LWESF?" and I said "Yes." I |
40 |
> intend to follow up on that, now that our goals are either met or about |
41 |
> to be met. There is no 'THE DATE' that we absolutely must adhere to. |
42 |
> Instead, I'm telling you that there is no technical way we can go with |
43 |
> gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a |
44 |
> significantly long period of time while work is done in those areas. |
45 |
Now above you say there is a deadline and here you say there isn't. I can't |
46 |
see how you can say I am describing new goals when you can't point me to a |
47 |
document which states what the current goals are. There is no QA as noone |
48 |
can trace a specification pass back to a specified requirement. I've |
49 |
digressed into QA but thats actually what the total process should be about. |
50 |
|
51 |
> > > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 |
52 |
> > > needs a much more mature upgrade path, otherwise there will be serious |
53 |
> > > breakage (you need to remerge wget without ssl support, then merge the |
54 |
> > > new openssl, then rebuild everything depending on it currently). |
55 |
> > |
56 |
> > The OpenSSL upgrade is really ready, it just that the whole tree needs a |
57 |
> > rebuild which is time consumming. You have to break the cycle sooner or |
58 |
> > later. Seems to me one solution is to release a binary version of 1.4 |
59 |
> > build with the latest OpenSSL goes someway to ease that upgrade. Users |
60 |
> > can get a |
61 |
> |
62 |
> Certainly, new stage1 and stage2 installs would have no problem - they |
63 |
> haven't done an emerge system yet. A stage3 with openssl 0.9.7 would |
64 |
> have no problem. Existing users or people using old stage3s would be |
65 |
> screwed. We need a better upgrade path for that in order to avoid the |
66 |
> kind of "patch work job" you described earlier. |
67 |
> |
68 |
> With regards to 'breaking the cycle,' we need functionality in Portage |
69 |
> that either allows the ebuild to directly run revdep-rebuild or |
70 |
> incorporate revdep-rebuild into Portage (or preferably real reverse |
71 |
> dependencies, which will come in Portage 2.1 last I heard). |
72 |
Ok, now this is good. All that is needed is to write these points down and |
73 |
pretty soon you will end up with a requirement document that everyone can |
74 |
understand, identify where they can be of most use and a check list you can |
75 |
tick off when each thing is done. Now the project is managed! It really is |
76 |
simple but because it is tedious, for a good designer, it is somewhat boring. |
77 |
|
78 |
> |
79 |
> > working basic system maybe with kde and gnome desktops then add or |
80 |
> > rebuild at their own pace. New takers have no problems as they are |
81 |
> > current. GCC is a slightly different problem but not as large. I guess |
82 |
> > it could be solved putting different versions of GCC in slots. Glibc is |
83 |
> > pretty well there and doesn't seem to have any problems that I have |
84 |
> > noticed. |
85 |
> |
86 |
> SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is |
87 |
> not ready for it. Many applications will not build and there are many, |
88 |
> many unsolved problems and weird issues that people can't track down. |
89 |
> GCC 3.3 is not production ready and I, for one, am not interested in |
90 |
> pushing people to release a broken compiler on the masses for the sake |
91 |
> of saying "we're up to date!" - can you please justify pushing GCC 3.3 |
92 |
> before it's ready? |
93 |
|
94 |
I don't need too. I'm not a gentoo developer, I just help where I can, when |
95 |
I can. What you should be telling me is here is a url of the number of |
96 |
packages that won't build with gcc3.3 in portage and here is another list |
97 |
that we are not sure of. Have that in an easy to find location then things |
98 |
can start to happen. It's all very well to say things are as broken as SCO's |
99 |
kernel code but all I can say is, show me the list and I will see what I can |
100 |
do to fix some of it. :) |
101 |
|
102 |
> |
103 |
> That's not too many for an August deadline: I'm not sure where you got |
104 |
> that idea. They'll be ready at the same time because it makes sense for |
105 |
> them to be ready at the same time to have a uniform release. There is no |
106 |
> reason _not_ to release them at the same time. |
107 |
|
108 |
Great but not visible. |
109 |
> |
110 |
> If a specific arch leads decides they're not ready for a 1.4 release, |
111 |
> they won't be released. I'm not going to mandate that archs that aren't |
112 |
> ready have a release, but I'm not going to refuse to release what's |
113 |
> ready, either. |
114 |
|
115 |
Your the release guy, your call seems reasonable. |
116 |
|
117 |
> |
118 |
> Marketinng Dept? We have nothing to gain from 'marketing' except for |
119 |
> providing a superior product to users. I am sorry that providing a |
120 |
> superior product to users and attempting to avoid any inconvienence to |
121 |
> users does not fit with what you would like. I am not willing to push |
122 |
> gcc 3.3 yet because it breaks for a lot of people; I am not willing to |
123 |
> push openssl 0.9.7 out of package.mask because many people will have |
124 |
> broken systems without a better upgrade path. I am sorry that you do not |
125 |
> understand QA. |
126 |
|
127 |
Talk about the pot calling the kettle black. You can't point to 1 record that |
128 |
confirms anything your designing. I have been a designer for ISO9001 |
129 |
approved companies for the last 10 years, before that to Mil and other |
130 |
telecom standards, please give me a break. |
131 |
|
132 |
> |
133 |
> > > > These are just really fundementals but until the requirements are |
134 |
> > > > documented things will never really come together. |
135 |
> > > > |
136 |
> > > > Get things out in the open. Gentoo-core is probably the worst idea |
137 |
> > > > someone ever came up with, OSS development is meant to be a very |
138 |
> > > > transparent process. Make it transparent. I know there are always |
139 |
> > > > private issues but if they involve more than 3 people then perhaps |
140 |
> > > > they should be public. |
141 |
> > > |
142 |
> > > We are making it transparent by discussing development on gentoo-dev. |
143 |
> > |
144 |
> > Don't tell me, someone woke up this morning and formed a new management |
145 |
> > structure, honest :) You know you need this transparent as it is the |
146 |
> > only hope of it getting done in time. It's not a big deal for me |
147 |
> > actually, it's just that of ppl where primed and ready for the |
148 |
> > announcement you would be more than halfway towards meeting the |
149 |
> > objectives. |
150 |
> |
151 |
> Can you explain what you mean here? Getting what done |
152 |
> in time? Which announcement? Which objectives? |
153 |
Your asking me? Shit I'm not running the project, your meant to know all |
154 |
those answers. |
155 |
|
156 |
> |
157 |
> > Anyway, from another comment it is impossible to define goals for Gentoo |
158 |
> > therefore I would submit it is impossible to have a 1.4 release. I have |
159 |
> > no problems with that, marketing probably does though. |
160 |
> |
161 |
> Now you're really grasping at straws. Can you tell me which comment says |
162 |
> that it's impossible to define goals for Gentoo? |
163 |
Can you point to any document that defines Gentoo 1.4? |
164 |
|
165 |
> |
166 |
> What marketing? The fact that I said that it'd be nice to have something |
167 |
> to hand out on CDs to people for LWESF so they can go home and install |
168 |
> Gentoo suddenly means everything we do is based on marketing? |
169 |
|
170 |
Ecveryone has marketing whether they know it or not. You just described a |
171 |
part of marketing. |
172 |
> |
173 |
> I apologize for all of us for trying to provide you, the users, with a |
174 |
> superior product, good QA, and convienent upgrades. |
175 |
I think it is already established that you have no QA in the design sense. |
176 |
Bugs are handled pretty well, product is good, ego is a little on the high |
177 |
side, so in general thanks for a job well done. Hey QA ain't everything, I'm |
178 |
the first to admit that, I'm just happy Gentoo is QAed to death like debian. |
179 |
|
180 |
tony |
181 |
-- |
182 |
Contract ASIC and FPGA design. |
183 |
Telephone +46 702 894 667 |
184 |
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623 |
185 |
|
186 |
|
187 |
|
188 |
-- |
189 |
gentoo-dev@g.o mailing list |