[Mageia-dev] Updates and 0 release

Samuel Verschelde stormi at laposte.net
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


More information about the Mageia-dev mailing list