[Mageia-dev] [Freeze] please let in xonotic

Sun Mar 11 22:25:32 CET 2012

Le dimanche 11 mars 2012 à 17:58 +0100, Samuel Verschelde a écrit :
+> Le dimanche 11 mars 2012 13:21:57, Michael Scherer a écrit :
+> > Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit :
+> > > Hi
+> > > 
+> > > please let in xonotic-0.6.0
+> > > It's just a game that impacts nothing else.
+> > 
+> > Niet.
+> > 
+> > That's bugfix or security fixes.
+> 
+> Communication tip for the future : when such a policy change happens (this is 
+> a policy change, there were more exceptions in the past before package freeze, 
+> for leaf packages without weird deps and post/pre scripts and little impact), 
+> let's try to highlight it *before*.
+
+We asked if people understood what version freeze mean, and people all
+said yes. 
+
+http://meetbot.mageia.org/mageia-dev/2012/mageia-dev.2012-02-15-20.13.log.html#l-75
+
+So I assumed that people were aware of what was posted last time :
+
+http://permalink.gmane.org/gmane.linux.mageia.devel/4015
+
+and that "very good reasons" where basically the same for everybody. 
+
+It seems there is some misunderstanding, likely coming from another
+discussion that the one I found. Can people just tell me where they have
+seen their interpretation of freeze, cause I have read the one I posted
+twice, I still think it correspond that what i just said.
+
+> There was a communication effort to announce the freeze: I read freeze 
+> announce, was present at the last packager meeting. However it didn't struck 
+> me, it all looked like the usual end of release cycle, with their common-sense 
+> exceptions.
+>
+> A message such as "contrarily as what happened in the past" (this is the 
+> important part, highlight a *change*), "there will be no exception even for 
+> leaf non-critical packages, so that you all focus on bugfixes, as we know that 
+> otherwise you will not fix bugs and continue updating your packages". 
+
+I took a look at the archives for the last round ( ie mageia 1 ), thanks
+to evolution. Since people were upset because this exception should have
+been granted, I assumed that the same type of exception would have been
+granted in the past numerous times ( I mean, if people didn't remember
+the mail saying "this would not be granted", that's likely because we
+granted it several time, enough time to have people totally forget what
+was posted in the first place ).
+
+I found exactly 1 package that not at least saying "that's a bug fix
+release", "this fix a CVE", "it fix upgrade"., ie all reasons that were
+announced "we would likely let this pass".
+
+It was alienarena on 06/05/2011, and it was pushed by boklm around 2h
+after the mail was sent.
+
+That's the only one I can find that was not corresponding at the
+criteria we laid out for being a regular exception ( cf url given sooner
+), but it was still granted. We trusted boklm as well as others to
+choose, so he did. But still, if we look at the list given before ( and
+since no one answered at all and no one complained later, I assumed that
+everybody agreed, especially since this was based on common sense ), it
+was said "it would likely not pass".
+
+
+So if there wasn't others ( and I will assume that's the case unless
+someone show others examples that I could have missed ), we can see that
+the whole "but it was granted last time" assumption is either based
+on : 
+- 1 single rpm being a exception that would have been refused and that
+wasn't ( ie, a weak example )
+or :
+- based on a different "last time" than last year ( and then why did no
+one complained last year is left as a exercise )
+or :
+- based on different perception of what type of exception were granted
+last time, perception that doesn't align with the reality of the
+archives I checked.
+
+But so far, I think that we are basically and roughly coherent when
+compared to the last freeze period. Therefore, I do not see the need to
+communicate a change when there was in fact no changes on the side of
+the policy. And sorry, I cannot communicate to say that what people
+remember do not correspond to what was done. 
+
+And we can see that as tmb said, the problem is not that granting would
+disturb the distribution, but that granting once for a minor package
+would lead to the same type of lengthy and heated discussion as we are
+having now, but for each packages. The more complex the rules are, the
+more discussion and the more problem we will have to solve. 
+
+-- 
+Michael Scherer
+
+