Le mercredi 27 juillet 2011 22:52:00, Samuel Verschelde a écrit : > Le mercredi 27 juillet 2011 16:59:37, Samuel Verschelde a écrit : > > Le mercredi 27 juillet 2011 12:52:04, Samuel Verschelde a écrit : > > > Le mardi 26 juillet 2011 19:38:30, Samuel Verschelde a écrit : > > > > Le mardi 26 juillet 2011 18:42:05, Michael Scherer a écrit : > > > > [snip] > > > > > > > > > Yet, the problem would also be there for regular non-version > > > > > upgrade ( ie, if we have foo-2-2.mga2 in cauldron and stable, and > > > > > that we need to rebuild on stable and not on cauldron, we face the > > > > > same problem ), so using 0 is a incomplete solution to the issue, > > > > > and the only solution is to rebuild in cauldron, and such problem > > > > > should better be detected by youri. > > > > > > > > Very good point, this is a decisive argument to me. > > > > > > > > > So, the conclusion is that we should test ugprade rather than > > > > > assuming that it will just work because we placed a 0 instead of a > > > > > 1 somewhere. > > > > > > > > Ok for me provided we put in place the necessary processes to avoid > > > > upgrade problems (Youri::Submit::Test::Precedence for example). > > > > > > > > > Now, using 0 prevent us from having a simple way of seeing what > > > > > prerelease we ship and that should be updated to latest stable ( as > > > > > this seems to me quite desirable ). > > > > > > > > Good point too. > > > > > > > > > This is also inconsistent with the practice we had of backporting > > > > > from cooker ( as the initial goal at Mandriva was to have 0 > > > > > modifications from cooker to backports to reduce the load ). And if > > > > > we ship something in update and in backports, we would have the > > > > > same packages with 2 different releases, and that doesn't seems a > > > > > good idea. > > > > > > > > Worse, the backport would be preferred to the update :/ > > > > > > > > You should have said all this right from the start rather than > > > > assuming that we would have all these elements in mind :) > > > > > > > > Samuel > > > > > > I suggest we add this point to tonight's meeting topics and that a > > > decision be taken then. > > > > > > Then we would adapt the updates policy and the current packages in > > > updates_testing if the 0 release in updates is abandoned. We must also > > > decide if we continue to use subrels or not (using them could avoid > > > unneeded rebuilds in cauldron when there are packaging bugs in > > > updates). > > > > > > Best regards > > > > > > Samuel > > > > Ok, there will be no meeting tonight, so let's decide it on the ML. Was > > everyone convinced by misc's demonstration and do we agree to stop using > > the 0 release for updates and activate the > > Youri::Submit::Test::Precedence check on submit to prevent higher > > releases in mageia n than in mageia n+1 ? > > > > And if yes do we use subrels for subsequent modifications of packages > > that are proper to the mageia 1 branch ? > > > > I vote yes for both questions. > > > > Samuel > > Just to make things clear, contrarily as what was said in some of the > previous mails, I was told on IRC by misc and dmorgan that we should > always use subrels for updates. > > So this means that, when pushing foo-2-1.mga2 from cauldron to 1/updates, > it will become foo-2-1.1.mga1 and not foo-2-1.mga1 > > It means also that you will have to bump the release in cauldron in order > to be allowed to submit the update, in that case. But as misc said, it > should not happen very often : > - providing new versions as updates should remain an exception per updates > policy > - if the package in cauldron already has a release > 1, no need to bump it > > Hope it's clear. > > Best regards > > Samuel Verschelde
We have updates blocked by this release 0 issue, so we need a quick decision. I propose that if tomorrow nobody reacted against the proposal, it will be adopted. Best regards Samuel
