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