Re: [Mageia-dev] Proposal of a backporting process
mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto: A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. Well my point is i often backport something for my job (for the most commoncpp2 now, ucommon in future), and since they are libraries i can fall in errors. I always tested before backporting though, and i haven't had any problems upgrading, but that's me and i could have been lucky. If we can accept some exceptions from time to time, but proved (bug open, testing and updates/backports etc) i can think to have mageia not only at home or in a virtual box. Otherwise i can't see the need of backports, for me of course. Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Proposal of a backporting process
2011/6/29 Angelo Naselli anase...@linux.it: mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto: A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. Well my point is i often backport something for my job (for the most commoncpp2 now, ucommon in future), and since they are libraries i can fall in errors. I always tested before backporting though, and i haven't had any problems upgrading, but that's me and i could have been lucky. If we can accept some exceptions from time to time, but proved (bug open, testing and updates/backports etc) i can think to have mageia not only at home or in a virtual box. Otherwise i can't see the need of backports, for me of course. As this is being discussed we have a nice practical example in the forum: https://forums.mageia.org/en/viewtopic.php?f=8t=667 A guy is using Mageia 1 which provides lyx 1.6. He already has several documents done with lyx 2.0, so he needs lyx 2.0 in Mageia. Now lyx 2.0 is in Cauldron. Say the guy does not want to use Cauldron because of the risk of instability. This is a perfect use case for a backport of lyx 2.0 for Mageia 1. How would we go about that according to policy? -- wobo
Re: [Mageia-dev] Proposal of a backporting process
Le mercredi 29 juin 2011 à 10:56 +0200, Angelo Naselli a écrit : mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto: A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. Well my point is i often backport something for my job (for the most commoncpp2 now, ucommon in future), and since they are libraries i can fall in errors. I always tested before backporting though, and i haven't had any problems upgrading, but that's me and i could have been lucky. If we can accept some exceptions from time to time, but proved (bug open, testing and updates/backports etc) i can think to have mageia not only at home or in a virtual box. Otherwise i can't see the need of backports, for me of course. If we start to add exception while we do not even have started to agree on the general case, we are never gonna go anywhere :) I have the impression that everybody want to be able at the same time to backport anything, and yet expect to have the same level of support and quality, and without using any more ressources. Technically, anything could be backported with proper tests. After all, that's roughly the process we use for cauldron ( ie, take a new version of software, compile it on the distribution, and build later others software against that ). Every software have someone interested, from low level like kernel ( backported on kernel-linus, asked by people as seen on MIB ), or gcc ( gcc 4.6 being my main motivation for keeping a cooker installation ) to higher level like gajim or midori. The only thing that no one would be interested is stuff that do not move ( at, linpng, etc ), ie everything were there is no new features, and working fine. And even, people could want to have a new feature, such as systemd, etc. So in the end, if we want to satisfy everybody, the answer is to have no policy forbidding anything and just say do proper amount of QA. That's fine by me ( especially since I do not use backports ), but we have to agree on that. -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
mercoledì 29 giugno 2011 alle 15:37, Michael Scherer ha scritto: If we start to add exception while we do not even have started to agree on the general case, we are never gonna go anywhere :) Yes sorry, that was not my intention :) I do believe we're an open community and as in every open community we, and I first, don't impose just talk and decide. So every decision will be taken is fine for me. Said that what i meant was, if someone open a backport request, and there are people who can take care about, that should not close by default if does not respect all the policies, and that's for the same reason of openness... Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Proposal of a backporting process
Op woensdag 29 juni 2011 17:28:30 schreef Angelo Naselli: mercoledì 29 giugno 2011 alle 15:37, Michael Scherer ha scritto: If we start to add exception while we do not even have started to agree on the general case, we are never gonna go anywhere :) Yes sorry, that was not my intention :) I do believe we're an open community and as in every open community we, and I first, don't impose just talk and decide. So every decision will be taken is fine for me. Said that what i meant was, if someone open a backport request, and there are people who can take care about, that should not close by default if does not respect all the policies, and that's for the same reason of openness... Angelo actually, perhaps we should implement a strict policy, and if people wish to deviate, i have an urpmi-proxy program, that has local overrides, in general, it requests stuff from an external mirror, and you can also have a local repository, and if you use the proxy, it can sort of backport whatever you want if you rebuild it yourself in your local repos.
Re: [Mageia-dev] Proposal of a backporting process
Michael Scherer a écrit : Le mercredi 29 juin 2011 à 10:56 +0200, Angelo Naselli a écrit : mercoledì 29 giugno 2011 alle 00:23, andre999 ha scritto: A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. Well my point is i often backport something for my job (for the most commoncpp2 now, ucommon in future), and since they are libraries i can fall in errors. I always tested before backporting though, and i haven't had any problems upgrading, but that's me and i could have been lucky. If we can accept some exceptions from time to time, but proved (bug open, testing and updates/backports etc) i can think to have mageia not only at home or in a virtual box. Otherwise i can't see the need of backports, for me of course. If we start to add exception while we do not even have started to agree on the general case, we are never gonna go anywhere :) I have the impression that everybody want to be able at the same time to backport anything, and yet expect to have the same level of support and quality, and without using any more ressources. Technically, anything could be backported with proper tests. After all, that's roughly the process we use for cauldron ( ie, take a new version of software, compile it on the distribution, and build later others software against that ). Every software have someone interested, from low level like kernel ( backported on kernel-linus, asked by people as seen on MIB ), or gcc ( gcc 4.6 being my main motivation for keeping a cooker installation ) to higher level like gajim or midori. The only thing that no one would be interested is stuff that do not move ( at, linpng, etc ), ie everything were there is no new features, and working fine. And even, people could want to have a new feature, such as systemd, etc. So in the end, if we want to satisfy everybody, the answer is to have no policy forbidding anything and just say do proper amount of QA. That's fine by me ( especially since I do not use backports ), but we have to agree on that. I see this as an argument for having simple, clean basic rules (the general case), on which we can have well-defined exceptions, some (or all) of which may require case-by-case approval. So let's accept the initial proposal as the base rules. Then define some well-defined exceptions, for use cases that fall outside these base rules. And whether each particular exception should require case-by-case approval. -- André
Re: [Mageia-dev] Proposal of a backporting process
domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Proposal of a backporting process
Le mardi 28 juin 2011 à 09:25 +0200, Angelo Naselli a écrit : domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? if B use A, that mean that A is not a leave package, since something requires it. Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. Yes. There is a moment where we need to answer do we want to backport all cauldron on stable, which is basically what we incrementally do with cauldron, or do we just backport a subset of application where we can do enough QA because changes are small enough ? I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Proving is easy. The package in release must have a higher EVR than those on backports. But if we let people do cherry picking, this is much harder. -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
Angelo Naselli a écrit : domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Angelo A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. -- André
Re: [Mageia-dev] Proposal of a backporting process
'Twas brillig, and Michael Scherer at 25/06/11 23:16 did gyre and gimble: we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). I've seen various ppa-purge commands being dished out for custom PPAs on Ubuntu. It looks like quite a nice idea, but only really applies for individual use archives (e.g. help us test the development version of $foo), not a general purpose one like backports. That said, a GUI which detected that certain packages have come from backports and offers and easy mechanism to switch back to the older one from release or updates would, IMO, be a plus. Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Proposal of a backporting process
On Mon, 27 Jun 2011 20:17:22 +0100 Colin Guthrie wrote: 'Twas brillig, and Michael Scherer at 25/06/11 23:16 did gyre and gimble: we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). I've seen various ppa-purge commands being dished out for custom PPAs on Ubuntu. It looks like quite a nice idea, but only really applies for individual use archives (e.g. help us test the development version of $foo), not a general purpose one like backports. That said, a GUI which detected that certain packages have come from backports and offers and easy mechanism to switch back to the older one from release or updates would, IMO, be a plus. Rpms from Tainted have 'tainted' in the filename - why not do the same for backports? Surely that would make their identification a little simpler? John NZ
Re: [Mageia-dev] Proposal of a backporting process
Le mardi 28 juin 2011 à 09:55 +1200, John a écrit : On Mon, 27 Jun 2011 20:17:22 +0100 Colin Guthrie wrote: That said, a GUI which detected that certain packages have come from backports and offers and easy mechanism to switch back to the older one from release or updates would, IMO, be a plus. Rpms from Tainted have 'tainted' in the filename - why not do the same for backports? Surely that would make their identification a little simpler? Detection is not that hard. If the release is superior to the one in release/update, this is a backport. That's trivial from a conception point of view. -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
Samuel Verschelde a écrit : Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Schererm...@zarb.org wrote: ... - 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 ? 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. Given this explanation, I would definitely go for option 2 as well. 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...). Sound good to me. if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? 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. I tend to like the idea of using bugzilla with a streamlined template, to avoid unnecessary duplication of code to be maintained. But if madb can track things better, and it can be readily developed, that sounds good. As for packagers, it shouldn't make much difference if the tools are done right. Best regards Samuel Verschelde Regards -- André
Re: [Mageia-dev] Proposal of a backporting process
Op zondag 26 juni 2011 00:16:59 schreef Michael Scherer: [...] we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). that's not a bad idea, what is the best way to revert? is that with --old- package ? what if the package has been removed on mirrors? (ie: due to more recent updates)
Re: [Mageia-dev] Proposal of a backporting process
I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). that's not a bad idea, what is the best way to revert? is that with --old- package ? Maybe I'm stupid, but rpmdrake does not have any option to downgrade a package. To my knowledge, the only GUI in this world that has such an option (in a menu) is Synaptic, but Synaptic itself ceases to be the default GUI package manager in *buntu 11.11. And man urpmi does not assist the user into downgrading a package. Frankly, I don't know how to protect a package from being updated, the way I can do it with yum (or the way I can hold a package with dpkg, aptitude or dselect). Of course, I am not that familiar with Mageia (or Mandriva), or rather I treated Mageia (and Mandriva) as distros where I should use the GUI tools or the default options of the CLI tools and not bother much -- otherwise, why using mga/mdv and not something else? R-C aka beranger
Re: [Mageia-dev] Proposal of a backporting process
26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. -- Sander
Re: [Mageia-dev] Proposal of a backporting process
Op zondag 26 juni 2011 12:10:14 schreef Sander Lepik: 26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. that is exactly what i meant, sometimes these can be big dependencies, and i've used once or twice --oldpackage in rpm i guess some extra work could be wanted to have this in urpmi and possibly rpmdrake
Re: [Mageia-dev] Proposal of a backporting process
Le dimanche 26 juin 2011 à 13:10 +0300, Sander Lepik a écrit : 26.06.2011 12:35, Michael Scherer kirjutas: urpme package; urpmi package That's not so easy if something depends on that package. How hard is it to implement rpm's --oldpackage to urpmi? I really don't know but i hope it's nothing too hard. See the thread about policy, and the part about only packages that nothing requires should be backported. Regarding the rollback ( because, that's how it is called ), there is a lot of conference dedicated on this topic, the latest one being that http://www.slideshare.net/johngt/improving-rollback-in-linux-via-dsl-approach-distributing , just before the one I gave about mageia at FOSDEM. You can also take a look at the mancoosi research project, read the discussion over that at cooker@ ( somewhere around http://lists.mandriva.com/cooker/2010-11/msg00401.php ), and read the rest of the thread where it was already proposed : http://www.mageia.org/pipermail/mageia-dev/20101008/001021.html ( point 4 ). -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ). So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - 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. - 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 ? 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...). if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? 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
Re: [Mageia-dev] Proposal of a backporting process
Op zaterdag 25 juni 2011 19:33:15 schreef Samuel Verschelde: [...] 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 would prefer to keep things separate, an mgarepo switch command or even a mgarepo backport shortcut, then current branch/revision/whatever could be made into backports or something... and from then on, you can submit like normal
Re: [Mageia-dev] Proposal of a backporting process
Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit : On 25 June 2011 19:33, Samuel Verschelde sto...@laposte.net wrote: Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Scherer m...@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
Re: [Mageia-dev] Proposal of a backporting process
On 25 June 2011 22:15, Samuel Verschelde sto...@laposte.net wrote: Le samedi 25 juin 2011 21:22:20, Ahmad Samir a écrit : On 25 June 2011 19:33, Samuel Verschelde sto...@laposte.net wrote: Le vendredi 24 juin 2011 21:39:51, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Scherer m...@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. 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
Re: [Mageia-dev] Proposal of a backporting process
On Sat, Jun 25, 2011 at 11:15 PM, Wolfgang Bornath molc...@googlemail.com wrote: The Request Backport Button could be a solution for non-english speakers. They can not use Bugzilla because they can not write in English to make their request understood, but they can find the package name in a database and understand the function of a button which reads Backport. -- wobo well used i think this can be really good.
Re: [Mageia-dev] Proposal of a backporting process
Le vendredi 24 juin 2011 à 22:39 +0300, Ahmad Samir a écrit : On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ). So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - 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. Would you elaborate on how bugzilla is heavy for a backports request? It requires a more formal process, requires to fill a proper bug ( thus either requesting more experience, or more work from triaging ). While bugzilla would work, I think we could have a more streamlined and direct way of requesting backport. Maybe a custom template in bugzilla would do the trick. - based on feedback ( ie if the package work or if the packager is confident ), the packager decide to move it to backport for everybody, using some stuff similar to rpmctl ( the tool we used to move package at Mandriva ). The tool would also send notifications. The packager decides to move it and he has the necessary privileges to do so? or will he have to request someone from another team to move it? The packager decide to move. This way : - packages are not sent untested, thus raising confidence in backports How many times did backports breaks a user's whole installation? Not often. But the issue is not if the system is broken beyond repair, as it didn't happen, and would surely not happen with the proposed policy. But even if system work, people will perceive backport has being unreliable if some of them do not work. we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? I a not sure that most people realize they can revert. Maybe a easier interface to do that could be offered ( along maybe with a tool that send feedback on why it did downgrade it ? ). -- Michael Scherer
Re: [Mageia-dev] Proposal of a backporting process
- 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. copy i believe. IIUC we should branch cauldron into stable relases for that package, but what happens if the package already exists? I mean foo 1.0.0 is in stable, a foo 1.1.0 is required and could be backported into stable branch... we have two foo programs with their own story. WDYT ? I like the second option, but in such a way we should provide upgrades from a stable with backports, since they follow a good feedback policy before going to stable. I understand QA and sysadmins are not overloaded, but there's not so much difference between updates and backports then... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Proposal of a backporting process
Michael Scherer a écrit : ... - Someone request a backport ... - a packager decide to 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. ... This way : - packages are not sent untested, thus raising confidence in backports - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? Overall I think that it is an excellent approach, for the reasons given. I don't yet understand the difference between proposal 1 and 2, so for the moment I don't have a preference. Even though bugzilla might seem a bit cumbersome for requesting backports, otherwise I think that it is an excellent tool for this purpose. We could perhaps have some sort of shortcut for filing backport requests. -- André
Re: [Mageia-dev] Proposal of a backporting process
On 24 June 2011 02:09, Michael Scherer m...@zarb.org wrote: Hi, as said in the thread of firefox 5, and in the meeting of packager sooner this week, this is the first mail about backports ( on 3 ). So here is the proposal of a process, based on the feedback of people, and the idea of some packagers ( mainly stormi ). - 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? Would you elaborate on how bugzilla is heavy for a backports 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... if the package doesn't build, the packager fix ( or drop the idea if this requires too much work ) - the packager send requesting feedback about the backport from the people who requested it, and test it as well. Probably off-topic, but how will that work with madb? i.e. how will the maintainer get the feedback? - based on feedback ( ie if the package work or if the packager is confident ), the packager decide to move it to backport for everybody, using some stuff similar to rpmctl ( the tool we used to move package at Mandriva ). The tool would also send notifications. The packager decides to move it and he has the necessary privileges to do so? or will he have to request someone from another team to move it? - if the package doesn't work, he either fix, or drop the backport idea. If he fix, we go back on testing, if he drop, we remove the rpm ( with a automated cleaning of rpm after 1 or 2 months ). [..] If the packager drop the backport, it should be notified to the requester ( hence the use of bugzilla, or a more suitable tool ) Agreed. This way : - packages are not sent untested, thus raising confidence in backports How many times did backports breaks a user's whole installation? we always say that backports should mainly be cherry picked, but not enabled all the time... so how does installing a new version of e.g. wine break the user's system when he can easily back out that rpm? - the QA should not be overloaded, and can focus on updates - sysadmins are not overloaded - people requesting backport see how QA work, and are involved into the distribution as testers, thus creating a much healthier discussion with packagers, and creating more incentive to help. And since they request the package, they will be motivated to test more than stuff they do not use. WDYT ? -- Michael Scherer -- Ahmad Samir
