Le vendredi 24 juin 2011 02:10:14, Michael Scherer a écrit : > I would also propose a few rules : > > "a package should have been in cauldron since 1 week before being > backported", so we can at least ensure there was a minimal test on it, > Ie, if I package stuff-virtual-manager, I cannot backport it before 1 > week. If we have a package of stuff-virtual-manager since 1 month, and > that I update a new version, then I can backport. The idea is that a > newer packages may suffer from more bug than older one.
Could this apply only to "-backport" media and not "-backport_testing " media ? I would find good to be able to send a package very quickly to backports_testing so that I can start to be tested as soon as possible. A whole week for that would be a long time, considering that after that you have to add more time so that the backport can be tested. By the way I think a packager usually knows the risks there is to send a package too quickly to the backports and that we don't necessarily need to enforce such a strict "1 week" rule. Especially when sending to backports_testing first. > - cannot be backported if this is not a leaf package, will be revised > later I would like to be less strict, by replacing "leaf package" by "leaf group of packages, tighly tied together by strict requires". Examples : - A requires newer B and C, and no other package requires B and C (quite common with games where data are split into separate packages) => you can backport A, B, C. To me this situation should be possible. - A requires newer B, but D depends on B too => you can't backport A and B alone, but if the maintainers consider it acceptable to enforce upgrade of D when someone wants to upgrade A or upgrade of A when someone wants to upgrade D (could be related pieces of software), then you can backport A, B and D (and make sure to set the good requires). To me this situation would be nice to have as an available option. Best regards Samuel Verschelde
