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
|
<!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=%3CBANLkTikay_%3DfuBTnODXiEx1Q9QMm3me93A%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="006014.html">
<LINK REL="Next" HREF="006016.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=%3CBANLkTikay_%3DfuBTnODXiEx1Q9QMm3me93A%40mail.gmail.com%3E"
TITLE="[Mageia-dev] Proposal of a backporting process">ahmadsamir3891 at gmail.com
</A><BR>
<I>Sat Jun 25 22:53:03 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="006014.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI>Next message: <A HREF="006016.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6015">[ date ]</a>
<a href="thread.html#6015">[ thread ]</a>
<a href="subject.html#6015">[ subject ]</a>
<a href="author.html#6015">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>On 25 June 2011 22:15, Samuel Verschelde <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-dev">stormi at laposte.net</A>> wrote:
><i> Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
</I>>><i> 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>>><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> >> > - 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
</I>>><i> > bugzilla. Madb will then create backports requests via XML-RPC, with the
</I>>><i> > original reporter in CC maybe, and regularly watch bug report status.
</I>>><i> > This will be extra work on madb's side and force those users (who maybe
</I>>><i> > don't know how to use bugzilla) to use 1 tool for the request and a
</I>>><i> > different tool for testing reports, but why not.
</I>>><i> > - option 2 : maintainers are OK to use bugzilla for bugs and madb for
</I>>><i> > package requests => madb will query the maintainers database and notify
</I>>><i> > the maintainer(s) by mail. It could, like bugzilla, send notifications
</I>>><i> > to a ML too, and provide a simple yet sufficient tracking system
</I>>><i> > (status, comments).
</I>>><i>
</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>>><i> Yes, but what's wrong with bugzilla and better in the other tool?
</I>><i>
</I>><i> Bugzilla is an issue tracker, and is centered on that concept. I think that a
</I>><i> simple "request backport" button in a package database browsing application
</I>><i> can be easier and more efficient, in that the "need" will be more easily
</I>><i> transmitted from the user to the packager. The backports requests we get today
</I>><i> (and got back in mandriva) don't represent the majority of needs. I'd like to
</I>><i> see what happens if users have a dead simple way to request them.
</I>><i>
</I>
You want to interface for users, so that they don't have to deal with
a 1minute-to-fill bug report to request a backport... that's your
prerogative, I don' have a problem with that as long as it works.
><i> Plus, as we want to transform "requester" into "tester", the more requests we
</I>><i> can get, the more users we have a chance to turn into testers... And maybe
</I>><i> more
</I>><i>
</I>
"Tester" will have to use bugzilla, as that's the designated tool to
contact devs/packagers... so maybe it's a good chance users become
familiar with bugzilla?
><i> I'm almost sure madb will have such a "request backport" button. It was
</I>><i> planned in the original specs. There's still to decide what this button does :
</I>><i> option 1 or option 2 above, or even (but not my choice) a redirect to a
</I>><i> prefilled form in bugzilla.
</I>><i>
</I>><i> There's one point that for me favors the use of a dedicated tool : the fact
</I>><i> that several users can request the same backport. Madb will be store existing
</I>><i> requests and associate new requesters to them if needed. This way :
</I>><i> - we will have means to see the most demanded backports
</I>><i> - there will be only one (if any) associated bugzilla request, and once madb
</I>><i> detects that the backport is available for testing, it will notify all
</I>><i> associated users, and once available for good too.
</I>><i> I think it's easier this way than asking to users to "check if there's already
</I>><i> a backport request for this program and add yourself in CC to the bug report
</I>><i> if there's one, otherwise create a new backport request".
</I>><i>
</I>
FWIW, such kind of duplicate reports is easy to spot and marking one
bug as a dupe of another adds the user to CC automatically.
Again, I am not with or against using madb, simply because I've not
seen in action and can't judge it.
>><i>
</I>>><i> >> > - a packager decide to do it. Based on the policy ( outlined in
</I>>><i> >> > another mail ), and maybe seeing with the maintainer first about that
</I>>><i> >> > for non trivial applications, the backport can be done, or not. The
</I>>><i> >> > criterias for being backported or not are not important to the
</I>>><i> >> > process, just assume that they exist for now ( and look at next mail
</I>>><i> >> > ). So based on criteria, someone say "it can be backported, so I do
</I>>><i> >> > 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
</I>>><i> >> > there 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
</I>>><i> > specs in backports ?
</I>>><i>
</I>>><i> The cauldron one got some changes/patches, the one in backports didn't
</I>>><i> get them => outdated.
</I>><i>
</I>><i> I see. You mean that once the backport has its own branch, updating it from
</I>><i> cauldron becomes difficult because each branch lives its own life.
</I>><i>
</I>><i> My proposal that the BS allows a direct jump from cauldron to backport, taking
</I>><i> care by itself of the SVN copying part can solve this problem I think.
</I>><i>
</I>>><i>
</I>>><i> > I favor option 2 (with all needed useful shortcuts in mgarepo and BS to
</I>>><i> > make it simple for packagers) because it allows to cope with the
</I>>><i> > following 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
</I>>><i> > ready for the next stable release
</I>>><i> > - the latest release in the 1.x branch, 1.3.0, brings many features
</I>>><i> > requested by some users, we want to provide it as a backport : with
</I>>><i> > option 1 we can't, 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
</I>>><i> > ready for the next stable release
</I>>><i> > - we had backported version 1.2.6 before switching to 2.0alpha in
</I>>><i> > cauldron - the backported version 1.2.6 has a big bug we hadn't spotted
</I>>><i> > during tests and we want to fix in the backport : with option 1 we
</I>>><i> > can't, with option 2 we can.
</I>>><i> >
</I>>><i> > So, for me, this is definitely option 2.
</I>>><i>
</I>>><i> Good point, but now we're not really talking about backports any more,
</I>>><i> I think; we're talking about having a second "updates" repo but with
</I>>><i> version bumps allowed, which sort of negates the backports repos
</I>>><i> criteria that was used in mdv all those years....
</I>><i>
</I>><i> I'm not sure. See misc's backport policy proposal : it's very close to
</I>><i> Mandriva's.
</I>><i>
</I>>><i> I can't help but
</I>>><i> think that in some cases that will be promising support that we can't
</I>>><i> afford to give to begin with.
</I>><i>
</I>><i> I'd like us to try our best then, but remember that we're also trying to use
</I>><i> backport and software requests as a catalyst to get more testers and maybe
</I>><i> even more packagers.
</I>><i> Maybe even (let's dream :)) we will become known as a distribution where it's
</I>><i> easy to get newer versions of software and attract more users, which we will
</I>><i> try to turn into contributers in the end and then just rule the world :P
</I>><i>
</I>><i> Samuel
</I>><i>
</I>
IIUC, the whole idea behind backports, is having an easy way for
packagers to offer new versions of desktop application packages for
users, emphasis on "easy"; based on the cauldron (cooker back in the
day) SVN, the packager submits a new package to backports. That worked
most of the times. I've seen anyone giving numbers/statistics on how
many backports actually didn't work for the users.
So, yes, I am all for improving the process, but without complicating
it too much.
--
Ahmad Samir
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="006014.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI>Next message: <A HREF="006016.html">[Mageia-dev] Proposal of a backporting process
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6015">[ date ]</a>
<a href="thread.html#6015">[ thread ]</a>
<a href="subject.html#6015">[ subject ]</a>
<a href="author.html#6015">[ 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>
|
