Re: [Mageia-dev] Backports policy proposal
In data venerdì 24 giugno 2011 08:30:15, Maarten Vanraes ha scritto: Op vrijdag 24 juni 2011 02:10:14 schreef Michael Scherer: [...] Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. [..] This seems hard to enforce... i can imagine if you make backport, it has essentially the same version as in cauldron, i can think that there is a few spec file changes that are only for backports, and thus the release becomes newer than the one in cauldron I'm confused :/ %mkrel was born to avoid that am i worng? -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Backports policy proposal
Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto: Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... +1, i just had problem when the pacakges where backported into 2010.1 and that broke the upgrade to mageia 1... Well here it just mean we probably failed to check backports package :/ -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Backports policy proposal
In data sabato 25 giugno 2011 15:27:01, Balcaen John ha scritto: Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto: Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... +1, i just had problem when the pacakges where backported into 2010.1 and that broke the upgrade to mageia 1... Well here it just mean we probably failed to check backports package :/ Well indeed i've realized later, i should have been carefull in backporting 2010.1... but 2010.1 is not mageia 1 and mag2 should upgrade mga1... even if i have some doubt after mageia 9 (mga9-mga10) ... -- Angelo signature.asc Description: This is a digitally signed message part.
[Mageia-dev] No sound with Soundblaster in Mageia 1
hi all, can anyone take a look at this bug? it is the first bug filled by one of our italian community users, i proposed him to fill and i don't want to make a poor showing : ) https://bugs.mageia.org/show_bug.cgi?id=1902 cheers, Marcello
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] Backports policy proposal
On 25 June 2011 15:52, Angelo Naselli anase...@linux.it wrote: In data sabato 25 giugno 2011 15:27:01, Balcaen John ha scritto: Le samedi 25 juin 2011 10:08:58, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 16:19:45, Buchan Milne ha scritto: Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... +1, i just had problem when the pacakges where backported into 2010.1 and that broke the upgrade to mageia 1... Well here it just mean we probably failed to check backports package :/ Well indeed i've realized later, i should have been carefull in backporting 2010.1... but 2010.1 is not mageia 1 and mag2 should upgrade mga1... even if i have some doubt after mageia 9 (mga9-mga10) ... mga10 is higher than mga9: $ rpmdev-vercmp mga9 mga10 mga9 mga10 -- Angelo -- Ahmad Samir
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] Backports policy proposal
Le vendredi 24 juin 2011 à 17:33 +0300, Anssi Hannula a écrit : On 24.06.2011 03:10, Michael Scherer wrote: Another rule that we could add is that cauldron should always be newer than backports, in order to ensure upgradability. The same goes for n-2 and n-1 release. While this seems innocent, do not forget this will have a impact when we do the version freeze. So this will prevent backporting anything to mga1 if it is not in mga2 release/updates ? That's a good question but yes, I would consider such policy. Ie, do backport only for the latest supported release. Also, I don't see the advantage in preventing backports during freeze. The backports are re-allowed soon anyway, and the upgradeability goes away anyway. Then if people use mgaonline, it will fail, and then, people will start to say we cannot upgrade distribution and sooner or later, mgaonline will have the same bad reputation that backports had. So either we want mgaonline to be rock solid ( and I think that would be a benefit, and that if we managed to do it for mandriva, we can continue ), or we want to offer backports that will disrupt it, and thus have if you use backport, upgrade will not be supported, which is yet another reason for people to not use it. I do not see how we could win on both, except by limiting backporting to make sure system are still upgradable. Another solution would be some smart upgrader that do enable backports for upgrade, without taking everything. And until we see a working piece of code doing that, this will not be a solution. -- Michael Scherer
Re: [Mageia-dev] Backports policy proposal
Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : Michael Scherer a écrit : so : - cannot be backported if this is not a leaf package, will be revised later - cannot be backported if the maintainer say no, but we assume he say yes by default - cannot be backported if it impact the dependency tree too much ( Obsoletes, Provides, etc ) - cannot be backported if the package was just created and is thus basically untested in cauldron What about corner cases where a potential backport is incompatible with changes introduced in cauldron ? Should we leave such packages to third parties ? (I would tend to say yes.) Give a more precise example. - must not prevent upgrade to next release I can see where a backport could be a more recent version than in cauldron for the moment. Since that could make the newer version available to users somewhat sooner. Although by release, cauldron should have at least as recent a version. Or should we prohibit this ? (I'm thinking of cases where more recent versions are expected for cauldron before release.) If we decide to use the spec from cauldron on stable ( as it seems to be the sanest way of doing it ), the only way to have a newer version in stable than in cauldron would be to have the build broken on cauldron. If we tolerate this, and if no one fix ( because the person that did the upgrade only care about stable release ), we have a broken build. So forcing the build to be correct on cauldron would be a stronger incentive to fix. It seems more desirable to prevent a backport if the price to pay is to have a potentially broken cauldron package. - strict requires between backported packages, in order to make sure they can be cherrypicked ( ie, someone enable backports, install, remove backports ) It would be best if one can select individual backports without activating the backports repositories, as is now the case. So only the brave (wanting all backports) need activate the backports repositories. Agree with everything, except as noted. It might be useful to list major packages that should never be backported. I like the idea of tagging backports in the package name, as well as in the package database. We cannot tag in the packages database. Yum do it with a separate sqlite file, afaik. And tagging in the package name would be quite tricky to do if we need to play with %mkrel and release. -- Michael Scherer
Re: [Mageia-dev] Backports policy proposal
Le samedi 25 juin 2011 à 15:05 +0200, Angelo Naselli a écrit : In data venerdì 24 giugno 2011 02:10:14, Michael Scherer ha scritto: - cannot be backported if the package was just created and is thus basically untested in cauldron Well even if i could agree with that, i cannot see how can we ensure that a 2-3 weeks presence in cauldron means that the package has been tested by someone... we can only suppose to... a 0 week presence basically mean no test, so it can only improve the chance of being tested. -- Michael Scherer
Re: [Mageia-dev] Update of backport, policy proposal
Le vendredi 24 juin 2011 à 18:13 -0400, andre999 a écrit : Michael Scherer a écrit : This mail is about handling update on the backport repository. Either new version, or bugfix, or security upgrade. Everybody was focused on should we do patch, or should we do more backport issue, but the real problem is not really here. First, we have to decide what kind of update do we want to see, among the 3 types : - bugfixes - security bug fixes, - new version For bugfixes and new versions, that are not known to have security implications, let's treat them essentially as new backports. If the bug were locally reported, the reporter would be involved in the testing. Such updates would be installed as any other backport. However I would favour notifying those who have installed previous versions of these backports, of the availability of newer versions. The question is how. Maybe even having a backports updates category. (But not to be installed automatically by default.) For security issues, I'm not sure that it is important how we find out. As far as responsibility, I think the main responibility should be by the packager, but it could be useful for the security team to monitor it, to find an alternate packager if necessary. (Presumably from those who have tested or installed the package.) (I don't know who monitors security issues now, I just assume the security team.) However I think that such packages should be tested as normally for backports, and then treated as security updates, to be automatically applied. If we place it in a repository that is enabled by default, we will basically do a version upgrade for every people that have it enabled. If this is updates, this would violate our own policy. If we place in backports, it is not enabled by default. This is because those who have installed the backport in question have decided to accept a higher degree of risk. However a security issue can be a much greater risk, and is something that is normally resolved automatically. So by installing a security bug fix automatically for a backport, we are essentially maintaining the level of risk already assumed by the user. So that basically mean unsupported. There is even more tricky problems : Let's take a software that release soon, release often. Let's say a voip software. Someone install version 1.0 from release. So far, so good, but he hear that 1.1 is out, and he install it from backport ( after requesting ). He is satisfied, then the developers of our voip software decide to create a version 2.0, with a completely new interface but the ui is yet unfinished and untranslated, so our user cannot use it. Yet, someone request a backport, and let's assume we do it. With our current scheme, our user will not be affected and he doesn't want to upgrade. So he keep the version 1.1. A security issue is discovered, in 1.X and 2.X. 1.0-2 is sent to release update, with security fix. 2.1 is sent to backport, as the packager follow the list. What should be done for the user : Force upgrade to the next major release ? Ask him to revert to release update ? Tell him this is not supported ? Or maybe we should not have upgraded to 2.0 if we knew that current user would refuse it ? -- Michael Scherer
