[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)

Fri Jul 6 13:19:41 CEST 2012

> On 06/07/12 07:56, Oliver Burger wrote:
+[...]
+> This has nothing to do with being rude.
+
+IIUC, a small bit of it is related in 2 instances (from my pov):
+ - QA team being ignored in their question
+ - packager being doubted by QA team
+
+(in some or other forms, both of these can be seen as rude)
+
+for one more perceived rudeness, look below.
+
+> As I said previously, this is being blown wildly out of proportion.
+
+very true
+
+> In
+> reality it centres around one packager and two bugs. In both these bugs
+> the packager expected QA to validate updates where one was an xinetd
+> service which expressly stated it was disabled by default but in actual
+> fact was enabled and in the other a mailing list with a web interface
+> which simply couldn't work in it's default configuration.
+>
+> What it being thrown at us is that we are unreasonably expecting every
+> single little bug to be fixed without any common and need to make
+> drastic changes to our policies.
+
+i did mention it would best for packagers (and i think it's in policy)
+that they would give reproducer tests for validation (perhaps it should be
+extended to getting the package working as well)
+
+> We attended the packager meeting on Wednesday to respond to this and
+> discuss it. At the meeting it was agreed that we had not changed the way
+> we have been doing things since day one and that the right way forward
+> was to continue doing what we were doing, with both packagers and QA
+> using common sense.
+
+IIUC, not 100% the same, security updates should get pushed without delay
+even if there's an additional problem (unless regressions). The idea
+behind this, is that security updates are important for people who are
+already running it. and since they are running it, they aren't likely to
+have the problems that QA had.
+
+I have no trouble having contacting packager and ask for fix, but
+ultimately, for if for whatever reason the packager isn't there, i still
+think it should be pushed.
+
+> The following day the same far fetched accusations are thrown at us
+> again, now escalated to the ML, suggesting we caused a months delay and
+> suggesting a solution to the accusation being we begin to 'rubber stamp'
+> security updates regardless of if they actually work or not or an
+> internet facing service which says it's disabled is actually not so.
+
+This is also perceived rudeness:
+- The packager's pov is that QA should have pushed it anyway.
+- personally, i'm not certain that this is the intention of the person who
+wrote it.
+
+The problem in this exact case, is that in fact, IMHO, the suggested
+modification, wasn't needed; allthough it might be better, it's ultimately
+not needed, because having a mailinglist, you need to configure alot of
+things anyway. and perhaps it's not even required to use CGI::Fast
+(depending on configuration). arguably it's perhaps better to have this as
+suggest.
+
+The packager's pov is that QA team was stating a undiscussable MUST that
+this dependency should be required (not suggested; which is better), while
+in effect, afterwards, it appears that this dependency is a separate and
+not even a major bug (easy workaround).
+
+But, QA team doesn't know alot about this. so i'm not speaking about
+faults here.
+Also packaging team must realize that QA team doesn't know alot about
+this. They are just doing what they think is right.
+
+but if packaging team says that this isn't really a major requirement for
+this security bug, then again, QA team should understand this too.
+
+
+> In both cases there were simple ways to fix them. In one it was just to
+> alter the description (2 minutes) so it didn't say it was disabled and
+> in the other it was either to add a suggest or alter the default
+> configuration so it didn't require the missing suggest (2 minutes).
+
+That is also true.
+
+> We have to use common sense in QA and only ask that, to avoid all this
+> unpleasantness in the future, common sense is used by the packager also.
+> All this is a reaction to 4 minutes of additional work. That is not
+> common sense to me.
+>
+> If we're expected to validate updates in the state these two bugs
+> reached us then we may as well not be here at all.
+
+no offense meant, but in retrospect, it appears those new bugs in those 2
+bug reports (to me) aren't that major at all.
+
+but I agree that it isn't easy to test, and thus packager should be
+accomodating that.
+