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

[AL13N]

> 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.