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
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Proposal of a backporting process
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20of%20a%20backporting%20process&In-Reply-To=%3CBANLkTikHL-W-P1zxfBQPKD%3D9CYVw%2BR9raA%40mail.gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="006011.html">
<LINK REL="Next" HREF="006014.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Proposal of a backporting process</H1>
<B>Ahmad Samir</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20of%20a%20backporting%20process&In-Reply-To=%3CBANLkTikHL-W-P1zxfBQPKD%3D9CYVw%2BR9raA%40mail.gmail.com%3E"
TITLE="[Mageia-dev] Proposal of a backporting process">ahmadsamir3891 at gmail.com
</A><BR>
<I>Sat Jun 25 21:22:20 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="006011.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI>Next message: <A HREF="006014.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6013">[ date ]</a>
<a href="thread.html#6013">[ thread ]</a>
<a href="subject.html#6013">[ subject ]</a>
<a href="author.html#6013">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On 25 June 2011 19:33, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote:
><i> Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
</I>>><i> On 24 June 2011 02:09, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">misc at zarb.org</A>> wrote:
</I>>><i> > Hi,
</I>>><i> >
</I>>><i> > as said in the thread of firefox 5, and in the meeting of packager
</I>>><i> > sooner this week, this is the first mail about backports ( on 3 ).
</I>>><i> >
</I>>><i> > So here is the proposal of a process, based on the feedback of people,
</I>>><i> > and the idea of some packagers ( mainly stormi ).
</I>>><i> >
</I>>><i> >
</I>>><i> > - Someone request a backport ( by bugzilla, by madb, by a email, by
</I>>><i> > taking a packager family in hostage, whatever ). I would prefer use
</I>>><i> > bugzilla but this may not be very user friendly, or too heavy.
</I>>><i>
</I>>><i> How would the packager get notified of backports requests via madb?
</I>><i>
</I>><i> There are several options :
</I>><i> - option 1 : maintainers prefer to have all backports requests in bugzilla.
</I>><i> Madb will then create backports requests via XML-RPC, with the original
</I>><i> reporter in CC maybe, and regularly watch bug report status. This will be
</I>><i> extra work on madb's side and force those users (who maybe don't know how to
</I>><i> use bugzilla) to use 1 tool for the request and a different tool for testing
</I>><i> reports, but why not.
</I>><i> - option 2 : maintainers are OK to use bugzilla for bugs and madb for package
</I>><i> requests => madb will query the maintainers database and notify the
</I>><i> maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too,
</I>><i> and provide a simple yet sufficient tracking system (status, comments).
</I>><i>
</I>
[...]
>><i>
</I>>><i> Would you elaborate on how bugzilla is heavy for a backports request?
</I>><i>
</I>><i> Heavy I don't know, but I think that we can give users a better tool to
</I>><i> request backports, see what backports already have been requested, etc.
</I>><i>
</I>
Yes, but what's wrong with bugzilla and better in the other tool?
>><i>
</I>>><i> > - a packager decide to do it. Based on the policy ( outlined in another
</I>>><i> > mail ), and maybe seeing with the maintainer first about that for non
</I>>><i> > trivial applications, the backport can be done, or not. The criterias
</I>>><i> > for being backported or not are not important to the process, just
</I>>><i> > assume that they exist for now ( and look at next mail ). So based on
</I>>><i> > criteria, someone say "it can be backported, so I do it".
</I>>><i>
</I>>><i> [...]
</I>>><i>
</I>>><i> > - I am not sure on this part, but basically, we have 2 choices :
</I>>><i> >  - the packager take the cauldron package and push to backport testing
</I>>><i> >  - the packager move the cauldron package in svn to backport, and there
</I>>><i> > send it to backport testing.
</I>>><i> >
</I>>><i> > Proposal 1 mean less work duplication, but proposal 2 let us do more
</I>>><i> > customization.
</I>>><i>
</I>>><i> Option 1 doesn't only mean not duplicating work, but also that the the
</I>>><i> spec in backports svn isn't ever out-dated; the only reason I see a
</I>>><i> package being in stable distro SVN is if it's in /release|updates, not
</I>>><i> backports...
</I>><i>
</I>><i> I'm not sure I understand your point. What do you mean with out-dated specs in
</I>><i> backports ?
</I>
The cauldron one got some changes/patches, the one in backports didn't
get them => outdated.
><i> I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make
</I>><i> it simple for packagers) because it allows to cope with the following
</I>><i> situation :
</I>><i> - foo is in version 1.2.2 in release|updates
</I>><i> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
</I>><i> the next stable release
</I>><i> - the latest release in the 1.x branch, 1.3.0, brings many features requested
</I>><i> by some users, we want to provide it as a backport : with option 1 we can't,
</I>><i> with option 2 we can.
</I>><i>
</I>><i> or :
</I>><i> - foo is in version 1.2.2 in release|updates
</I>><i> - foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for
</I>><i> the next stable release
</I>><i> - we had backported version 1.2.6 before switching to 2.0alpha in cauldron
</I>><i> - the backported version 1.2.6 has a big bug we hadn't spotted during tests
</I>><i> and we want to fix in the backport : with option 1 we can't, with option 2 we
</I>><i> can.
</I>><i>
</I>><i> So, for me, this is definitely option 2.
</I>><i>
</I>
Good point, but now we're not really talking about backports any more,
I think; we're talking about having a second "updates" repo but with
version bumps allowed, which sort of negates the backports repos
criteria that was used in mdv all those years.... I can't help but
think that in some cases that will be promising support that we can't
afford to give to begin with.
The whole "backports isn't officially supported" was/is a sort of CYA*
motto, like the "the beverage you're about to drink is hot" on
Starbucks coffee cups (if the customer doesn't already know coffee is
served hot, then there's something fundamentally wrong somewhere in
his head), it's just there so that when someone sues, they have a way
out, that's all it is.
I've seen backported packages get repushed with fixes when needed,
that's support AFAICT.
* CYA == cover your ass.
><i> However, I think it must be made a painless as possible to packagers :
</I>><i> - in the common case, allow to submit directly from cauldron to the backports
</I>><i> media, but let the BS detect that and automatically do the SVN copy part.
</I>><i> - for the situations I described above, work with the backport branch
</I>><i> similarly as we work on updates (technically speaking : SVN, BS...).
</I>><i>
</I>><i>
</I>>><i>
</I>>><i> > if the package doesn't build, the packager fix ( or drop the idea if
</I>>><i> > this requires too much work )
</I>>><i> >
</I>>><i> > - the packager send requesting feedback about the backport from the
</I>>><i> > people who requested it, and test it as well.
</I>>><i>
</I>>><i> Probably off-topic, but how will that work with madb? i.e. how will
</I>>><i> the maintainer get the feedback?
</I>><i>
</I>><i> I partially answered above : either via bugzilla, or via a simple tracking
</I>><i> system included in madb for that need. It will depend on the chosen process,
</I>><i> we'll try to adapt the tool to the situation.
</I>><i>
</I>><i>
</I>><i> Best regards
</I>><i>
</I>><i> Samuel Verschelde
</I>><i>
</I>
--
Ahmad Samir
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="006011.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI>Next message: <A HREF="006014.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6013">[ date ]</a>
<a href="thread.html#6013">[ thread ]</a>
<a href="subject.html#6013">[ subject ]</a>
<a href="author.html#6013">[ 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>
|
