Re: [Mageia-dev] Finalizing update process
On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le vendredi 22 juillet 2011 à 11:04 +0300, Ahmad Samir a écrit : On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. If the only problem is to reassign bugs, then we can write a script. My main worries are that given that right now, there is 1 single person in the group, that change nothing. I would even add that it proves my point, using alias mean that people do not know who they assign the bugs to. So while you think there is no point of failure, but there is, and you do not see nor know it. Also, assigning thing to a group of people tend to make them think someone else will do it :/ Finally, if the problem is someone can leave and we have to reassign bug, there is nothing special regarding security bugs to that regard, and we have the need to reassign others bugs too, and yet, we do not use aliases. So why make a exception just for that ? -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 22 July 2011 11:27, Michael Scherer m...@zarb.org wrote: Le vendredi 22 juillet 2011 à 11:04 +0300, Ahmad Samir a écrit : On 19 June 2011 15:00, Michael Scherer m...@zarb.org wrote: Le samedi 18 juin 2011 à 23:25 +0300, Ahmad Samir a écrit : On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. Yes, that requires to create a account for that. Dmorgan knows, I don't :/ ( and we should document that once the wiki will be installed ). The same for sec team, there should be a way to assign/put-in-CC. That would requires the creation of the secteam as something more formal than now, and for now, that's no. So you should better explain the need about assigning or put a group of people in CC when you can simply put one person for that. -- Michael Scherer Sorry, I seem to have missed this email. I can see secur...@groups.mageia.org can be set as bug assignee in bugzilla now, so the discussion is null at this point. About the better explanation, the benefits of having one generic email address set as assignee in security-related bug reports, just one point, not having one point of failure, if the only person in the sec team becomes unavailable for a prolonged period of time for any reason, someone will have to trudge through the bug reports assigned to him to change the assignee field, whereas if a generic email address is used that won't be necessary. If the only problem is to reassign bugs, then we can write a script. My main worries are that given that right now, there is 1 single person in the group, that change nothing. I would even add that it proves my point, using alias mean that people do not know who they assign the bugs to. So while you think there is no point of failure, but there is, and you do not see nor know it. Right. Sorry for wasting your time with my waffling then. Also, assigning thing to a group of people tend to make them think someone else will do it :/ Finally, if the problem is someone can leave and we have to reassign bug, there is nothing special regarding security bugs to that regard, and we have the need to reassign others bugs too, and yet, we do not use aliases. So why make a exception just for that ? -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On Sat, 18 Jun 2011, Ahmad Samir wrote: qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. It should be possible now (since friday actually). This bug for instance is assigned to qa-bugs@ : https://bugs.mageia.org/show_bug.cgi?id=1554
Re: [Mageia-dev] Finalizing update process
On 15 June 2011 22:32, Stew Benedict stewbi...@gmail.com wrote: On 06/15/2011 09:22 AM, Stew Benedict wrote: On 06/15/2011 08:50 AM, Dexter Morgan wrote: On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlundt...@mageia.org wrote: BTW, should we have a read-only security/update-announce ml that where we mail about all updates ? yes seems a must have to push updates descriptions , distributions affected, ... That is accounted for in the policy document (last line) Due to the unbridled enthusiasm for getting started on updates, we now have 4 trial packages :) vde2, mysql, curl, subversion Bugs: https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2) https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql) https://bugs.mageia.org/show_bug.cgi?id=1813 (curl) https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion) Packages need fixes applied, built for mga1 (I believe mysql is already in updates_testing), packager should do some initial testing then re-assign the bug to QA QA process for updates: http://mageia.org/wiki/doku.php?id=qa_updates -- Stew Benedict qa-bugs@ can't be be set as the assignee in bug reports, it should be made possible. The same for sec team, there should be a way to assign/put-in-CC. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 15 juin 2011 à 07:55 -0400, Stew Benedict a écrit : On 06/12/2011 08:25 AM, Angelo Naselli wrote: In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto: Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well here we could stop at QA team step, or at least someone more that can test and say that the fixing is good... So, We've had a lot of discussion, which is good, but imho we need to start getting some updates out the door. Users are asking for them and the CVEs just keep rolling in. As I understand it, the mechanics are in place to issue updates, and I've put together a page as a first pass at a policy, based on my memory of how things worked in the past and what I've picked up from the discussion. http://mageia.org/wiki/doku.php?id=updates_policy Randomly, I'm targeting 2 bugs to push through, to test the process: https://bugs.mageia.org/show_bug.cgi?id=1084 (vde2, app crashes) https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion, security issue) Now, first problem is we still don't have a maintainer database, so who gets the assignment, the person that first imported the package? Perhaps this is the first change to the policy - maintainer or any interested packager initiates the update Sound sensible, yes. The idea IMHO is not to prevent people for doing the work if they wish, but if there is no volunteer, it should be the duty of someone, and this someone is the maintainer. Now, we do not have a official maintainer db, but the test instance is still here afaik. So yes, picking someone from the list of person that committed would do the trick. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
Michael Scherer skrev 15.6.2011 15:10: Le mercredi 15 juin 2011 à 07:55 -0400, Stew Benedict a écrit : On 06/12/2011 08:25 AM, Angelo Naselli wrote: In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto: Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well here we could stop at QA team step, or at least someone more that can test and say that the fixing is good... So, We've had a lot of discussion, which is good, but imho we need to start getting some updates out the door. Users are asking for them and the CVEs just keep rolling in. As I understand it, the mechanics are in place to issue updates, and I've put together a page as a first pass at a policy, based on my memory of how things worked in the past and what I've picked up from the discussion. http://mageia.org/wiki/doku.php?id=updates_policy Randomly, I'm targeting 2 bugs to push through, to test the process: https://bugs.mageia.org/show_bug.cgi?id=1084 (vde2, app crashes) https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion, security issue) Now, first problem is we still don't have a maintainer database, so who gets the assignment, the person that first imported the package? Perhaps this is the first change to the policy - maintainer or any interested packager initiates the update Sound sensible, yes. The idea IMHO is not to prevent people for doing the work if they wish, but if there is no volunteer, it should be the duty of someone, and this someone is the maintainer. Now, we do not have a official maintainer db, but the test instance is still here afaik. So yes, picking someone from the list of person that committed would do the trick. BTW, should we have a read-only security/update-announce ml that where we mail about all updates ? -- Thomas
Re: [Mageia-dev] Finalizing update process
On 06/15/2011 08:50 AM, Dexter Morgan wrote: On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlundt...@mageia.org wrote: BTW, should we have a read-only security/update-announce ml that where we mail about all updates ? yes seems a must have to push updates descriptions , distributions affected, ... That is accounted for in the policy document (last line) -- Stew Benedict
Re: [Mageia-dev] Finalizing update process
On 06/15/2011 09:22 AM, Stew Benedict wrote: On 06/15/2011 08:50 AM, Dexter Morgan wrote: On Wed, Jun 15, 2011 at 2:20 PM, Thomas Backlundt...@mageia.org wrote: BTW, should we have a read-only security/update-announce ml that where we mail about all updates ? yes seems a must have to push updates descriptions , distributions affected, ... That is accounted for in the policy document (last line) Due to the unbridled enthusiasm for getting started on updates, we now have 4 trial packages :) vde2, mysql, curl, subversion Bugs: https://bugs.mageia.org/show_bug.cgi?id=1678 (vde2) https://bugs.mageia.org/show_bug.cgi?id=1554 (mysql) https://bugs.mageia.org/show_bug.cgi?id=1813 (curl) https://bugs.mageia.org/show_bug.cgi?id=1521 (subversion) Packages need fixes applied, built for mga1 (I believe mysql is already in updates_testing), packager should do some initial testing then re-assign the bug to QA QA process for updates: http://mageia.org/wiki/doku.php?id=qa_updates -- Stew Benedict
Re: [Mageia-dev] Finalizing update process
In data mercoledì 8 giugno 2011 23:53:51, Ahmad Samir ha scritto: Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well here we could stop at QA team step, or at least someone more that can test and say that the fixing is good... -- Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] Finalizing update process
'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble: On 8 June 2011 23:38, Stew Benedict stewbi...@gmail.com wrote: On 06/08/2011 05:31 PM, Michael Scherer wrote: Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Schererm...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) You're right (even if that's never happened for 3-4 years in mdv, since sec team rebuilt the packages when pushing to */updates IIRC). Personally, and this might just be me, I always submit my packages to *testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my various iterations. When I'm happy and when it's ready to pass to QA, I set the subrel to 1. This way the final version that should hit updates is nice and neat. In an ideal world, QA would validate it for me then change the subrel for me. That process would require a rebuild. I'm not sure what others feel about this? It's not impossible to just do this as a matter of course as part of the process we go through and increment subrel to a round number before handing over to QA... although maybe I'm just a bit too anal about neat version numbers :p Col -- Colin Guthrie mageia(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/]
Re: [Mageia-dev] Finalizing update process
On Thu, 09 Jun 2011, Michael Scherer wrote: Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit : Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. Sorry to be picky, but there is no submit to */release, it is frozen. And in my proposition, there is also no submit to */update, there is a move from */updates_testing. In that case, if the package is not rebuilt and only moved from */updates_testing, we need to disable the */updates_testing repository in iurt during builds of packages for */updates_testing repository, to make sure it is not linked to an other testing package. I think this was not the case on testing repository on mandriva.
Re: [Mageia-dev] Finalizing update process
Le jeudi 9 juin 2011 11:05:16, Colin Guthrie a écrit : 'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble: On 8 June 2011 23:38, Stew Benedict stewbi...@gmail.com wrote: If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) You're right (even if that's never happened for 3-4 years in mdv, since sec team rebuilt the packages when pushing to */updates IIRC). Personally, and this might just be me, I always submit my packages to *testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my various iterations. When I'm happy and when it's ready to pass to QA, I set the subrel to 1. This way the final version that should hit updates is nice and neat. In an ideal world, QA would validate it for me then change the subrel for me. That process would require a rebuild. I'm not sure what others feel about this? It's not impossible to just do this as a matter of course as part of the process we go through and increment subrel to a round number before handing over to QA... although maybe I'm just a bit too anal about neat version numbers :p Neat version numbers are great, so I like your way of doing updates :) Samuel
Re: [Mageia-dev] Finalizing update process
Le jeudi 9 juin 2011 07:00:24, Anssi Hannula a écrit : On 09.06.2011 02:25, Michael Scherer wrote: I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Yes. Note that this applies to some other software that communicates with outside systems as well, e.g. subdownloader. Maybe also Vuze if the content delivery system requires a version update. Maybe the correct phrasing would be something like: - Packages where some functions no longer work due to remote server changes, requiring a newer version of the package. Agreed. Samuel
Re: [Mageia-dev] Finalizing update process
Samuel Verschelde a écrit : Le jeudi 9 juin 2011 11:05:16, Colin Guthrie a écrit : 'Twas brillig, and Ahmad Samir at 08/06/11 22:48 did gyre and gimble: On 8 June 2011 23:38, Stew Benedict stewbi...@gmail.com wrote: If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) You're right (even if that's never happened for 3-4 years in mdv, since sec team rebuilt the packages when pushing to */updates IIRC). Personally, and this might just be me, I always submit my packages to *testing with a subrel of 0.1, 0.2 0.3 etc etc. Users then test my various iterations. When I'm happy and when it's ready to pass to QA, I set the subrel to 1. This way the final version that should hit updates is nice and neat. In an ideal world, QA would validate it for me then change the subrel for me. That process would require a rebuild. I'm not sure what others feel about this? It's not impossible to just do this as a matter of course as part of the process we go through and increment subrel to a round number before handing over to QA... although maybe I'm just a bit too anal about neat version numbers :p Neat version numbers are great, so I like your way of doing updates :) Samuel I like this approach too. Very nice :) Especially the idea of incrementing subrel to a round number before handing to QA. And if QA finds a problem, we could revert to the decimal increment sequence until fixed, before incrementing to a round number for QA again. (The same round number, or would it be better to use the next ?) -- André
[Mageia-dev] Finalizing update process
Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Cheers -- Anne http://www.mageia.org
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So the points are : - no update can be uploaded without QA validation - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 18:44, Michael Scherer m...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So the points are : - no update can be uploaded without QA validation - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) -- Michael Scherer -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. So the points are : - no update can be uploaded without QA validation What does 'QA validation' mean exactly, can only certain people do it...? - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Christiaan
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 19:39, Ahmad Samir ahmadsamir3...@gmail.com wrote: On 8 June 2011 18:57, Christiaan Welvaart c...@daneel.dyndns.org wrote: On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? - the bug is closed - a announce is sent ( on various medias to be defined ), with the text of update So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports - The QA team couldn't validate, i.e. using the test case in the bug report, their test results didn't show that the bug is fixed Adding to this: - the bug is fixed, but it caused regressions somewhere else in the package itself, or in packages depending on it. So the points are : - no update can be uploaded without QA validation What does 'QA validation' mean exactly, can only certain people do it...? IIUC, QA validation is that they use the test case given in the report; an example of a test case: - install package foo-1mga1 from */release - do foo bar, notice the app crashes - install the fixed package foo-1.1mga1 from */updates_testing - test again, the bug should be fixed if any of these steps fail, then it's not gonna get pushed as an update. And it should be the QA team doing the validation, i.e. experienced devs/packagers in the that team. - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Not the packager committing the fix, (if he doesn't think it's fixed he won't ask for an update to begin with). But the QA team, this team could/should have packagers in it. Christiaan -- Ahmad Samir -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Scherer m...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 06/08/2011 05:31 PM, Michael Scherer wrote: Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Schererm...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) -- Stew Benedict New Tazewell, TN
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 23:38, Stew Benedict stewbi...@gmail.com wrote: On 06/08/2011 05:31 PM, Michael Scherer wrote: Le mercredi 08 juin 2011 à 19:48 +0300, Ahmad Samir a écrit : On 8 June 2011 18:44, Michael Schererm...@zarb.org wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Isn't it cleaner to rebuild when submitting to */updates? instead of moving. Well, that depend on the way package is built. In fact, it should not matter much, as we should not do a change that could break a existing software in update, and so this should be the same in updates_testing ( ie, they should be the same wrto ABI ) But that's also why I ask here :) If you're going to rebuild *after* QA, you've just invalidated your QA. (yeah, I know it *should* be the same, but stuff happens) You're right (even if that's never happened for 3-4 years in mdv, since sec team rebuilt the packages when pushing to */updates IIRC). -- Stew Benedict New Tazewell, TN -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. -- Anssi Hannula -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 20:39 +0300, Ahmad Samir a écrit : On 8 June 2011 18:57, Christiaan Welvaart c...@daneel.dyndns.org wrote: So who decides to reject an update and at what point? According to your proposal, either QA people decide this or they waste time on updates that later get rejected. IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports I would say that there is no version upgrade, unless exception. - The QA team couldn't validate, i.e. using the test case in the bug report, their test results didn't show that the bug is fixed Yup. Or someone detected a regression. ( like 'I installed foo-1.0-1 but it opened a dimensional vortex to hell', as it happened on the QA testing facility of Phobos in Doom ) - QA manage the checks, and so will requires help ( hence the security team or any packager can help, provided they know how to do QA ) So a packager wants to fix a bug in package that is not very visible, sends it to QA, then has to test it anyway? I'm not sure what you're saying here. Not the packager committing the fix, (if he doesn't think it's fixed he won't ask for an update to begin with). Yup :) But the QA team, this team could/should have packagers in it. Or someone could help by doing QA and saying so far, I see no regression, or just saying I see regression before some more experienced QA member do the test. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
Le mercredi 08 juin 2011 à 18:57 +0200, Christiaan Welvaart a écrit : On Wed, 8 Jun 2011, Michael Scherer wrote: Le mercredi 08 juin 2011 à 10:40 +0200, Anne nicolas a écrit : Hi there We have some stuff to complete here: http://mageia.org/wiki/doku.php?id=security http://mageia.org/wiki/doku.php?id=securityCan we spend the 2 or 3 coming days to finalize it and start updates submits? Pascal is working on this. So here is a proposal : - anybody can submit a package to updates_testing. - once submitted to testing, it should ask to QA to test, along with : - a reason for the update ( likely bug number ) - potentially a priority ( ie, if this is just a translation update or a urgent 0 day exploit ) - a way to test the bug and see it is fixed - text for the update - qa validate the update ( with process to define ) - someone move the package from updates_testing to testing Someone from security (stable updates) team I guess? Someone who type the command would be a admin ( until someone decide to write a script for that, and to plug it to the current restricted shell framework ). Who decide exactly what should og or not is open. IE, that the part of the process to define. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well, I didn't asked to secteam to do anything except managing the security aspect : - finding CVE - finding patch ( with the help of maintainer ) - finding test and fixes But the building and updating should be done by maintainer, as this would scale better. Let the security team focus on the security aspect, and be there as a help for maintainers and viceversa. We shouldn't overload the secteam, while maintainers are here for that :) One of the problem at Mandriva was that security and stable updates were quite disconnected from maintainers, and so it didn't scale well. It didn't scale because people didn't know security procedure ( it was not part of the expected curriculum of a packager, and often was done without them implied ), it didn't scale because security was only for a restricted set of salaree taking care of everything on separate systems. I think we should focus on having : - a system using already know procedure ( ie regular build system ) - make sure that taking care of update is something done regulary as part as packager duty ( after all, that's the whole part of being maintainer ) (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. segfault, crash are the duty of packager, as well as wrong requires or anything. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 9 June 2011 01:25, Michael Scherer m...@zarb.org wrote: Le jeudi 09 juin 2011 à 00:53 +0300, Ahmad Samir a écrit : On 8 June 2011 23:40, Anssi Hannula anssi.hann...@iki.fi wrote: On 08.06.2011 23:23, Ahmad Samir wrote: On 8 June 2011 21:45, Samuel Verschelde sto...@laposte.net wrote: Le mercredi 8 juin 2011 19:39:55, Ahmad Samir a écrit : IMHO, rejection reasons: - The sec team doesn't think the update fixes a serious security vulnerability; so it's not updates but backports What about bugfix updates ? I guess fixing a bug is a valid reason for an update, like it was in Mandriva's updates. Regards Samuel Right, I probably phrased that one wrongly; I meant: fixes a serious bug, e.g. crashing, segfaulting I don't think we should exclude non-serious bugs :) Depends, overworking the sec team doesn't look like a good aspect... (that's why I liked contrib in mdv, I could push an update any time, without having to go though the bug report - QA - Sec team loop). Well, I didn't asked to secteam to do anything except managing the security aspect : - finding CVE - finding patch ( with the help of maintainer ) - finding test and fixes But the building and updating should be done by maintainer, as this would scale better. Let the security team focus on the security aspect, and be there as a help for maintainers and viceversa. We shouldn't overload the secteam, while maintainers are here for that :) One of the problem at Mandriva was that security and stable updates were quite disconnected from maintainers, and so it didn't scale well. It didn't scale because people didn't know security procedure ( it was not part of the expected curriculum of a packager, and often was done without them implied ), it didn't scale because security was only for a restricted set of salaree taking care of everything on separate systems. I think we should focus on having : - a system using already know procedure ( ie regular build system ) - make sure that taking care of update is something done regulary as part as packager duty ( after all, that's the whole part of being maintainer ) (or version updates in some cases, like firefox/opera/flash or updating an rc/beta version to a stable one, and maybe some online games that are useless unless on latest version) I agree, (except for the games part, nowadays if it's less than 4GB it's not really a game). I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Maybe the sec team should only work on sec fixes, and there should be a sub-group of the sec team that handle the not CVE|crash|segfaulting|buffer-overflow updates. segfault, crash are the duty of packager, as well as wrong requires or anything. -- Michael Scherer Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. -- Ahmad Samir
Re: [Mageia-dev] Finalizing update process
Le jeudi 09 juin 2011 à 02:40 +0300, Ahmad Samir a écrit : Yes, but I was talking about the actual submitting to */release, not fixing the package itself. IIUC the submission rights will be restricted to the Sec team. Sorry to be picky, but there is no submit to */release, it is frozen. And in my proposition, there is also no submit to */update, there is a move from */updates_testing. So for managing the submit to updates_testing and the whole process, I think it should be open to any packagers. It should be maintainers responsibility to do the update ( prepare, do a test build, check, submit ), even if secteam members could be proactive for that. But the process should not be restricted to them, or it will not scale ( and given we want to have bugfixes updates, it wouldn't make much sense to call the team like this ). Since ensuring that a update is a minimal change is (to me) a quality issue, I propose to add to the QA list of things to check before refusing a update : it doesn't fullfill the requirement of minimal changes ( with exceptions But that requires QA people to have minimal packaging notions, which could be a problem :/ Again, nothing prevent people from the secteam to also be part of the QA team. -- Michael Scherer
Re: [Mageia-dev] Finalizing update process
On 09.06.2011 02:25, Michael Scherer wrote: I guess we can start with a list of exception : - stuff that should be updated to latest version, because the security support for older releases ( firefox, chrome ) is too hard - we update to latest version if there is no regression and a strong reason to upgrade ( severe bugfixes, security issue, breakages ). Exception of this category should be very expectional - stuff where there is strict bugfixes only release ( postgresql ), or update to a stable version ( which should be a bugfix only release when compared to beta/rc :) ) - we upgrade to stable ( for rc/beta ) - we do version update if it is bug fixes and if the packager is ok with it ( and if the rules of the bugfix branches are clearly documented ) - everything else - only minimal patches The question of game is still open, ie, should it go in 1st category, or should we have different rules to see what should be there or not ? I guess this would only be for networked game ? Yes. Note that this applies to some other software that communicates with outside systems as well, e.g. subdownloader. Maybe also Vuze if the content delivery system requires a version update. Maybe the correct phrasing would be something like: - Packages where some functions no longer work due to remote server changes, requiring a newer version of the package. -- Anssi Hannula
