[Mageia-dev] Updates and 0 release

Thu Jul 28 10:08:44 CEST 2011

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
+