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