1 |
Enrico Weigelt wrote: |
2 |
<snip> |
3 |
> |
4 |
>>> 1) thousands of packages will never be marked stable |
5 |
>> Honestly, they shouldn't be stable. |
6 |
> |
7 |
> hmm, maybe we should have different groups of ports (*1) for |
8 |
> |
9 |
> a) quite stable: no bugs yet and enough votes) |
10 |
> b) *proven* to be stable: has passed the whole bunch of qm tests. |
11 |
> |
12 |
> The quite stable category could be used for "normal" packages which |
13 |
> are used in production but are not very critical. Maybe games and |
14 |
> seldomly used stuff can be taken from here. |
15 |
> |
16 |
> Critical things (ie. base system, toolchain, critical apps) should |
17 |
> only be taken from the proven/mature category. Maybe we could maintain |
18 |
> several profiles which does the common masking. |
19 |
|
20 |
This my first mail to this list. |
21 |
|
22 |
Short intro: I was introduced to gentoo by some colleagues roughly 2 |
23 |
years ago. *ALL* of them switched to Ubuntu, because the were annoyed by |
24 |
the package policy of gentoo with respect to server environments. I am |
25 |
still into gentoo and this upcoming criticism since Ubuntu motivates me |
26 |
to support gentoo more actively. Altough I did not finished any ebuild |
27 |
at this moment, I hope to help with my 'fresh' user view: |
28 |
|
29 |
I agree on the need to work on the unstable packages (my keyword list is |
30 |
large and I did not know that it is a bug to say please make it stable) |
31 |
|
32 |
To differentiate quite stable and proven is a good starting point. |
33 |
|
34 |
> I'm not quite familar w/ overlays yet, but it seems wise to me |
35 |
> to maintain overlays for several groups of b) ports. Individual |
36 |
> overlays may have their own policies. For example one for critical |
37 |
> server systems would require absolutely reliable, automatic remote |
38 |
> updates, security fixes fast in but enhancements lazy, binary |
39 |
> compatibility, etc. |
40 |
> |
41 |
>> In fact, likely, many shouldn't be in the tree. We have way too many |
42 |
>> packages that are used solely by a small group of people sitting around |
43 |
>> the tree. These would be better served in official overlays, where |
44 |
>> they can be maintained by the interested parties (including users), |
45 |
>> rather than in the tree. |
46 |
> |
47 |
> Those overlays seem good, if they represent an entire subtree |
48 |
> (aka distinct from the main tree). For example there could be an |
49 |
> KDE/Qt overlay, which contains the whole KDE stuff. People not |
50 |
> interested in any of KDE (like me) don't need it. This would make |
51 |
> syncing less resource intensive. |
52 |
> |
53 |
> But: please let's call them *Subtrees*. |
54 |
|
55 |
The name overlay makes more sense, because a subtree is a sub-directory |
56 |
in case of a filesystem. The overlay is not a new subdirectory in |
57 |
portage, it exists of one or more directories outside portage which |
58 |
'cover' one or more subdirectories of portage. |
59 |
|
60 |
But I don't know if the overlay is a solution to handle the discussed |
61 |
problem. |
62 |
|
63 |
|
64 |
> box:/ # equery-2do world |
65 |
> [www-apps/bugilla-2.22 ~x86] (installed: 2.22 +postgres ...) |
66 |
> * solve bug 12345 |
67 |
> * test seamless upgrading from 2.20.2 |
68 |
> ... |
69 |
> [knollo/test-1.23 ~x86] (installed 1.20) |
70 |
> * solve bug 1222 |
71 |
> * try out new +postgres |
72 |
> ... |
73 |
> |
74 |
> <snip> |
75 |
|
76 |
Good idea, would be nice for me to find in an *efficient* way starting |
77 |
points for my helping hand. |
78 |
|
79 |
|
80 |
>>> 4) The user experience sucks - see the forums/wiki... "to install |
81 |
>>> this great sw you need the latest version of x, which depends on y,z, |
82 |
>>> so copy paste this huge block in to /etc/portage/package.keywords."... |
83 |
>>> then 2 weeks later some depend changes, and suddenly emerge -u world |
84 |
>>> no longer works, and user has more problems to solve. |
85 |
>> Honestly, the number of people out there giving shit advice is part of |
86 |
>> the problem. Rather than telling people to do this sort of thing, a |
87 |
>> better solution would be to tell people how they can *help* instead of |
88 |
>> how they can bypass the system, which ends up with clueless users filing |
89 |
>> more bugs, which delays the stabilization longer. |
90 |
> |
91 |
> ACK. It's quite the same problem as many many packages (upstream) in |
92 |
> the OSS world have - they try to work around bugs in imported packages, |
93 |
> sometimes even ship their own branch of them (ie. apache -> expat) |
94 |
> instead of simply fixing the problem on the source. And this then |
95 |
> ends up in thinkgs like the whole autotools hell. |
96 |
> That's why I started my OSS-QM project, I had announced some weeks ago. |
97 |
> |
98 |
> <snip> |
99 |
>> Every user that someone knowledgeable gets to use something they don't |
100 |
>> understand, is a potential bug report slowing stabilization even more. |
101 |
> |
102 |
> At least these bug reports should contain the user's keywording info. |
103 |
> Ie. if the bug applies to an masked version, there should be an tag, |
104 |
> so the devs can easily filter on that. Maybe one's only fixing bugs |
105 |
> in unmasked packages and keeps things stable, another one then works |
106 |
> on stabelizing an still masked package. |
107 |
> |
108 |
> BTW: is there any console tool for reporting bugs w/ all necessary |
109 |
> information quickly ? |
110 |
> |
111 |
> Ie. if I found an bug in my current bugzilla, I simply wan to call |
112 |
> it with the package name - the tool gathers all necessary information |
113 |
> (ie. looks for the installed version, including masks, useflags, etc) |
114 |
> and asks a few questions. |
115 |
> |
116 |
>>> The testing is supposed to be for the ebuild, not the package itself, |
117 |
>>> so there's not much point in holding back packages with simple ebuilds |
118 |
>>> from being stabilised. And the testing process isn't that extensive |
119 |
>>> anyway - all it ensures is that the package builds and can be run on |
120 |
>>> one particular arch testers system. No disrespect to the testers, but |
121 |
>>> they can't be experts in every particular piece of software. How much |
122 |
>>> code coverage does a typical ebuild really get when being tested? |
123 |
>> First off, we have a level of expectation of stability to maintain. If |
124 |
>> all packages were done "right" then 90% of the ~arch packages in the |
125 |
>> tree would be under package.mask, rather than ~arch. Only packages in |
126 |
>> ~arch would be ones with no bugs open, to test the ebuild, so that they |
127 |
>> can become stable. As we all know, this isn't the case. Developers all |
128 |
>> over the place, including myself, have put in tons of packages that |
129 |
>> aren't necessarily perfectly stable themselves. We do this because our |
130 |
>> users demand it. We have reached a critical mass of users, where no |
131 |
>> matter what we do, somebody is going to bitch and piss and moan because |
132 |
>> we don't do things the way they would like. There's nothing that we can |
133 |
>> do about this except decide collectively what the best course of action |
134 |
>> for our users would be and try to make things as high-quality as |
135 |
>> possible. |
136 |
> |
137 |
> hmm, social pressure is a big problem here. The mass of people who |
138 |
> maybe are happy with semi-stable packages hurt those few who need |
139 |
> critical stability. |
140 |
> |
141 |
> I tend to like the idea of mission-critical overlays more and more. |
142 |
|
143 |
Overlays may be good for people like me who want to begin developing |
144 |
gentoo. But it can't help overall. |
145 |
|
146 |
> |
147 |
>> Automatic stabilization is one of those things that would cause our |
148 |
>> quality to go to hell. Another thing is this. If you don't like it, |
149 |
>> fork. You've got the code. You're *more than welcome* to go around |
150 |
>> making your own overlay/tree and marking whatever rubbish you feel like |
151 |
>> as stable. There's *nobody* stopping you from doing so. However, many |
152 |
> |
153 |
> I just read over the discussion very quickly, but isn't this exactly |
154 |
> what Sunrise should be for ? |
155 |
> |
156 |
> <snip> |
157 |
|
158 |
What I understood from sunrise: They try to lower the barrier to get |
159 |
involved in ebuild development. BTW: Is there anybody who can tell me, |
160 |
if sunrise is now accepted by the gentoo community, and if not, what is |
161 |
the criticism? Should I go for sunrise? |
162 |
|
163 |
But also here I don't thing that sunrise should be a good practice for |
164 |
the gentoo user to overcome the aging unstable package problem. |
165 |
|
166 |
> |
167 |
>> Another problem is that we don't *know* what is being run by our users. |
168 |
> |
169 |
> hmm, why not creating an database for this ? |
170 |
> Users are then encouraged to run an tool which regularily posts the |
171 |
> interesting parts of the emerge database (package+version+useflags+ |
172 |
> keywords) and some system information (CFLAGS, hardware data, ...) |
173 |
> into the database. Once we've reached an critical mass, we've got |
174 |
> some usable statistic information. So we could also see, what should |
175 |
> not be kicked off the tree (ie. someone's still using old packages, etc). |
176 |
> We simply should tell people to use this tool if they like to get their |
177 |
> systems supported. |
178 |
> |
179 |
|
180 |
<snip> |
181 |
|
182 |
> + an tool checks the emerge db for masked packages which are older |
183 |
> than 30 days and asks the user if he likes to give comments and |
184 |
> if he likes to see it stabelized. |
185 |
|
186 |
|
187 |
Yeah, that's why I want to raise my voice! Great idea! That would be a |
188 |
community solution. Since the Ubuntu hype and criticism about unstable |
189 |
gentoo I was thinking in this direction. May the things and ideas said |
190 |
above are old (take them as a user vote then), I want try to make it |
191 |
more explicit and put my own view on it: |
192 |
|
193 |
1. IMHO the problem is not aging ebuilds at all. It is about information |
194 |
content in portage and user feedback. More concrete: the problem is that |
195 |
there is not enough information about ebuilds. What we see on the |
196 |
surface (either on http://packages.gentoo.org or via emerge) is whether |
197 |
an ebuild is stable, unstable (keyword masked), hardmasked or not |
198 |
present at all. Not more. But what is needed is WHY,since WHEN and some |
199 |
other information: |
200 |
|
201 |
stable: OK, here everything is fine. The situation everbody likes ;) |
202 |
|
203 |
unstable: Why? Are there reason in the software package itself that |
204 |
makes the integration via an ebuild into gentoo non-trivial? Is the |
205 |
former maintainer Ubuntu addicted, know? Doesn't he find the time? Does |
206 |
he think, this ebuild is not important, because only two users are using |
207 |
it? |
208 |
|
209 |
hardmasked: Why? The same above, or severe security problems that arose? |
210 |
Since when? |
211 |
|
212 |
2. To answer these questions, a feedback statistic would help a lot: a |
213 |
tool like 'emerge-feedback category/package-version' collecting the data |
214 |
in a single database could do it. |
215 |
|
216 |
scenario a) user just says 'emerge-feedback installation-succesfull |
217 |
category/package-version' and agrees that data like USEFLAGS, CFLAGS etc |
218 |
are also submitted. This enables the developers to see how important an |
219 |
ebuild in the community is and which package works best under which |
220 |
environment. |
221 |
|
222 |
scenario b) an emerge was not successful as an immediate reaction the |
223 |
user says 'emerge-feedback install-failed'. This tool could then collect |
224 |
all information necessary for a good bug report to bugzilla. If bug |
225 |
reports could be unified in this way, developer could also get to know |
226 |
how many user experience this problem under which circumstances. The |
227 |
difference here: If a bug occurs and a user is willing to submit it. He |
228 |
checks for an existing bug report. And if it already exist, he normally |
229 |
does not give any further feedback. |
230 |
|
231 |
scenario c) A user checks a package like postgis at packages.gentoo.org, |
232 |
he sees, 5 versions exist but only the oldest ver. 0.75 is marked |
233 |
stable, and the other 4 up to ver 1.1.2 are not. If he sees next to each |
234 |
version since when it is in the state and in addition to e.g. version |
235 |
1.1.2 that a number of X user already installed it succesfully since |
236 |
then and Y user report problems he might be more encouraged to test and |
237 |
report it. |
238 |
|
239 |
|
240 |
Of course, all this information could be gathered from forums reading, |
241 |
bugzilla, ChangeLogs etc., but I am enthusiastic about this idea raised |
242 |
in this thread is: transparency, efficiency of the information and |
243 |
community feedback. |
244 |
|
245 |
I would also like to emphasize that it is important to also see why and |
246 |
since when a package is deleted. Not to say that I am often annoyed by |
247 |
package deletions, because they often force unwanted upgrades of |
248 |
depending packages. Also here to have the information, if a package was |
249 |
deleted because the programmer stopped the support like MySQL will do |
250 |
for the 3.x and 4.x in the next month. Or if the ebuild maintainer did |
251 |
not see the use anymore... |
252 |
|
253 |
I also dream of package branches that are marked as long time |
254 |
maintained, e.g. apache 1.3 should have a long life in portage. |
255 |
|
256 |
Ciao, |
257 |
|
258 |
someone |
259 |
-- |
260 |
gentoo-dev@g.o mailing list |