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
|
<!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=%3C20101205112450.GA12918%40sisay.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Next" HREF="001605.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Support policy</H1>
<B>Michael scherer</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Support%20policy&In-Reply-To=%3C20101205112450.GA12918%40sisay.ephaone.org%3E"
TITLE="[Mageia-dev] Support policy">misc at zarb.org
</A><BR>
<I>Sun Dec 5 12:24:50 CET 2010</I>
<P><UL>
<LI>Next message: <A HREF="001605.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1604">[ date ]</a>
<a href="thread.html#1604">[ thread ]</a>
<a href="subject.html#1604">[ subject ]</a>
<a href="author.html#1604">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On Sat, Dec 04, 2010 at 11:38:55AM +0100, Giuseppe Ghibò wrote:
><i> Michael Scherer wrote:
</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> why this kind of "competition"?
</I>
It is up to you to explain why you see competition when i just
state that we have obviously a different set of ressources.
><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> What you are saying is good, and I would like to extend what you
</I>><i> posted with what follows. IMHO we are trying to focus too much on
</I>><i> what it was wrong to forget what it was already good, like if what
</I>><i> was already good in the distro would be granted by default (e.g.
</I>><i> trying to focus too much on what is already in ANY of the 100
</I>><i> distrowatch.com distros: all of them have the same core-packages on
</I>><i> the other hand] to forget what is was already good or better: e.g.
</I>><i> good support for extra hardware, better support for scientific
</I>><i> applications, etc.).
</I>><i>
</I>><i> We should summarize what there is from what there isn't in the
</I>><i> distro. The 2nd problems is that we seem assigning to most packagers
</I>><i> and maintainers some secret powers that they should have, like
</I>><i> knowing the package better or at the same level than upstream
</I>><i> developers. If not, then there are lack of resources...; maybe they
</I>><i> just know how to assemble and compile it...and that's all. IMHO
</I>><i> knowing the package at such high levels has become the exception,
</I>><i> not the rule. One packager/maintainer might know very very well 1 or
</I>><i> maybe 3,4 packages (e.g. colin for pulseaudio, buchan for samba, me
</I>><i> for tex and so on), but there are 10000 packages out there and there
</I>><i> aren't 5000 maintainers...
</I>
Well, we at least except the maintainer to know how to run the software
or how to use it. If someone package a perl module, it is either for running
a script, or for another module ( hence in all case using it ).
So of course, the maintainer do not know everything, but he has at least
basic knowledge about the software.
><i> I give you an example. In MDV 2010.0 or 2010.1 the kdenlive package,
</I>><i> a video editing application, was not working at all. It crashes on
</I>><i> basic stuff as soon as you open or import a video file. In other
</I>><i> words unusable. How was possible that? Well, one might say poor QA,
</I>><i> bad packagers, bad maintainers or no maintainers at all, or no QA at
</I>><i> all. It your fault, it's their fault, it's our fault. Indeed it
</I>><i> doesn't matter. The main problem is that we rely as main source of
</I>><i> QA the bugzilla. So what is reported on bugzilla has a bug that we
</I>><i> should fix, what there isn't should work by default and has
</I>><i> automagically an higher QA score. IMHO this is a false assumption. I
</I>><i> might find it crashes and be lazy and not doing any bugzilla report,
</I>><i> or I'm not sure about what to tell exactly, because maybe I think
</I>><i> it's fault of my configuration, and so on. In the specific example
</I>><i> backports have a working kdenlive (maybe it's just luck, dunno) but
</I>><i> according to the supposed QA score the kdenlive in main should be
</I>><i> better than the one in backports. And indeed it isn't because any
</I>><i> program barely working is better than any program crashing on
</I>><i> startup.
</I>><i> To solve this there are a lot of solution, but it's not said that
</I>><i> the one or the other should influence people to use this distro and
</I>><i> not another, like we might think. E.g.
</I>><i>
</I>><i> 1) We might move kdenlive from good main to evil contrib or remove
</I>><i> kdenlive from the distro? Well, a non-existing package won't crash.
</I>><i> And so distro would result more polished, ordered (I like ordered
</I>><i> and cleaned distro with no broken deps in hdlists, really) should
</I>><i> rock. But from point of view of an end user he don't have any video
</I>><i> editing application anyway. So who cares of the others packages he
</I>><i> won't use?
</I>
That solution was already used for koffice or kdevelop, IIRC.
And the fact is while it should be IMHO a really last resort solution,
we cannot avoid keeping it in mind.
And the issue is not only our reputation, but also the one of kdenlive, and
as a distributor, we must think of our upstream as well.
><i> 2) We might let people know that the backport version works. So more
</I>><i> communcation here.
</I>
Or add the backport to updates, as this would be a bugfix.
><i> 3) We might add several new rules and weights on the shoulders of
</I>><i> the maintainers/packagers. A packager could fly away, so letting
</I>><i> these rules on the shoulders of the other survived packagers which
</I>><i> then will be more overloaded, and then could fly away more. Sound a
</I>><i> bit like the "highlander" packager...
</I>
Like "running the package at least once to see if it work before uploading" ?
This is not a new rule.
><i> 4) We might help to let these rules easier, lighter and quicker to
</I>><i> be implemented (more communcation, self or packagers helping each
</I>><i> others, more automatic tools)
</I>
We need to offload everything we can on automatic scripts. This was my presentation
in 2004 at cooker meeting, and this is still true, IMHO. Youri, rpmlint, etc, all
have served to catch errors that were discovered by random user before.
Of course, this doesn't fix them.
><i> 5) Add a precise protocol of testing for each package. This might be
</I>><i> automatic or manual (or both). In case of manual, the testing
</I>><i> protocol steps might be performed by anyone. But shouldn't go in the
</I>><i> destructive spiral of more rules. Documentation should be crystal
</I>><i> clear, and information should be easy to catch not let users waste
</I>><i> days and days trying to find the right thing to do, in seeking good
</I>><i> documentation between tons of obsolete and bad one. Also the report
</I>><i> of the testing should be easy to post, not opening 27 sites, scroll
</I>><i> between 18000 packages, wait 10 minutes the server answers, or
</I>><i> sending 84 mails and wait answer from 54 different people...; In
</I>><i> case of kdenlive, a basic protocol test could be like this: 1)
</I>><i> install the package 2) Go on menu Project/Add clip and open the file
</I>><i> blabla.avi HERE... 3) Go on menu Monitor/Clip and click on the
</I>><i> button "play" 4) ... 5) rely also on the upstream protocol testing
</I>><i> if exists 6) report it works by a couple of clicks. This won't
</I>><i> require specific skill and even users who might not have ever used
</I>><i> this package could partecipate.
</I>
Yup. And I think we can adopt this progressively. Ie, first focus on
writing one test file, and then use it. And start with a 2nd test file, etc.
Once there is enough test file, people can organize test days.
And we could even share those procedures with others distributions.
><i> 5) Punish the one who uploaded the package. Blocking it for one lap.
</I>><i> Well this is a bit scaring ;-) Don't do that.
</I>
Indeed, punishing people should not be used, this doesn't work. We are not child
anymore. And I think this would be humiliating ( but I understand that this
was proposed to be complete ).
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Next message: <A HREF="001605.html">[Mageia-dev] Mirror layout, round two
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#1604">[ date ]</a>
<a href="thread.html#1604">[ thread ]</a>
<a href="subject.html#1604">[ subject ]</a>
<a href="author.html#1604">[ 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>
|
