Re: [Mageia-dev] Backports policy proposal
Michael Scherer a écrit : Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit : Michael Scherer a écrit : Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : Michael Scherer a écrit : [...] - 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. Suppose leaf package fooa depends on foob. foob is part of the current release. Cauldron replaces foob with fooc. fooa is incompatible with fooc. Then why do we replace foob by it in the first place if this break fooa ? (see below) fooa is requested by some users, and future versions of fooa are intended to be compatible with fooc. In this case, even though it wouldn't be testable in cauldron, it could be tested in backports-testing, and I think it could be a good idea to allow it. Even if fooc compatibility wouldn't be available for the next Mageia release, a user could avoid updating for a release in order to keep using fooa. However, if there were no intention to make fooa compatible with fooc, maybe it should be denied. The example is bogus. If we have fooa in the distro and we upload fooc that break it, then we have to fix the breakage as a priority. Usually, that would be having foob and fooc as parallel installablable. The idea is that fooa is not in release, but is compatible with release, and not with cauldron. (More details below.) Anyway, the question is how often does it happens ? Because it may happen is not a justification if in practice, it never happen. And not having a backport is not the end of the world so unless the problem is quite frequent ( and so far, this one is far from being frequent , especially since it is based on a wrong supposition in the first part ), I do not think this would be blocking. Often enough there will be changes in cauldron to newer packages not entirely compatible with the older ones they are replacing. And other existing packages are dependant on them, so they have to be fixed in cauldron. Backport requests could be compatible with release but not cauldron. I wouldn't expect that to be frequent, but such requests have already happened. In some cases the updates for compatibility from upstream could just be late in coming. The question is, should we allow such backports under certain circumstances ? I'm not necessarily saying yes. Maybe we should say not for now, to be reviewed later ? -- André
Re: [Mageia-dev] Backports policy proposal
Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit : Michael Scherer a écrit : Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : Michael Scherer a écrit : [...] - 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. Suppose leaf package fooa depends on foob. foob is part of the current release. Cauldron replaces foob with fooc. fooa is incompatible with fooc. Then why do we replace foob by it in the first place if this break fooa ? fooa is requested by some users, and future versions of fooa are intended to be compatible with fooc. In this case, even though it wouldn't be testable in cauldron, it could be tested in backports-testing, and I think it could be a good idea to allow it. Even if fooc compatibility wouldn't be available for the next Mageia release, a user could avoid updating for a release in order to keep using fooa. However, if there were no intention to make fooa compatible with fooc, maybe it should be denied. The example is bogus. If we have fooa in the distro and we upload fooc that break it, then we have to fix the breakage as a priority. Usually, that would be having foob and fooc as parallel installablable. Anyway, the question is how often does it happens ? Because it may happen is not a justification if in practice, it never happen. And not having a backport is not the end of the world so unless the problem is quite frequent ( and so far, this one is far from being frequent , especially since it is based on a wrong supposition in the first part ), I do not think this would be blocking. 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. I would like to see the source repository info available for every installed package. Maybe even stored somewhere in the .rpm file, also. Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add new fields to the packages database ? (Although a parallel sqlite file would work.) Compatibility would be indeed a concern. But if we move packages between repository without rebuilding for QA reasons, this would also be meaningless. -- Michael Scherer
Re: [Mageia-dev] Backports policy proposal
Michael Scherer a écrit : Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : Michael Scherer a écrit : [...] - 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. Suppose leaf package fooa depends on foob. foob is part of the current release. Cauldron replaces foob with fooc. fooa is incompatible with fooc. fooa is requested by some users, and future versions of fooa are intended to be compatible with fooc. In this case, even though it wouldn't be testable in cauldron, it could be tested in backports-testing, and I think it could be a good idea to allow it. Even if fooc compatibility wouldn't be available for the next Mageia release, a user could avoid updating for a release in order to keep using fooa. However, if there were no intention to make fooa compatible with fooc, maybe it should be denied. - 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. Good point. Possibly a little more work for the moment, for greater stability. But the example in the previous case above gives an exception -- which might be reasonable to allow. [...] 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. I would like to see the source repository info available for every installed package. Maybe even stored somewhere in the .rpm file, also. Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add new fields to the packages database ? (Although a parallel sqlite file would work.) And tagging in the package name would be quite tricky to do if we need to play with %mkrel and release. Right. I thought about this afterwards. -- André
Re: [Mageia-dev] Backports policy proposal
On 26.06.2011 01:34, Michael Scherer wrote: 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. This will essentially prevent backporting anything to mga1 after mga2 release. :/ -- Anssi Hannula
Re: [Mageia-dev] Backports policy proposal
In data domenica 26 giugno 2011 00:43:22, Michael Scherer ha scritto: 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. Agree, but the same chance as we put in backport_testing - or what name is- first. -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Backports policy proposal
Le dimanche 26 juin 2011 à 18:00 +0300, Anssi Hannula a écrit : On 26.06.2011 01:34, Michael Scherer wrote: 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. This will essentially prevent backporting anything to mga1 after mga2 release. :/ Yes, that's explicitly the problem. Now, maybe we could say if you use backports on version N after the release of N+1, then mgaonline will no longer work. Provided we find a user friendly way to warn users, we can maybe find something. But again, it is either the backports or the upgrade. And people do have expressed to have both : - reinstalling at every release is hard and annoying, why not do like Ubuntu and Debian ? - We want newer software, why not provides newer version ? So we either need a way to solve the dilemma, or at least, a way to clearly explain the impact to people. I think I may have a idea that would solve this issue and the one of update, but I need to think a little bit before proposing it ( especially since I suffer from common cold, maybe my idea is completely rubbish ). -- Michael Scherer
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.
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] 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] Backports policy proposal
On Friday, 24 June 2011 08:30:15 Maarten Vanraes wrote: 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, Why should it need spec file changes? and thus the release becomes newer than the one in cauldron If it requires spec file changes, why should cauldron not get a new release that includes the changes? Sorry, but a number of my packages were regularly backported, and I never needed cooker to be older ... Regards, Buchan
Re: [Mageia-dev] Backports policy proposal
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 ? 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. -- Anssi Hannula
Re: [Mageia-dev] Backports policy proposal
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.) - 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.) - 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. (I'd like the database to retain all the source repositories of installed packages.) -- André
