diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006013.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006013.html | 205 |
1 files changed, 205 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006013.html b/zarb-ml/mageia-dev/2011-June/006013.html new file mode 100644 index 000000000..13c507503 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006013.html @@ -0,0 +1,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> |