Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Buchan Milne wrote: > On Thursday, 5 July 2012 20:34:02 David Walser wrote: >> Guillaume Rousse wrote: >> > So, before any further contribution from my side, I'd like the people in >> > charge of security updates to find some internal agreement about what >> > kind of help they expect from other people exactly. If that's just to >> > push a non-discussable list of changes into spec files, they could as >> > well ask for SVN commit and package submission rights, to do it >> > directly. This would avoid a large amount of anger and frustration for >> > everyone. >> >> Nobody is in charge, which is part of the problem. I think a lot of us >> packagers come from Mandriva where we were used to Oden being in charge of >> updates for stable distros, and therefore not having to worry about it. > > While Mandriva had a security team (before Oden, Stew, and before that Stew > and Vince). However, that doesn't mean you never had to worry about anything. Sure, maybe the security manager would ask a maintainer for help with something sometimes, but they still had ultimately responsibility for the updates. My point is that responsibility falls on all of us packagers now, and it's a perspective shift that needs to be made. Also, I don't want anyone to get the idea that I'm in charge of security updates, even though I've kind of taken charge of it in a way, because when I finally started using Mageia at the end of last year, I noticed a lot of updates had been missed and nobody had taken charge of keeping track of such things. So I try my best to keep track of it now and do my best to help get the needed updates out. Please keep in mind that I do not have the level of experience of Vince or Oden and I have a full-time job which is not "make security updates for Mageia." I am doing my best, as is the QA team. Mageia may not be the first to market with security updates (we're usually later than many other distros), but for highly critical zero-days and things being actively exploited, we've done well with packagers, QA, and sysadmins working together to get these updates out in a timely manner. For other security updates, the important thing is that we get them out, not that we're first to market. Finally Buchan, I have no complaints about the job you've done contributing to security updates for packages you maintain. So if I ever sound like I'm complaining, it's not directed at you.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Regards, Buchan Buchan please refer here: https://www.mageia.org/pipermail/mageia-dev/2012-July/017245.html Thankyou.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On Thursday, 5 July 2012 20:34:02 David Walser wrote: > Guillaume Rousse wrote: > > So, before any further contribution from my side, I'd like the people in > > charge of security updates to find some internal agreement about what > > kind of help they expect from other people exactly. If that's just to > > push a non-discussable list of changes into spec files, they could as > > well ask for SVN commit and package submission rights, to do it > > directly. This would avoid a large amount of anger and frustration for > > everyone. > > Nobody is in charge, which is part of the problem. I think a lot of us > packagers come from Mandriva where we were used to Oden being in charge of > updates for stable distros, and therefore not having to worry about it. While Mandriva had a security team (before Oden, Stew, and before that Stew and Vince). However, that doesn't mean you never had to worry about anything. > We > are a community distro, we have no paid security manager. It is all of our > responsibility to do security updates for stable distros. > > As far as what kind of help is expected, it varies per bug really. Some of > them have maintainers that might want to give input. Some I would like to > know from someone else more experienced or who has more at stake in a > package how to handle an update when there are choices. Sometimes other > distros have pushed an updated (bugfix-only) version, or patched other bugs > as well, rather than just patched the security bug. IMHO, for a security, the priority is to get the patched binaries out to vulnerable users as soon as possible. If there is a pre-existing minor issue with the originally released package which an experienced user of the software in question can get around without any problems, a separate bug should be filed, but the minor issue should *NEVER* delay the update. If the software doesn't start with the default config, the user isn't vulnerable, and we can take more time to fix their problem. If the admin has fixed the default config issue, then THEY ARE VULNERABLE. For *SECURITY* bugs, addressing their vulnerability is the priority. Otherwise, we may as well not distinguish between bugfix and security updates. My expectation is that: 1)Old security fixes should have the highest priority 2)Any new security fix should have higher priority than any bugfix 3)Security updates should be provided within 1 week max Yes, QA team doesn't have enough resources. Guess what, neither do other teams. But, for me, it was frustrating to dedicate time (when I really didn't have it) to provide packages within 48 hours (24 for Mageia 2), and then have a 3-4 week delay in validation, mainly because of some minor pre-existing issues with the Mageia 1 package (which had been solved in the Mageia 2 relase package). Regards, Buchan
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Le dimanche 8 juillet 2012 13:49:36, nicolas vigier a écrit : > On Fri, 06 Jul 2012, Claire Robinson wrote: > > This has nothing to do with being rude. > > > > As I said previously, this is being blown wildly out of proportion. 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. > > > > 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. > > The argument you keep repeating about your opinion being common sense is > insulting for the people who do not have the same opinion. You could at > least admit that other people may have a different point of view, > without saying they don't have common sense. That's not what she said. > > > 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. > > > > 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). > > > > 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. > > Of course if you considere packagers should blindly apply any change > requested without any possible discussion because you decided it's common > sense, it only takes 2 minutes. Are you really suggesting that's what Claire thinks or are you just trying to warm up the atmosphere? > But conscientious packagers usually try to understand the problem they are > fixing, think about the potential problems introduced by the change, look at > the alternative solutions, etc ... Of course. Why do you seem to think that when a QA member raises a point he/she considers it's an order rather than a bug report? > > Also adding new suggests or changing default configuration should be > avoided in updates. The new suggest will be installed even for people > who already have a working setup. And the configuration file will be > updated for the people who did not need to modify it and don't > necessarily expect this kind of change in an update. Point noted. > > > 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. > > The goal of updates testing is to find regressions, not to do extensive > testing to find new unrelated bugs. This kind of testing can be useful, > but not as part of updates testing, and preferably on Cauldron. This is the same kind of testing, we look for bugs then we can see if they are regressions or not. They don't have "hey I'm a regression flag, test here!" flags :) But I agree with the fact that only regressions can block an update, the other bugs being left to the packager's appreciation. Samuel
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On Fri, 06 Jul 2012, Claire Robinson wrote: > > This has nothing to do with being rude. > > As I said previously, this is being blown wildly out of proportion. 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. > > 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. The argument you keep repeating about your opinion being common sense is insulting for the people who do not have the same opinion. You could at least admit that other people may have a different point of view, without saying they don't have common sense. > 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. > > 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). > > 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. Of course if you considere packagers should blindly apply any change requested without any possible discussion because you decided it's common sense, it only takes 2 minutes. But conscientious packagers usually try to understand the problem they are fixing, think about the potential problems introduced by the change, look at the alternative solutions, etc ... Also adding new suggests or changing default configuration should be avoided in updates. The new suggest will be installed even for people who already have a working setup. And the configuration file will be updated for the people who did not need to modify it and don't necessarily expect this kind of change in an update. > 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. The goal of updates testing is to find regressions, not to do extensive testing to find new unrelated bugs. This kind of testing can be useful, but not as part of updates testing, and preferably on Cauldron.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On 06/07/12 12:57, Guillaume Rousse wrote: Le 06/07/2012 13:19, AL13N a écrit : 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) No, what is really rude for me is Claire's agressive reaction here, two times in a row. I don't ask for flowers and congratulations everytime I interact with anyone else asking for help, I'd just like avoid feeling assaulted for "giving QA team too much work" while volonteering to contribute fixing a stalled issue. Especially on a public media such as bugzilla. Now, as I've been advised to use common sense, I'll just shut up, instead of adding more fuel to the fire, and I'll try to select more wisely my personal involvement in the future. The stalled issue was actually a packaging issue Guillaume. We don't expect to be held responsible for those in QA or have to send flowers when they are resolved. Perhaps that is where this misunderstanding stems from. Claire
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Le 06/07/2012 13:19, AL13N a écrit : 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) No, what is really rude for me is Claire's agressive reaction here, two times in a row. I don't ask for flowers and congratulations everytime I interact with anyone else asking for help, I'd just like avoid feeling assaulted for "giving QA team too much work" while volonteering to contribute fixing a stalled issue. Especially on a public media such as bugzilla. Now, as I've been advised to use common sense, I'll just shut up, instead of adding more fuel to the fire, and I'll try to select more wisely my personal involvement in the future. -- BOFH excuse #229: wrong polarity of neutron flow
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
> 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.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On 06/07/12 07:56, Oliver Burger wrote: Am 06.07.2012 08:18, schrieb AL13N: Op donderdag 5 juli 2012 23:52:39 schreef Claire Robinson: With respect Nicolas, you're not on the receiving end. [...] allthough i see badly worded(possibly to look offensive) sentences, i don't think this is intentional, and more a problem of communication than something else. I often have the feeling that certain sentences from french people come accross as rude to me. I've come to understand that this is not the intention, but somehow related to how french sentences are built and how it's been translated to english. The same thing was pointed out to me by a native speaker (as MrsB is), when I wrote an answer that somehow was rather rude to the receiver. We have to keep in mind, that most of us are non native speakers and that all of us have slightly different cultures. So - although it may be hard - it would be good for the native speakers among us, not to put every word through a rudeness detector. I know the Brits are far more courteous then the Germans (and perhaps the French as well?), so let's go back to fixing bugs and not feeling hurt by people who might not even be rude from their point of view... Oliver This has nothing to do with being rude. As I said previously, this is being blown wildly out of proportion. 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. 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. 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. 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). 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. Claire
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Am 06.07.2012 08:18, schrieb AL13N: Op donderdag 5 juli 2012 23:52:39 schreef Claire Robinson: With respect Nicolas, you're not on the receiving end. [...] allthough i see badly worded(possibly to look offensive) sentences, i don't think this is intentional, and more a problem of communication than something else. I often have the feeling that certain sentences from french people come accross as rude to me. I've come to understand that this is not the intention, but somehow related to how french sentences are built and how it's been translated to english. The same thing was pointed out to me by a native speaker (as MrsB is), when I wrote an answer that somehow was rather rude to the receiver. We have to keep in mind, that most of us are non native speakers and that all of us have slightly different cultures. So - although it may be hard - it would be good for the native speakers among us, not to put every word through a rudeness detector. I know the Brits are far more courteous then the Germans (and perhaps the French as well?), so let's go back to fixing bugs and not feeling hurt by people who might not even be rude from their point of view... Oliver -- Oliver Burger aka obgr_seneca Mageia contributor
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Op donderdag 5 juli 2012 23:52:39 schreef Claire Robinson: > On 05/07/12 23:34, nicolas vigier wrote: > > On Thu, 05 Jul 2012, Claire Robinson wrote: > >> These recent attacks are causing even more work for us, which again helps > >> nobody, and diverts our attention away from where it is really needed. > >> Also > >> I would point out that having to validate the same package several times > >> obviously lessens the amount of time we can spend elsewhere, which > >> compounds the problem. > > > > A disagreement is not an attack. > > With respect Nicolas, you're not on the receiving end. [...] allthough i see badly worded(possibly to look offensive) sentences, i don't think this is intentional, and more a problem of communication than something else. I often have the feeling that certain sentences from french people come accross as rude to me. I've come to understand that this is not the intention, but somehow related to how french sentences are built and how it's been translated to english.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Op donderdag 5 juli 2012 20:34:08 schreef David Walser: > AL13N wrote: > > this is a good point: "BTW, a missing dependency should not be > > considered a blocking issue as it can be easily fixed by the end user. > > Especially for a security update, as he probably already done it." > > > > also, not sure, but it seems the tester was unawere of perl-CGI-Fast being > > not really required (i think). > > > > still, IRC meeting yesterday seemed to conclude that security or major bug > > updates cannot be majorly delayed by bugs, it is however ok, to ask > > packager to do a quick fix for something at the same time. > > > > still, for this issue, it seems also that there was a month delay due to > > not setting assigned back. or even setting NEEDINFO. > > Incorrect. There was a month delay because the packager who first submitted > it to QA failed to provide an update for Mageia 2. That person also failed > to make any comment whatsoever, while being aware that questions had been > raised. > > Let me be clear, I know we're all busy, and I don't expect things to be > fixed right away all the time. However, we need to communicate. Even if > you don't have time to fix something, if you know there are issues, and you > have some input to give on it, give it. I really don't appreciate being > ignored for a month, and then when someone else tries to help, all of > sudden you (not you Maarten) finally speak up and complain about what has > been done. i do understand, however, as i said, even though QA might be ignored, i think QA still would have to validate it, when QA reads this and sees no response, imho :-( . > > also, i notice that noone seemed to have pointed out the tester that in > > fact that dependency isn't required. > > But it is used by the default configuration, so a suggests is appropriate. > Our packages should be functional out of the box. iiuc, the qa team member says it's required, and not suggested, and noone from packaging team thought about mentioning that it should be a suggests. (of course, i didn't know this, but suspected it) > > i also see that some sentences look harsh to one of both sides here. (or > > at > > least to me). > > Yes, that is true. Both sides could tone it down, and it is really not > appropriate to have that kind of argument in public on Bugzilla (IMO).
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
AL13N wrote: > this is a good point: "BTW, a missing dependency should not be > considered a blocking issue as it can be easily fixed by the end user. > Especially for a security update, as he probably already done it." > > also, not sure, but it seems the tester was unawere of perl-CGI-Fast being > not > really required (i think). > > still, IRC meeting yesterday seemed to conclude that security or major bug > updates cannot be majorly delayed by bugs, it is however ok, to ask packager > to do a quick fix for something at the same time. > > still, for this issue, it seems also that there was a month delay due to not > setting assigned back. or even setting NEEDINFO. Incorrect. There was a month delay because the packager who first submitted it to QA failed to provide an update for Mageia 2. That person also failed to make any comment whatsoever, while being aware that questions had been raised. Let me be clear, I know we're all busy, and I don't expect things to be fixed right away all the time. However, we need to communicate. Even if you don't have time to fix something, if you know there are issues, and you have some input to give on it, give it. I really don't appreciate being ignored for a month, and then when someone else tries to help, all of sudden you (not you Maarten) finally speak up and complain about what has been done. > also, i notice that noone seemed to have pointed out the tester that in fact > that dependency isn't required. But it is used by the default configuration, so a suggests is appropriate. Our packages should be functional out of the box. > i also see that some sentences look harsh to one of both sides here. (or at > least to me). Yes, that is true. Both sides could tone it down, and it is really not appropriate to have that kind of argument in public on Bugzilla (IMO).
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Guillaume Rousse wrote: > So, before any further contribution from my side, I'd like the people in > charge of security updates to find some internal agreement about what > kind of help they expect from other people exactly. If that's just to > push a non-discussable list of changes into spec files, they could as > well ask for SVN commit and package submission rights, to do it > directly. This would avoid a large amount of anger and frustration for > everyone. Nobody is in charge, which is part of the problem. I think a lot of us packagers come from Mandriva where we were used to Oden being in charge of updates for stable distros, and therefore not having to worry about it. We are a community distro, we have no paid security manager. It is all of our responsibility to do security updates for stable distros. As far as what kind of help is expected, it varies per bug really. Some of them have maintainers that might want to give input. Some I would like to know from someone else more experienced or who has more at stake in a package how to handle an update when there are choices. Sometimes other distros have pushed an updated (bugfix-only) version, or patched other bugs as well, rather than just patched the security bug. Based on my descriptions in my e-mail and comments in the bugs, you can see some of those that I'd just like some advice. Others are more complicated or packages that I don't know anything about. Bottom line is, the ones I've asked about, there's some reason I haven't just done it myself. Any help you can offer is appreciated. If you want clarification on any particular one what I need, please just ask me.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
AL13N a écrit : Op donderdag 5 juli 2012 21:31:50 schreef Guillaume Rousse: I spent some time today to help the QA team to manage those pending security updates. And for the second time in a week, I've been facing rather unpleasant attitude from someone else from the same team: https://bugs.mageia.org/show_bug.cgi?id=5939 I wonder how we're supposed to work together when expressing an opinion about issues prioritization expose you to harsh comment from someone unable to express his disagreement without agressivity. That's not much point ressorting to "we're all in the same boat" kind of metaphor during IRC meeting to thereafter suggest to leave the board to people expressing concerns about the boat heading... So, before any further contribution from my side, I'd like the people in charge of security updates to find some internal agreement about what kind of help they expect from other people exactly. If that's just to push a non-discussable list of changes into spec files, they could as well ask for SVN commit and package submission rights, to do it directly. This would avoid a large amount of anger and frustration for everyone. this is a good point: "BTW, a missing dependency should not be considered a blocking issue as it can be easily fixed by the end user. Especially for a security update, as he probably already done it." Although if it can be easily added, why not do it ? Even if only a suggest ? also, not sure, but it seems the tester was unawere of perl-CGI-Fast being not really required (i think). According to the comments in the bug, an optional package was required by the default config file, even if the package was not installed. That is a real bug. Adding a suggest is a temporary, and not permanent fix, as suggests don't have to be installed. Although the permanent fix could be done later. This brings up another improvement that is needed in the install routines. Suggests should be treated as suggests, with confirmation from the user on install. As such, QA could more readily test and find such bugs. still, IRC meeting yesterday seemed to conclude that security or major bug updates cannot be majorly delayed by bugs, it is however ok, to ask packager to do a quick fix for something at the same time. still, for this issue, it seems also that there was a month delay due to not setting assigned back. or even setting NEEDINFO. also, i notice that noone seemed to have pointed out the tester that in fact that dependency isn't required. i also see that some sentences look harsh to one of both sides here. (or at least to me). i think we need to understand that: A. QA team has responsibility on validation of update - thus they decide validated or not - if they find a non-regression bug, they can ask packagers to fix at the same time, but for major and security bugs, this should not be waited for, in such a case, a separate bug can be made and this one validated. - however, i can also understand that due to the amount of updates needed validation, that such a wait, could be instead of 1 day, easily amount to a few weeks, without this being intentional. - so, i would ask that QA, try to get the packager on IRC (or email) and if the packager isn't immediately available, to still continue to validate and possibly make a new bug report on it. so that "bugs" or "features" can still be discussed if need be. - give that packagers are responsible for their package (and likely know it better than QA team), i would state that they are also responsible for deciding need or no (immediate) need for extra change before validation. B. QA team tests and finds bugs, and the reality of their pov is that if they'd put bugs they find in a separate BR, it often doesn't get fixed, and thus each validation test for all newer security patches, they hit the same bug for testing; which causes them frustration. C. However, some packages need quite some configuration to get it to run to test, so packagers are allowed to add a small list of how to reproduce, or even configure it to run. as this will likely make for faster testing, and also less possibilities of misunderstanding a possible missing requirement. Personally, I think regarding this quite some things could've been done better, but we can't have it all. i don't think there's a golden rule for this, and given our limited resources, i guess we (both teams) will have to bear with this. PS: i'm just putting my nose in matter that don't concern me here, but i'm just trying to understand both sides, i'm not trying to offend anyone, or to belittle any of the issues involved. +1 Sometimes when things get frustrating, a few kind words from both sides can help a lot. And maybe step back and smile a little. But it certainly can be difficult. -- André
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On 05/07/12 23:34, nicolas vigier wrote: On Thu, 05 Jul 2012, Claire Robinson wrote: These recent attacks are causing even more work for us, which again helps nobody, and diverts our attention away from where it is really needed. Also I would point out that having to validate the same package several times obviously lessens the amount of time we can spend elsewhere, which compounds the problem. A disagreement is not an attack. With respect Nicolas, you're not on the receiving end. If the current situation is indeed such an intolerable issue then perhaps we should think seriously if we currently have the resources to maintain two active releases or rethink our ability to open backports, instead of bullying those who are already stretched too thinly. If there is too much workload, a solution is to provide only limited support and stop trying to fix all bugs with stable updates: only important security issue and critical bugs are fixed with an update, all other bugs are fixed in Cauldron only. This is what is done in most other distributions. This is mainly what is happening now. Don't forget mga1 has had a long time to receive its bug fixes, they are few and far between now. Most security updates on the other hand are for both mga1 and mga2 so take at least twice as long to test.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On Thu, 05 Jul 2012, Claire Robinson wrote: > These recent attacks are causing even more work for us, which again helps > nobody, and diverts our attention away from where it is really needed. Also > I would point out that having to validate the same package several times > obviously lessens the amount of time we can spend elsewhere, which > compounds the problem. A disagreement is not an attack. > > If the current situation is indeed such an intolerable issue then perhaps > we should think seriously if we currently have the resources to maintain > two active releases or rethink our ability to open backports, instead of > bullying those who are already stretched too thinly. If there is too much workload, a solution is to provide only limited support and stop trying to fix all bugs with stable updates: only important security issue and critical bugs are fixed with an update, all other bugs are fixed in Cauldron only. This is what is done in most other distributions.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On 05/07/12 22:51, nicolas vigier wrote: On Thu, 05 Jul 2012, Guillaume Rousse wrote: Le 04/07/2012 01:21, David Walser a écrit : Sorry, think I've got them all now. For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to borrow the patches from the mplayer update. For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT. https://bugs.mageia.org/show_bug.cgi?id=6427 I spent some time today to help the QA team to manage those pending security updates. And for the second time in a week, I've been facing rather unpleasant attitude from someone else from the same team: https://bugs.mageia.org/show_bug.cgi?id=5939 I wonder how we're supposed to work together when expressing an opinion about issues prioritization expose you to harsh comment from someone unable to express his disagreement without agressivity. That's not much point ressorting to "we're all in the same boat" kind of metaphor during IRC meeting to thereafter suggest to leave the board to people expressing concerns about the boat heading... So, before any further contribution from my side, I'd like the people in charge of security updates to find some internal agreement about what kind of help they expect from other people exactly. If that's just to push a non-discussable list of changes into spec files, they could as well ask for SVN commit and package submission rights, to do it directly. This would avoid a large amount of anger and frustration for everyone. About prioritization, I think we should remember that : - we want security updates quickly, to reduce the time users will have vulnerable systems - we don't want regressions in updates, that's why we need QA team to test the updates, and why we avoid major changes in updates - all people working on Mageia are volunteers, have limited time and probably other external constraints. We can ask them to make an effort when there is an urgency, but this should not be abused. So I think it would make sense to have a policy that say that when a bug that is not a regression is found while testing an update, it can be mentioned for information, but it should not block the validation of the update. Packager can fix it while fixing the other issue, if he has time, but he doesn't fix it if he is too busy or think it introduce too much changes for an update. In that case the issue can be fixed later when the packager has some free time, with no hurry. The trouble with this is, when the packager finds some free time it then creates yet another update request for QA to validate and compounds the problem. We simply have to apply common sense. If something is easily fixed, fix it. If it isn't then ask for a separate bug report. There is no black and white policy for this, either extreme is wrong. I would hope that any packager sending an update for validation would be willing to follow that up and not just abandon it and move on, becoming annoyed when problems are found. You wouldn't expect QA to do that on our bug reports, you would rightly expect us to follow them up and provide any extra information and testing as required. Even knowing how busy we are. I am sure bug reports from our general userbase are not so keenly monitored or completely reported as the ones we create. This was all discussed yesterday. There is no real problem to resolve, other than finding more people to volunteer their time. This hostility towards QA is rather detrimental to that particular cause though. The methods we use are tried and tested, and have remained unchanged since the first updates began to arrive for Mageia 1. There is no reason to change them now and certainly no reason to begin taking shortcuts. QA is not there to 'rubber stamp' updates, we are there to perform QA. To view things from a users perspective and try to find the bugs before they reach them. We have to apply common sense in our work and only ask that packagers do the same thing. None of us want to see buggy updates being released or unnecessary delays I'm sure. Claire
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
On Thu, 05 Jul 2012, Guillaume Rousse wrote: > Le 04/07/2012 01:21, David Walser a écrit : >> Sorry, think I've got them all now. >> >> For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to >> borrow the patches from the mplayer update. >> >> For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT. >> >> https://bugs.mageia.org/show_bug.cgi?id=6427 > I spent some time today to help the QA team to manage those pending > security updates. And for the second time in a week, I've been facing > rather unpleasant attitude from someone else from the same team: > https://bugs.mageia.org/show_bug.cgi?id=5939 > > I wonder how we're supposed to work together when expressing an opinion > about issues prioritization expose you to harsh comment from someone unable > to express his disagreement without agressivity. That's not much point > ressorting to "we're all in the same boat" kind of metaphor during IRC > meeting to thereafter suggest to leave the board to people expressing > concerns about the boat heading... > > So, before any further contribution from my side, I'd like the people in > charge of security updates to find some internal agreement about what kind > of help they expect from other people exactly. If that's just to push a > non-discussable list of changes into spec files, they could as well ask for > SVN commit and package submission rights, to do it directly. This would > avoid a large amount of anger and frustration for everyone. About prioritization, I think we should remember that : - we want security updates quickly, to reduce the time users will have vulnerable systems - we don't want regressions in updates, that's why we need QA team to test the updates, and why we avoid major changes in updates - all people working on Mageia are volunteers, have limited time and probably other external constraints. We can ask them to make an effort when there is an urgency, but this should not be abused. So I think it would make sense to have a policy that say that when a bug that is not a regression is found while testing an update, it can be mentioned for information, but it should not block the validation of the update. Packager can fix it while fixing the other issue, if he has time, but he doesn't fix it if he is too busy or think it introduce too much changes for an update. In that case the issue can be fixed later when the packager has some free time, with no hurry.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
I spent some time today to help the QA team to manage those pending security updates. And for the second time in a week, I've been facing rather unpleasant attitude from someone else from the same team: https://bugs.mageia.org/show_bug.cgi?id=5939 I wonder how we're supposed to work together when expressing an opinion about issues prioritization expose you to harsh comment from someone unable to express his disagreement without agressivity. That's not much point ressorting to "we're all in the same boat" kind of metaphor during IRC meeting to thereafter suggest to leave the board to people expressing concerns about the boat heading... So, before any further contribution from my side, I'd like the people in charge of security updates to find some internal agreement about what kind of help they expect from other people exactly. If that's just to push a non-discussable list of changes into spec files, they could as well ask for SVN commit and package submission rights, to do it directly. This would avoid a large amount of anger and frustration for everyone. You seem to be frustrated by a false assumption. The assumption that something has changed over the past year of performing QA on security updates. It hasn't. We haven't begun doing anything differently and we haven't started to ask for any more than we have done before, during all that time. The reason we now have a backlog, which seems to be the cause of the frustration, is simply because we don't have enough volunteers. That is not really a reason to begin taking shortcuts, or cut out common sense, but it is something you can help with. Our QA workload doubled overnight when Mageia 2 was released. At the time there were mainly only two of us to perform the task, as there had been throughout the lifespan of Mageia 1 until that point. One tested every update x86_64 and one tested every update i586. As I'm sure you realise, that is nowhere near enough people to perform QA adequately on two live releases, especially just after release when many packaging bugs are being fixed. This is on top of having to work around bug 2317 which is only now beginning to receive attention. I fully sympathise with the need to concentrate on security updates and the need to handle them efficiently. Nothing has changed in that regard. We handle them now the same as we have been doing since last August and it has never been a problem for anybody. Believe it or not, it is actually appreciated by most.. We have been trying to recruit new members and with some limited success. Those new members will hardly be inspired though to volunteer their time by this type of bullying. I myself would also like to think I didn't have to purposely avoid certain packagers update requests because of their aggressive behaviour. That situation would be of no benefit to anybody. We always have and will continue to do our best to prioritise security updates. Unfortunately that has to happen at the expense of bugfix updates so there are a number of those waiting for our attention. David has also been pushing for maintainers to get various security bugs fixed so there has been a bit of an influx for QA to deal with. This whole issue is being blown wildly out of proportion and it is really demoralising for those of us who already spend far too many hours a day actually doing the job. If you really want to speed things up then please spend some time helping to shorten the list and lighten the load. We did request help two weeks ago in the packagers meeting. You can find the validation procedure here: http://bit.ly/Ne2lPP and the list of bugs awaiting QA here: http://bit.ly/LZMNhr Throughout the life of Mageia 1 the QA list was usually between 20 and 40 bugs long, it is now between 40 and 50 bugs long and is hovering around that point. These recent attacks are causing even more work for us, which again helps nobody, and diverts our attention away from where it is really needed. Also I would point out that having to validate the same package several times obviously lessens the amount of time we can spend elsewhere, which compounds the problem. If the current situation is indeed such an intolerable issue then perhaps we should think seriously if we currently have the resources to maintain two active releases or rethink our ability to open backports, instead of bullying those who are already stretched too thinly. Regards Claire
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Op donderdag 5 juli 2012 21:31:50 schreef Guillaume Rousse: > Le 04/07/2012 01:21, David Walser a écrit : > > Sorry, think I've got them all now. > > > > For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to > > borrow the patches from the mplayer update. > > > > For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT. > > > > https://bugs.mageia.org/show_bug.cgi?id=6427 > > I spent some time today to help the QA team to manage those pending > security updates. And for the second time in a week, I've been facing > rather unpleasant attitude from someone else from the same team: > https://bugs.mageia.org/show_bug.cgi?id=5939 > > I wonder how we're supposed to work together when expressing an opinion > about issues prioritization expose you to harsh comment from someone > unable to express his disagreement without agressivity. That's not much > point ressorting to "we're all in the same boat" kind of metaphor during > IRC meeting to thereafter suggest to leave the board to people > expressing concerns about the boat heading... > > So, before any further contribution from my side, I'd like the people in > charge of security updates to find some internal agreement about what > kind of help they expect from other people exactly. If that's just to > push a non-discussable list of changes into spec files, they could as > well ask for SVN commit and package submission rights, to do it > directly. This would avoid a large amount of anger and frustration for > everyone. this is a good point: "BTW, a missing dependency should not be considered a blocking issue as it can be easily fixed by the end user. Especially for a security update, as he probably already done it." also, not sure, but it seems the tester was unawere of perl-CGI-Fast being not really required (i think). still, IRC meeting yesterday seemed to conclude that security or major bug updates cannot be majorly delayed by bugs, it is however ok, to ask packager to do a quick fix for something at the same time. still, for this issue, it seems also that there was a month delay due to not setting assigned back. or even setting NEEDINFO. also, i notice that noone seemed to have pointed out the tester that in fact that dependency isn't required. i also see that some sentences look harsh to one of both sides here. (or at least to me). i think we need to understand that: A. QA team has responsibility on validation of update - thus they decide validated or not - if they find a non-regression bug, they can ask packagers to fix at the same time, but for major and security bugs, this should not be waited for, in such a case, a separate bug can be made and this one validated. - however, i can also understand that due to the amount of updates needed validation, that such a wait, could be instead of 1 day, easily amount to a few weeks, without this being intentional. - so, i would ask that QA, try to get the packager on IRC (or email) and if the packager isn't immediately available, to still continue to validate and possibly make a new bug report on it. so that "bugs" or "features" can still be discussed if need be. - give that packagers are responsible for their package (and likely know it better than QA team), i would state that they are also responsible for deciding need or no (immediate) need for extra change before validation. B. QA team tests and finds bugs, and the reality of their pov is that if they'd put bugs they find in a separate BR, it often doesn't get fixed, and thus each validation test for all newer security patches, they hit the same bug for testing; which causes them frustration. C. However, some packages need quite some configuration to get it to run to test, so packagers are allowed to add a small list of how to reproduce, or even configure it to run. as this will likely make for faster testing, and also less possibilities of misunderstanding a possible missing requirement. Personally, I think regarding this quite some things could've been done better, but we can't have it all. i don't think there's a golden rule for this, and given our limited resources, i guess we (both teams) will have to bear with this. PS: i'm just putting my nose in matter that don't concern me here, but i'm just trying to understand both sides, i'm not trying to offend anyone, or to belittle any of the issues involved.
Re: [Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Le 04/07/2012 01:21, David Walser a écrit : Sorry, think I've got them all now. For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to borrow the patches from the mplayer update. For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT. https://bugs.mageia.org/show_bug.cgi?id=6427 I spent some time today to help the QA team to manage those pending security updates. And for the second time in a week, I've been facing rather unpleasant attitude from someone else from the same team: https://bugs.mageia.org/show_bug.cgi?id=5939 I wonder how we're supposed to work together when expressing an opinion about issues prioritization expose you to harsh comment from someone unable to express his disagreement without agressivity. That's not much point ressorting to "we're all in the same boat" kind of metaphor during IRC meeting to thereafter suggest to leave the board to people expressing concerns about the boat heading... So, before any further contribution from my side, I'd like the people in charge of security updates to find some internal agreement about what kind of help they expect from other people exactly. If that's just to push a non-discussable list of changes into spec files, they could as well ask for SVN commit and package submission rights, to do it directly. This would avoid a large amount of anger and frustration for everyone. -- BOFH excuse #378: Operators killed by year 2000 bug bite.
[Mageia-dev] Security updates - Help needed (also forgot avidemux and gstreamer0.10-ffmpeg)
Sorry, think I've got them all now. For avidemux and gstreamer0.10-ffmpeg in Mageia 1, it may be sufficient to borrow the patches from the mplayer update. For avidemux in Mageia 2, patches will need to be pulled from ffmpeg GIT. https://bugs.mageia.org/show_bug.cgi?id=6427
