On 25 June 2011 22:15, Samuel Verschelde <[email protected]> wrote: > Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit : >> On 25 June 2011 19:33, Samuel Verschelde <[email protected]> wrote: >> > Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : >> >> On 24 June 2011 02:09, Michael Scherer <[email protected]> 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. >
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. > 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 > "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'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". > 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. >> >> >> > - 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 > 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
