diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006014.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006014.html | 199 |
1 files changed, 199 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006014.html b/zarb-ml/mageia-dev/2011-June/006014.html new file mode 100644 index 000000000..8b5247339 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006014.html @@ -0,0 +1,199 @@ +<!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=%3C201106252215.37716.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="006013.html"> + <LINK REL="Next" HREF="006015.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=%3C201106252215.37716.stormi%40laposte.net%3E" + TITLE="[Mageia-dev] Proposal of a backporting process">stormi at laposte.net + </A><BR> + <I>Sat Jun 25 22:15:37 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006013.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="006015.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6014">[ date ]</a> + <a href="thread.html#6014">[ thread ]</a> + <a href="subject.html#6014">[ subject ]</a> + <a href="author.html#6014">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit : +><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> +Bugzilla is an issue tracker, and is centered on that concept. I think that a +simple "request backport" button in a package database browsing application +can be easier and more efficient, in that the "need" will be more easily +transmitted from the user to the packager. The backports requests we get today +(and got back in mandriva) don't represent the majority of needs. I'd like to +see what happens if users have a dead simple way to request them. + +Plus, as we want to transform "requester" into "tester", the more requests we +can get, the more users we have a chance to turn into testers... And maybe +more + +I'm almost sure madb will have such a "request backport" button. It was +planned in the original specs. There's still to decide what this button does : +option 1 or option 2 above, or even (but not my choice) a redirect to a +prefilled form in bugzilla. + +There's one point that for me favors the use of a dedicated tool : the fact +that several users can request the same backport. Madb will be store existing +requests and associate new requesters to them if needed. This way : +- we will have means to see the most demanded backports +- there will be only one (if any) associated bugzilla request, and once madb +detects that the backport is available for testing, it will notify all +associated users, and once available for good too. +I think it's easier this way than asking to users to "check if there's already +a backport request for this program and add yourself in CC to the bug report +if there's one, otherwise create a new backport request". + +><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 see. You mean that once the backport has its own branch, updating it from +cauldron becomes difficult because each branch lives its own life. + +My proposal that the BS allows a direct jump from cauldron to backport, taking +care by itself of the SVN copying part can solve this problem I think. + +><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'm not sure. See misc's backport policy proposal : it's very close to +Mandriva's. + +><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'd like us to try our best then, but remember that we're also trying to use +backport and software requests as a catalyst to get more testers and maybe +even more packagers. +Maybe even (let's dream :)) we will become known as a distribution where it's +easy to get newer versions of software and attract more users, which we will +try to turn into contributers in the end and then just rule the world :P + +Samuel +</PRE> + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006013.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI>Next message: <A HREF="006015.html">[Mageia-dev] Proposal of a backporting process +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6014">[ date ]</a> + <a href="thread.html#6014">[ thread ]</a> + <a href="subject.html#6014">[ subject ]</a> + <a href="author.html#6014">[ 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> |