Re: [Mageia-dev] Proposal for bug statuses and workflow
Samuel Verschelde a écrit : Here is a workflow proposal for bug reports in bugzilla. [...] Best regards Samuel Verschelde I think it is really well thought out. Especially renaming certain statuses, to better coincide with their usage. The resolutions as well. Only one question : The NEW + triaged keyword status seems ok, but I can see Marja's point that it might be better to have an explicit TRIAGED status. What happens if the bug is not ACCEPTED, or there is no maintainer ? The bug is just left in this state ? (Looks like you're making good use of the Libreoffice Draw flowcharting.) In sum, WORKS_FOR_ME :) -- André
Re: [Mageia-dev] Proposal for bug statuses and workflow
On Wed, Oct 19, 2011 at 23:30, Samuel Verschelde sto...@laposte.net wrote: CLOSED replaces RESOLVED, because I think it's nicer for the bug reporter if we close bugs rather than consider them resolved when the reason for closing is WONT-FIX, DUPLICATE, OLD, etc., statuses that obviously don't match the meaning of RESOLVED. RESOLVED does match. Beware, this is a known false friend in English/French (although it is used in a equivalent meaning as in Je suis résolu à or J'ai pris la ferme résolution de). To resolve is to decide firmly, not to solve (well, as well, but in a later meaning). If the RESOLVED status in Bugzilla had been understood as SOLVED, then RESOLVED - FIXED would be a pleonasm. Romain
Re: [Mageia-dev] Proposal for bug statuses and workflow
Le 20/10/2011 10:26, Romain d'Alverny a écrit : If the RESOLVED status in Bugzilla had been understood as SOLVED, then RESOLVED - FIXED would be a pleonasm. You can solve a problem differently than fixing it, for instance by claiming it is not a problem, or that it is too old to really care. -- BOFH excuse #138: BNC (brain not connected)
Re: [Mageia-dev] Proposal for bug statuses and workflow
On Thu, Oct 20, 2011 at 10:43, Guillaume Rousse guillomovi...@gmail.com wrote: Le 20/10/2011 10:26, Romain d'Alverny a écrit : If the RESOLVED status in Bugzilla had been understood as SOLVED, then RESOLVED - FIXED would be a pleonasm. You can solve a problem differently than fixing it, for instance by claiming it is not a problem, or that it is too old to really care. That's precisely the resolution to the problem: fixed (and the solution is provided along here) or discarded or reported elsewhere. https://bugs.mageia.org/page.cgi?id=fields.html#status is more visual about this. Romain
Re: [Mageia-dev] Proposal for bug statuses and workflow
Le jeudi 20 octobre 2011 06:35:32, Marja van Waes a écrit : BTW, replacing status NEW + keyword Triaged by status TRIAGED, and leaving all the rest the same, would solve another problem and save time ;) +1 The less keywords we have, the better is : they are error prone. NEEDINFO can't be a status as it may happen everywhere in the workflow, but TRIAGED is only once.
Re: [Mageia-dev] Proposal for bug statuses and workflow
Le mercredi 19 octobre 2011 à 23:30 +0200, Samuel Verschelde a écrit : Here are the proposed Resolutions: Another thing, what about the upstream reported bugs ? In Mandriva they have a status REPORTEDUPSTREAM (if the triage_guide is true) Can we do the same ? http://mageia.org/wiki/doku.php?id=triage_guide#is_it_an_issue_that_should_be_covered_by_the_mageia_bug_process
[Mageia-dev] imagemagick 6.7
with the imagemagick of cauldron, this syntax does not work anymore to extract the icon number 8 : convert 'file.ico[8]' file.png : convert: unable to open image `file.ico[8]': No such file or directory @ error/blob.c/OpenBlob/2589. convert: no decode delegate for this image format `file.ico[8]' @ error/constitute.c/ReadImage/532. convert: missing an image filename `file.png' @ error/convert.c/ConvertImageCommand/3016. This prevent wine submit as of now : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20111020110738.zezinho.valstar.2548/log/ Does anyone have a clever clue ? Thanks zezinho
Re: [Mageia-dev] Proposal for bug statuses and workflow
Romain d'Alverny a écrit : On Wed, Oct 19, 2011 at 23:30, Samuel Verscheldesto...@laposte.net wrote: CLOSED replaces RESOLVED, because I think it's nicer for the bug reporter if we close bugs rather than consider them resolved when the reason for closing is WONT-FIX, DUPLICATE, OLD, etc., statuses that obviously don't match the meaning of RESOLVED. RESOLVED does match. Beware, this is a known false friend in English/French (although it is used in a equivalent meaning as in Je suis résolu à or J'ai pris la ferme résolution de). To resolve is to decide firmly, not to solve (well, as well, but in a later meaning). Sorry, but I think they have the same meanings in English and French. Which isn't surprising, considering that it comes from French. [...] Romain In English, RESOLVED can refer to decision, solving, or something in between. In the context of a bug report, what are we doing ? Maybe we discovered what the problem was. Maybe we fixed it, maybe not. But whatever the reason, the action is closing the report. Let's avoid obtuse language, and simply say CLOSED. It has the advantage of being able to give a clear reason of fixed, without any redundancy. aside This reminds me of proceedings at political conventions : Whereas ... and ... be it resolved that ... (Usually something that is never done.) /aside -- André
Re: [Mageia-dev] Proposal for bug statuses and workflow
Am 19.10.2011 23:30, schrieb Samuel Verschelde: Here is a workflow proposal for bug reports in bugzilla. See the flowchart (link below) and the explanations below. Not all statuses will be used in every bug report, but the flowchart more or less gives the standard flow for bugs reported against a stable release of Mageia. http://stormi.lautre.net/fichiers/mageia/triage.png NEW: as currently, bugs are set to this status when created NEW (+ NEEDINFO keyword): more input needed Why not set NEEDINFO keyword by default when a bug is reported and a triager or the maintainer removes it then if sufficient information to work on this bug is already present? I'd say this being a keyword and not mandatory it will be forgotten often IMHO. NEW (+ Triaged keyword): ACCEPTED IN_PROGRESS really fine-grained but useless IMHO. If it has been triaged, there should be someone who works on that bug, and what reason would there be to not accept a bug? Just my humble opinion. If those help to ease triage, why not.
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
Op donderdag 20 oktober 2011 00:26:54 schreef Pascal Terjan: On Wed, Oct 19, 2011 at 21:36, Maarten Vanraes al...@rmail.be wrote: Hi, is there someone who can help me understand the stage1/stage2/rescue system? or point to some docs? i've looked at it, but it seems to be sometimes one source file used for both... it's really confusing me. Sources in mdk-stage1/ are used to build several binaries (including init, stage1 and rescue-gui) images/make_boot_img is used to generate the boot images which will include stage1 and busybox do i need to install busybox rpm before executing this script? rescue/ is used to make rescue.sqfs image which contains a /etc/rc.sysinit which will prepare things and then run rescue-gui At the end stage1, if in rescue mode, the rescue image get loaded (from local cd, ftp, http, ...), mounted and the code is run (else same happens to stage2) by any chance, do you know where i can make these rescue menuitems?
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
Op donderdag 20 oktober 2011 00:26:54 schreef Pascal Terjan: On Wed, Oct 19, 2011 at 21:36, Maarten Vanraes al...@rmail.be wrote: Hi, is there someone who can help me understand the stage1/stage2/rescue system? or point to some docs? i've looked at it, but it seems to be sometimes one source file used for both... it's really confusing me. Sources in mdk-stage1/ are used to build several binaries (including init, stage1 and rescue-gui) images/make_boot_img is used to generate the boot images which will include stage1 and busybox rescue/ is used to make rescue.sqfs image which contains a /etc/rc.sysinit which will prepare things and then run rescue-gui At the end stage1, if in rescue mode, the rescue image get loaded (from local cd, ftp, http, ...), mounted and the code is run (else same happens to stage2) oh and can i test this rescue.sqfs somehow (without fucking up work system) or need i build an iso?
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
On Thu, Oct 20, 2011 at 17:40, Maarten Vanraes al...@rmail.be wrote: Op donderdag 20 oktober 2011 00:26:54 schreef Pascal Terjan: On Wed, Oct 19, 2011 at 21:36, Maarten Vanraes al...@rmail.be wrote: Hi, is there someone who can help me understand the stage1/stage2/rescue system? or point to some docs? i've looked at it, but it seems to be sometimes one source file used for both... it's really confusing me. Sources in mdk-stage1/ are used to build several binaries (including init, stage1 and rescue-gui) images/make_boot_img is used to generate the boot images which will include stage1 and busybox do i need to install busybox rpm before executing this script? I would suggest that you look at the drakx-installer-images rpm dependencies I usually build the rpm rescue/ is used to make rescue.sqfs image which contains a /etc/rc.sysinit which will prepare things and then run rescue-gui At the end stage1, if in rescue mode, the rescue image get loaded (from local cd, ftp, http, ...), mounted and the code is run (else same happens to stage2) by any chance, do you know where i can make these rescue menuitems? Without looking, I would say in rescue-gui.c but I may be wrong
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
On Thu, Oct 20, 2011 at 17:41, Maarten Vanraes al...@rmail.be wrote: oh and can i test this rescue.sqfs somehow (without fucking up work system) or need i build an iso? You can place it somewhere, for example accessible over ftp or http in a directory called something/install/stage2, and boot an install image in a vm
Re: [Mageia-dev] [packages-commits] [156965] Fix for the GIF load Overflow ( https://bugs.mageia.org/show_bug. cgi?id=3096 )
2011/10/20 r...@mageia.org: Revision 156965 Author shlomif Date 2011-10-20 20:16:23 +0200 (Thu, 20 Oct 2011) Log Message Fix for the GIF load Overflow ( https://bugs.mageia.org/show_bug.cgi?id=3096 ) ...snip.. --- updates/1/gimp/current/SPECS/gimp.spec2011-10-20 18:11:10 UTC (rev 156964) +++ updates/1/gimp/current/SPECS/gimp.spec2011-10-20 18:16:23 UTC (rev 156965) @@ -1,6 +1,6 @@ %define name gimp %define version 2.6.11 -%define release %mkrel 6 +%define release %mkrel 7 %define lib_major 0 You should use subrel when pushing new releases to stable one.
Re: [Mageia-dev] require help to understand stage1/stage2/rescue source files
Op donderdag 20 oktober 2011 19:11:07 schreef Pascal Terjan: On Thu, Oct 20, 2011 at 17:41, Maarten Vanraes al...@rmail.be wrote: oh and can i test this rescue.sqfs somehow (without fucking up work system) or need i build an iso? You can place it somewhere, for example accessible over ftp or http in a directory called something/install/stage2, and boot an install image in a vm so, then i can just use any boot.iso to do this? or does that boot.iso need to be built especially for this? i remember that i once tried to start install from older boot.iso and it didn't work...
Re: [Mageia-dev] Proposal for bug statuses and workflow
On Wed, 19 Oct 2011 17:30:05 -0400, Samuel Verschelde sto...@laposte.net wrote: VALIDATED is set by QA team once testing ends. It means that the update can be pushed (replaces the validated_update keyword) Will changing the status automatically update the assigned, for Testing and Validated? If changing the status to Validated changes the assigned from qa-bugs to sysadmin-bugs, qa-bugs should be added to the cc list. Regards, Dave Hodgins
[Mageia-dev] Please test dracut (mkinitrd replacement)
Hi, Due to upcoming changes to systemd and friends we'll likely need to use dracut rather than mkinitrd for some setups (i.e. those with LVM volumes defined in /etc/fstab) It would be good if people here could test as we will likely make it the default at some point in the not too distant future. To test: sudo -i (or su -) urpmi dracut cd /boot mv initrd-3.1.0-desktop-0.rc10.1.mga2.img initrd-old.img /sbin/installkernel -N 3.1.0-desktop-0.rc10.1.mga2 This should install dracut, move the existing initrd out of the way, and regenerate a new one using dracut. If you are using a different kernel version then adjust the two commands accordingly to pick the right version. Then just reboot. Hopefully all will go well and you won't notice much difference :) If it fails you should still be able to use the previous initrd by editing the grub command line and specifying the initrd-old.img file manually. Cheers Col -- Colin Guthrie colin(at)mageia.org 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] imagemagick 6.7
Le vendredi 21 octobre 2011 01:20:17, Colin Guthrie a écrit : FWIW, -delete 1--1 also works to extract the first frame... similar logic could be used to extract the 8th frame, but I like the previous syntax better so will look into restoring how my old code worked :) You don't need to search : it is fixed upstream.
