[Mageia-dev] Proposal of a backporting process

Sat Jun 25 22:15:37 CEST 2011

Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit :
+> On 25 June 2011 19:33, Samuel Verschelde <stormi at laposte.net> wrote:
+> > Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit :
+> >> On 24 June 2011 02:09, Michael Scherer <misc at zarb.org> wrote:
+> >> > - Someone request a backport ( by bugzilla, by madb, by a email, by
+> >> > taking a packager family in hostage, whatever ). I would prefer use
+> >> > bugzilla but this may not be very user friendly, or too heavy.
+> >> 
+> >> How would the packager get notified of backports requests via madb?
+> > 
+> > 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).
+> 
+> [...]
+> 
+> >> Would you elaborate on how bugzilla is heavy for a backports request?
+> > 
+> > 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.
+> 
+> Yes, but what's wrong with bugzilla and better in the other tool?
+
+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".
+
+> 
+> >> > - a packager decide to do it. Based on the policy ( outlined in
+> >> > another mail ), and maybe seeing with the maintainer first about that
+> >> > for non trivial applications, the backport can be done, or not. The
+> >> > criterias for being backported or not are not important to the
+> >> > process, just assume that they exist for now ( and look at next mail
+> >> > ). So based on criteria, someone say "it can be backported, so I do
+> >> > it".
+> >> 
+> >> [...]
+> >> 
+> >> > - I am not sure on this part, but basically, we have 2 choices :
+> >> >  - the packager take the cauldron package and push to backport testing
+> >> >  - the packager move the cauldron package in svn to backport, and
+> >> > there send it to backport testing.
+> >> > 
+> >> > Proposal 1 mean less work duplication, but proposal 2 let us do more
+> >> > customization.
+> >> 
+> >> Option 1 doesn't only mean not duplicating work, but also that the the
+> >> spec in backports svn isn't ever out-dated; the only reason I see a
+> >> package being in stable distro SVN is if it's in /release|updates, not
+> >> backports...
+> > 
+> > I'm not sure I understand your point. What do you mean with out-dated
+> > specs in backports ?
+> 
+> The cauldron one got some changes/patches, the one in backports didn't
+> get them => outdated.
+
+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 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.
+> 
+> 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'm not sure. See misc's backport policy proposal : it's very close to 
+Mandriva's. 
+
+> 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.
+
+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
+