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
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Missing packages in Mageia 1. How to backport?
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C4DF22E57.2080900%40colin.guthr.ie%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="005346.html">
<LINK REL="Next" HREF="005336.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Missing packages in Mageia 1. How to backport?</H1>
<B>Colin Guthrie</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Missing%20packages%20in%20Mageia%201.%20How%20to%20backport%3F&In-Reply-To=%3C4DF22E57.2080900%40colin.guthr.ie%3E"
TITLE="[Mageia-dev] Missing packages in Mageia 1. How to backport?">mageia at colin.guthr.ie
</A><BR>
<I>Fri Jun 10 16:46:47 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="005346.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
<LI>Next message: <A HREF="005336.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5364">[ date ]</a>
<a href="thread.html#5364">[ thread ]</a>
<a href="subject.html#5364">[ subject ]</a>
<a href="author.html#5364">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble:
><i> Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
</I>>><i> So the user that just wants to install supybot has to expose themselves
</I>>><i> to the risk of updating to a backported version of gnome or KDE.... this
</I>>><i> is hardly ideal. Especially for novice users.
</I>><i>
</I>><i> One alternative would be to make sure that backports for version 1 are
</I>><i> fully supported and break nothing.
</I>
That's certainly worth considering.
>><i> This seems like a strange statement as */updates on mdv was allowed to
</I>>><i> have new packages in some cases (I've done it before, although I think
</I>>><i> only for * == contrib), so I don't see why we have to restrict this
</I>>><i> possibility in Mageia.
</I>><i>
</I>><i> contrib/updates was basically not watched at all. People could send
</I>><i> anything without trouble, and there was no policy ( nor any enforcement
</I>><i> ). That's not really the best example to use :)
</I>
Hmm, I can't really disagree with that statement :D
>>><i> We have used backports in the past for that, and I see no reason to
</I>>>><i> change that.
</I>>><i>
</I>>><i> This is fine in the regular course of distro evolution, but here we're
</I>>><i> talking about users migrating from Mdv to Mga and finding "stale" Mdv
</I>>><i> packages still installed on their system when they want (and we want to
</I>>><i> provide) a Mageia version. This is very much a special case for this
</I>>><i> transitional period but I feel it's an important one, particularly
</I>>><i> *because* it's the first release.
</I>><i>
</I>><i> All releases are equal. And we warned that we would not be able to do
</I>><i> everything, so of course, we will have problem with those that lived on
</I>><i> Mars under a rock, but I think that most people know that we couldn't
</I>><i> have all.
</I>
Quite. But if the only reason for not providing a particular service or
offering is due to a policy (i.e. people want to provide and others want
to consume) then it's perhaps the policy that need re-evaluating. Just
because it's policy, doesn't mean it's the best solution. Pragmatism
often solves a lot of problems. As I said before I think we can easily
over analyse things...
>><i> I think you're thinking in absolute terms rather than transitional
</I>>><i> terms. In absolute terms I agree with you on principle, but I think we
</I>>><i> need to deal with transitional issues gracefully and not treat them as
</I>>><i> second class considerations.
</I>><i>
</I>><i> It was not clear for me from your mail that this would be temporary.
</I>><i>
</I>><i> So I assume we can agree to enforce the "new packages go to backports
</I>><i> unless very specific and defined exceptions" policy for version 2 of the
</I>><i> release ?
</I>
Yeah I'd personally be more than happy with that.
><i> If this is temporary, it would be ok, provided we follows the usual
</I>><i> rules about handling updates.
</I>><i>
</I>><i> As we do not want to have untested rpms backported in */updates, this
</I>><i> mean that package must be checked by QA before ( and proper testing for
</I>><i> a new rpm is more that just checking it doesn't break ).
</I>><i>
</I>><i> So it should follow the proper policy ( once we agreed on that ).
</I>><i>
</I>><i> As discussed in the previous thread, that would for example mean that
</I>><i> the packager that submit the backport is not the one testing it and
</I>><i> giving the go, even if he can test before submitting to avoid wasting QA
</I>><i> time.
</I>
That all seems reasonable to me (although I think the QA people can also
be a bit "fast and loose" with some requests (obviously at their own
discretion) - e.g. I doubt they really need to massively test the impact
to other packages of adding something like dd_rescue, more just test
that it "runs OK")
><i> Since we want to restrict to package that people have used and missed
</I>><i> for upgrade, I would also add that this part should be checked and
</I>><i> requires :
</I>><i> - a bug report saying "upgrade failed due to that"
</I>><i> - if we want to be inclusive, a forum post could do the trick ( provided
</I>><i> it is in english, or a bug referencing the forum )
</I>><i> - package must be kept upgradable from mandriva 2010.1
</I>><i> - ideally, the upgrade path should be tested, but I am pretty sure that
</I>><i> people will not :).
</I>
Yeah I agree to that. I think that while you're right about testing the
upgrade and that it will likely not be fully tested, we can still do a
"what version does mdv 2010.2 have?, what version do we have? Will it
upgrade?" conceptual test (i.e. ask the questions!) which should cover
98.23% of the cases). (made up stat obviously!)
><i> Finally, I would also add that as soon a package is in updates or
</I>><i> release, the usual rules should apply ( ie, no more exception ). If I
</I>><i> push the package to */updates once getmail because it is missing, but
</I>><i> the next package do not go to */updates unless it fullfill the usual
</I>><i> rules. Any following backports goes to */backports.
</I>
Makes sense yes.
><i> And, just to be clear, the policy only apply to version 1, for x86_64
</I>><i> and i586.
</I>
WFM.
><i> One question would be "what is a pacakge requires a complex backport",
</I>><i> for example, someone yesterday asked for darcs, that requires ghc, that
</I>><i> requires bootstrapping.
</I>><i>
</I>><i> Yes, no ? Why ?
</I>
If this kind of thing crops up, I think we can discuss it at the time.
As we will have to go through QA process anyway (albeit fast tracked)
there will have to be some packager<->QA interaction anyway.
>>><i> If the problem is that backports were too buggy in the past, then we
</I>>>><i> should fix backports process, not bypassing them.
</I>>><i>
</I>>><i> I don't think this is particularly relevant. Backports are unsupported
</I>>><i> generally. That's a given.
</I>><i>
</I>><i> Before, it was Mandriva that said "we don't support backport", but we
</I>><i> can do thing differently.
</I>
True...
><i> We do offer them, we spoke of the application made by Stormi to manage
</I>><i> backports request ( among others ), and it was asked to install it on
</I>><i> our servers. So to me, for something unsupported, it seems to be rather
</I>><i> well integrated.
</I>
Well we didn't purposefully break backports before either, and of course
some people did look after it nicely. Just because it's not actively
supported doesn't necessarily mean it's not well integrated either. They
are not mutually exclusive.
><i> So the question is "what do people mean exactly when they say "backports
</I>><i> are unsupported" and what would it change when compared to updates,
</I>><i> which is supported by definition" ?
</I>><i>
</I>><i> Ie, I think we as a community support them to some extend, and so we
</I>><i> should explain what can people expect, and what they cannot.
</I>><i> And if possible, in a positive way ( as one issue we had with backport
</I>><i> was that people kept telling "do not use it", which is why people do not
</I>><i> use it ).
</I>><i>
</I>><i> Ie, I have a backport installed, would I receive new version, or not ?
</I>><i> I found a bug, can I fill it in bugs.mageia.org, or not ?
</I>><i> Etc, etc.
</I>
Yes, this makes sense.
>>><i> And if we start by pushing new version in update, people will soon
</I>>>><i> wonder why the new version of X is in updates, while the new version of
</I>>>><i> Y is not, just because we didn't have X in release and Y was there.
</I>>><i>
</I>>><i> I very much consider "nothing -> version X" quite different from
</I>>><i> "version X -> version Y". I don't think it's a hard concept for anyone
</I>>><i> to grasp.
</I>><i>
</I>><i> We kept telling to people that we do not want to place new version in
</I>><i> update, and if we start to do the contrary, this is not really coherent.
</I>><i>
</I>><i> So while this can be justified, I think we should take in account
</I>><i> communication with users to clearly explain why we do, and why this is
</I>><i> temporary.
</I>><i>
</I>><i> I guess a blog post would do the trick, so would you be volunteer for
</I>><i> that if needed ?
</I>
If required yeah I can write up the outcome of this once the dust has
settled :)
Cheers as always.
Col
--
Colin Guthrie
mageia(at)colin.guthr.ie
<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A>
Day Job:
Tribalogic Limited [<A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A>]
Open Source:
Mageia Contributor [<A HREF="http://www.mageia.org/">http://www.mageia.org/</A>]
PulseAudio Hacker [<A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A>]
Trac Hacker [<A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A>]
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="005346.html">[Mageia-dev] Missing packages in Mageia 1. How to backport?
</A></li>
<LI>Next message: <A HREF="005336.html">[Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#5364">[ date ]</a>
<a href="thread.html#5364">[ thread ]</a>
<a href="subject.html#5364">[ subject ]</a>
<a href="author.html#5364">[ 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>
|
