1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Support policy
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C4CFA1A3F.8070800%40gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="001599.html">
<LINK REL="Next" HREF="001601.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Support policy</H1>
<B>Giuseppe Ghibò</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C4CFA1A3F.8070800%40gmail.com%3E"
TITLE="[Mageia-dev] Support policy">ghibomgx at gmail.com
</A><BR>
<I>Sat Dec 4 11:38:55 CET 2010</I>
<P><UL>
<LI>Previous message: <A HREF="001599.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001601.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1598">[ date ]</a>
<a href="thread.html#1598">[ thread ]</a>
<a href="subject.html#1598">[ subject ]</a>
<a href="author.html#1598">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Michael Scherer wrote:
><i>
</I>><i> Well, from a physical point of view, everything is limited, so saying
</I>><i> "limited ressources" didn't indeed told much.
</I>><i>
</I>><i> I think that the ressources at Mandriva could be summarized as "around 1
</I>><i> to 3 full time people ( maybe more, maybe less, and likely not full time
</I>><i> on the stable free distro )".
</I>><i>
</I>><i> Which is not balanced at all when compared to the ressources that were
</I>><i> placed in packaging. Ie, there was much more people to produce rpm than
</I>><i> people to
</I>><i> 1) take care of update ( secteam, 2 people )
</I>><i> 2) take care of testing update ( qateam, 1-3 people )
</I>><i>
</I>><i> Being unbalanced lead to the main/contribs split with the complexity and
</I>><i> problem that went with it. Of course, the goal is not to have less
</I>><i> packagers, but rather more Qa people, the 2 being not exclusive.
</I>><i>
</I>><i> This then bring to the simple question is "why did we have more
</I>><i> packagers than QA ?"
</I>><i>
</I>><i> My own opinion is that because packaging was opened to external
</I>><i> contribution since almost the start ( since 10 years, packagers number
</I>><i> have growth ), while QA was not, and I suppose that was due to a lack of
</I>><i> time devoted on making QA more open ( ironically likely due to a lack of
</I>><i> ressources at the first place ).
</I>><i>
</I>><i> And so, I think we are now in a totally different situation. QA will be
</I>><i> more open, because it cannot be closed. We can ( and I think we should )
</I>><i> make the QA ressources grow with the packagers one ( among others ).
</I>><i>
</I>><i> So how can we do ?
</I>><i>
</I>><i> While this may not seems apparent at first sight, I think that Fedora is
</I>><i> actually leading in term of community QA process ( we still had the lead
</I>><i> in term of automated QA ).
</I>><i>
</I>><i> Basically, packages that are updated requires to be noted, with a system
</I>><i> of karma ( <A HREF="http://fedoraproject.org/wiki/Bodhi_Guide#Karma">http://fedoraproject.org/wiki/Bodhi_Guide#Karma</A> ).
</I>><i> Positive karma, the update is pushed, negative, it is not.
</I>><i>
</I>><i> Anybody can test anything, even if there is also a proven tester group.
</I>><i>
</I>><i> There is even the concept of critical path packages, aka very important
</I>><i> package that must be deeply tested
</I>><i> ( <A HREF="http://fedoraproject.org/wiki/Critical_Path_Packages">http://fedoraproject.org/wiki/Critical_Path_Packages</A> ).
</I>><i>
</I>><i> Of course, the system is not perfect and will not solve everything. For
</I>><i> example, last week, openldap update broke server functionality :
</I>><i> ( <A HREF="http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html">http://lists.fedoraproject.org/pipermail/devel/2010-November/146097.html</A> )
</I>><i>
</I>><i> But still, having community enabled QA is a great way to have every grow
</I>><i> properly.
</I>><i> And in fact, that's exactly one of the feature of your project
</I>><i> mageia-app-db. So we could indeed have a better QAteam by easing the
</I>><i> work of community, using mageia-app-db. Ie, take regular user, and turn
</I>><i> them in QA team member.
</I>><i>
</I>><i> And so, doing like this would enable to give us :
</I>><i> - real involvement from some users
</I>><i> - balanced community, not overwhelmed by technical maniac packagers
</I>><i> ( like me )
</I>><i> - having a better Qa, for a better system
</I>><i>
</I>><i> So while nothing is done, while I am not a member of the QA team nor a
</I>><i> leader, while I just speak to voice my opinion, and while this is just a
</I>><i> proposal based on what other have done to solve the same issue than us,
</I>><i> this show that we can have more ressources than what Mandriva had.
</I>><i>
</I>><i>
</I>why this kind of "competition"?
><i> Ie, we need to think with a fresh mind, and I am sure that people can
</I>><i> creatively propose solutions on the problem :
</I>><i>
</I>><i> "how can we have a more balanced QA and packagers team".
</I>><i>
</I>><i>
</I>><i>
</I>What you are saying is good, and I would like to extend what you posted
with what follows. IMHO we are trying to focus too much on what it was
wrong to forget what it was already good, like if what was already good
in the distro would be granted by default (e.g. trying to focus too much
on what is already in ANY of the 100 distrowatch.com distros: all of
them have the same core-packages on the other hand] to forget what is
was already good or better: e.g. good support for extra hardware, better
support for scientific applications, etc.).
We should summarize what there is from what there isn't in the distro.
The 2nd problems is that we seem assigning to most packagers and
maintainers some secret powers that they should have, like knowing the
package better or at the same level than upstream developers. If not,
then there are lack of resources...; maybe they just know how to
assemble and compile it...and that's all. IMHO knowing the package at
such high levels has become the exception, not the rule. One
packager/maintainer might know very very well 1 or maybe 3,4 packages
(e.g. colin for pulseaudio, buchan for samba, me for tex and so on), but
there are 10000 packages out there and there aren't 5000 maintainers...
I give you an example. In MDV 2010.0 or 2010.1 the kdenlive package, a
video editing application, was not working at all. It crashes on basic
stuff as soon as you open or import a video file. In other words
unusable. How was possible that? Well, one might say poor QA, bad
packagers, bad maintainers or no maintainers at all, or no QA at all. It
your fault, it's their fault, it's our fault. Indeed it doesn't matter.
The main problem is that we rely as main source of QA the bugzilla. So
what is reported on bugzilla has a bug that we should fix, what there
isn't should work by default and has automagically an higher QA score.
IMHO this is a false assumption. I might find it crashes and be lazy and
not doing any bugzilla report, or I'm not sure about what to tell
exactly, because maybe I think it's fault of my configuration, and so
on. In the specific example backports have a working kdenlive (maybe
it's just luck, dunno) but according to the supposed QA score the
kdenlive in main should be better than the one in backports. And indeed
it isn't because any program barely working is better than any program
crashing on startup.
To solve this there are a lot of solution, but it's not said that the
one or the other should influence people to use this distro and not
another, like we might think. E.g.
1) We might move kdenlive from good main to evil contrib or remove
kdenlive from the distro? Well, a non-existing package won't crash. And
so distro would result more polished, ordered (I like ordered and
cleaned distro with no broken deps in hdlists, really) should rock. But
from point of view of an end user he don't have any video editing
application anyway. So who cares of the others packages he won't use?
2) We might let people know that the backport version works. So more
communcation here.
3) We might add several new rules and weights on the shoulders of the
maintainers/packagers. A packager could fly away, so letting these rules
on the shoulders of the other survived packagers which then will be more
overloaded, and then could fly away more. Sound a bit like the
"highlander" packager...
4) We might help to let these rules easier, lighter and quicker to be
implemented (more communcation, self or packagers helping each others,
more automatic tools)
5) Add a precise protocol of testing for each package. This might be
automatic or manual (or both). In case of manual, the testing protocol
steps might be performed by anyone. But shouldn't go in the destructive
spiral of more rules. Documentation should be crystal clear, and
information should be easy to catch not let users waste days and days
trying to find the right thing to do, in seeking good documentation
between tons of obsolete and bad one. Also the report of the testing
should be easy to post, not opening 27 sites, scroll between 18000
packages, wait 10 minutes the server answers, or sending 84 mails and
wait answer from 54 different people...; In case of kdenlive, a basic
protocol test could be like this: 1) install the package 2) Go on menu
Project/Add clip and open the file blabla.avi HERE... 3) Go on menu
Monitor/Clip and click on the button "play" 4) ... 5) rely also on the
upstream protocol testing if exists 6) report it works by a couple of
clicks. This won't require specific skill and even users who might not
have ever used this package could partecipate.
5) Punish the one who uploaded the package. Blocking it for one lap.
Well this is a bit scaring ;-) Don't do that.
6) Any combination of the above.
Second problem is that there also any referring to documentation
support, but speak only from point of view of packagers. We might have
things that are rock solid, but if nobody knows how to use them... ;-)
Bye
Giuseppe.
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="001599.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI>Next message: <A HREF="001601.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1598">[ date ]</a>
<a href="thread.html#1598">[ thread ]</a>
<a href="subject.html#1598">[ subject ]</a>
<a href="author.html#1598">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>
|
