diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006010.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006010.html | 168 |
1 files changed, 168 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006010.html b/zarb-ml/mageia-dev/2011-June/006010.html new file mode 100644 index 000000000..4add0cbfa --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006010.html @@ -0,0 +1,168 @@ +<!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=%3C201106251933.15549.stormi%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="005998.html"> + <LINK REL="Next" HREF="006011.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Proposal of a backporting process</H1> + <B>Samuel Verschelde</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Proposal%20of%20a%20backporting%20process&In-Reply-To=%3C201106251933.15549.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal of a backporting process">stormi at laposte.net + </A><BR> + <I>Sat Jun 25 19:33:15 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="005998.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="006011.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6010">[ date ]</a> + <a href="thread.html#6010">[ thread ]</a> + <a href="subject.html#6010">[ subject ]</a> + <a href="author.html#6010">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : +><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> +There are several options : +- option 1 : maintainers prefer to have all backports requests in bugzilla. +Madb will then create backports requests via XML-RPC, with the original +reporter in CC maybe, and regularly watch bug report status. This will be +extra work on madb's side and force those users (who maybe don't know how to +use bugzilla) to use 1 tool for the request and a different tool for testing +reports, but why not. +- option 2 : maintainers are OK to use bugzilla for bugs and madb for package +requests => madb will query the maintainers database and notify the +maintainer(s) by mail. It could, like bugzilla, send notifications to a ML too, +and provide a simple yet sufficient tracking system (status, comments). + +><i> +</I>><i> Would you elaborate on how bugzilla is heavy for a backports request? +</I> +Heavy I don't know, but I think that we can give users a better tool to +request backports, see what backports already have been requested, etc. + +><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'm not sure I understand your point. What do you mean with out-dated specs in +backports ? +I favor option 2 (with all needed useful shortcuts in mgarepo and BS to make +it simple for packagers) because it allows to cope with the following +situation : +- foo is in version 1.2.2 in release|updates +- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for +the next stable release +- the latest release in the 1.x branch, 1.3.0, brings many features requested +by some users, we want to provide it as a backport : with option 1 we can't, +with option 2 we can. + +or : +- foo is in version 1.2.2 in release|updates +- foo is in version 2.0alpha in cauldron, full of bugs but hopefully ready for +the next stable release +- we had backported version 1.2.6 before switching to 2.0alpha in cauldron +- the backported version 1.2.6 has a big bug we hadn't spotted during tests +and we want to fix in the backport : with option 1 we can't, with option 2 we +can. + +So, for me, this is definitely option 2. + +However, I think it must be made a painless as possible to packagers : +- in the common case, allow to submit directly from cauldron to the backports +media, but let the BS detect that and automatically do the SVN copy part. +- for the situations I described above, work with the backport branch +similarly as we work on updates (technically speaking : SVN, BS...). + + +><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 partially answered above : either via bugzilla, or via a simple tracking +system included in madb for that need. It will depend on the chosen process, +we'll try to adapt the tool to the situation. + + +Best regards + +Samuel Verschelde +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="005998.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="006011.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6010">[ date ]</a> + <a href="thread.html#6010">[ thread ]</a> + <a href="subject.html#6010">[ subject ]</a> + <a href="author.html#6010">[ 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> |