Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
On 03/01/12 10:09, Wolfgang Bornath wrote: 2012/1/3 Michael Scherer: Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit : Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer: Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : Hi everyone, Can someone please help to fix bug 1956? You don't need to be a regular forum visitor. We need someone to find and implement a probably existing MOD, needed to keep forum posts history when unlimited edit time is enabled From wobo's comment #32: Capabilities needed: Well, one could say that anybody who - knows how to run phpBB as admin and - has seen a line of php - knows how to edit code (respecting tags and such) - knows how to cut&paste should be able to install an existing MOD (if I'm not mistaken there is one or more). I know next to nothing about php coding. But I've been running a phpBB forum for a couple of years and successfully implemented some MODs in phpBB2 and phpBB3. With no help (except the phpBB-forum in case of problems). In practice you have a detailed installation README for each MOD. Like - open file /foo/bar/doo.php - Find the line which starts with '..' - After that add - "." And more such step-by-step guidance My eyes start to bleed dues to such "guidances". i'm sure misc means to say that we should have all our changes in packages/puppet config so that we can update without issues. and with file edits, that's a whole different thing. I was more thinking of proper patchs or better, proper modules, with files to deploy in a well know directory . I only gave a part of an example. MODs are made as enhancement to the standard software. The easiest MOD is like Michael wrote: "a module with files to deploy in a well known directory". But in most cases they consist of files to copy into various directories of the program tree and changes to existing files of the software. There are other MODs which can be implemented automatically - which is far worse IMHO. This is where a modded phpBB3 could turn into a nightmare to maintain - believe me, I've been there :( Of course no developper of a MOD could know what somebody has already done to the standard files, so it's not possible do use only patches. And it could be (and that happens quite often) that a MOD is not compatible to your already "modificated" forum software (destroys other modifications or whatever). IMHO the best way in this case here would be a mod written for our setup, all changes well defined to make it maintainable in a proper way. Saying this I beg to think again whether the issue justifies all the time and work. It would make me very, very happy, does that count a little? If I were sure that I'd be able to learn how to do it, I would now consider to halve the time I use for the Bug Squad and Doc Team and start learning.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Am 11.01.2012 08:57, schrieb Buchan Milne: > On Wednesday, 11 January 2012 06:32:50 Johnny A. Solbu wrote: >> On Wednesday 11 January 2012 03:28, Luis Daniel Lucio Quiroz wrote: >>> I mean, stop asking updates for mageia 1 just because there is another >>> newversion. >> May I suggest that next time, say it in so many words. >> >> Some of us are not good at reading between the lines, and your original >> post was written in a way that indicated that it was not clear on that you >> where talking about just what you said you where talking about in your >> last post. :-)= >> >> >> And I agree with you. Updating packages in a released product just because >> a new version is out is not a valid reason by itself. If on the other hand >> it fixes some bugs or security holes, it's worth considering. > Resolving the backports situation would however provide a means for users who > want to track upstream (for various reasons, such as being able to get > support > from upstreams who don't really want to support 'historic' releases) without: > 1)Forcing all users to get the update > 2)Requiring excessive QA work > 3)Requiring bug reports for each update Well, 2) and 3) are not valid reasons here, because backports should get a similar amount of QA testing as normal update candidates, and for the updates policy require a bugreport for validation through QA. Check https://wiki.mageia.org/en/Backports_policy#Steps and https://wiki.mageia.org/en/Updates_policy > Regards, > Buchan >
Re: [Mageia-dev] Fosdem 2012 - Mageia stand
'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble: > as you might already know from previous mails or from the blog post published > yesterday, Mageia is (again) attending Fosdem this year. > http://blog.mageia.org/en/2012/01/10/happy-new-mageia-year/ > > > Aside from participating in some discussion sessions and a talk done by misc, > we are also having a stand there for showing mageia to the public. > For this we do still need some help from you. We should have two people there > all the time and as you might imagine, nobody wants to stand there all day. > So if you are attending FOSDEM this year and are willing to help us, please > enter your name here: > https://wiki.mageia.org/en/Fosdem_2012#Mageia_booth > > Looking forward to meeting many people there, In a stunning break from the norm, I've actually managed to not plan a skiing holiday over the FOSDEM weekend... Misc won't believe me but I WILL be there! Added my name to the list. 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] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
2012/1/11 Marja van Waes : > On 03/01/12 10:09, Wolfgang Bornath wrote: >> >> 2012/1/3 Michael Scherer: >>> >>> Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit : Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer: > > Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : >> >> Hi everyone, >> >> Can someone please help to fix bug 1956? >> >> You don't need to be a regular forum visitor. >> >> We need someone to find and implement a probably existing MOD, needed >> to keep forum posts history when unlimited edit time is enabled >> >> From wobo's comment #32: >> Capabilities needed: >> Well, one could say that anybody who >> >> - knows how to run phpBB as admin and >> - has seen a line of php >> - knows how to edit code (respecting tags and such) >> - knows how to cut&paste >> >> should be able to install an existing MOD (if I'm not mistaken there >> is >> one or more). >> >> I know next to nothing about php coding. But I've been running a phpBB >> forum for a couple of years and successfully implemented some MODs in >> phpBB2 and phpBB3. With no help (except the phpBB-forum in case of >> problems). >> >> In practice you have a detailed installation README for each MOD. Like >> >> - open file /foo/bar/doo.php >> - Find the line which starts with '..' >> - After that add >> - "." >> >> And more such step-by-step guidance > > My eyes start to bleed dues to such "guidances". i'm sure misc means to say that we should have all our changes in packages/puppet config so that we can update without issues. and with file edits, that's a whole different thing. >>> >>> I was more thinking of proper patchs or better, proper modules, with >>> files to deploy in a well know directory . >> >> I only gave a part of an example. MODs are made as enhancement to the >> standard software. The easiest MOD is like Michael wrote: "a module >> with files to deploy in a well known directory". But in most cases >> they consist of files to copy into various directories of the program >> tree and changes to existing files of the software. There are other >> MODs which can be implemented automatically - which is far worse IMHO. >> This is where a modded phpBB3 could turn into a nightmare to maintain >> - believe me, I've been there :( >> >> Of course no developper of a MOD could know what somebody has already >> done to the standard files, so it's not possible do use only patches. >> And it could be (and that happens quite often) that a MOD is not >> compatible to your already "modificated" forum software (destroys >> other modifications or whatever). >> >> IMHO the best way in this case here would be a mod written for our >> setup, all changes well defined to make it maintainable in a proper >> way. Saying this I beg to think again whether the issue justifies all >> the time and work. >> > It would make me very, very happy, does that count a little? If I were sure > that I'd be able to learn how to do it, I would now consider to halve the > time I use for the Bug Squad and Doc Team and start learning. Why? IMHO this complete issue is going out of proportions. Let's remember why we *seem to need* this MOD in the first place. And what will we find? The time-to-edit discussion, again. In the council meeting where it was decided to have this mod It looked as the best way to please a disturbing minority request, the more as that same minority gave the impression that such a MOD could be implemented within a reasonable time span. As we see now after 8 months, this was never the case. Adding the fact that a test period of several months with a much looser time-to-edit setting in the German Mageia forum showed not one single case of misuse brings me to the conviction that we should rather rethink the time-to-edit limitation itself than to waste manpower on this issue. Manpower which is needed at more important tasks, if I may say. -- wobo
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
Am Mittwoch, 11. Januar 2012, 10:54:58 schrieb Wolfgang Bornath: > Why? IMHO this complete issue is going out of proportions. Let's > remember why we *seem to need* this MOD in the first place. And what > will we find? The time-to-edit discussion, again. In the council > meeting where it was decided to have this mod It looked as the best > way to please a disturbing minority request, the more as that same > minority gave the impression that such a MOD could be implemented > within a reasonable time span. As we see now after 8 months, this was > never the case. > > Adding the fact that a test period of several months with a much > looser time-to-edit setting in the German Mageia forum showed not one > single case of misuse brings me to the conviction that we should > rather rethink the time-to-edit limitation itself than to waste > manpower on this issue. Manpower which is needed at more important > tasks, if I may say. +1
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
Colin Guthrie a écrit : 'Twas brillig, and andre999 at 10/01/12 03:12 did gyre and gimble: Juan Luis Baptiste a écrit : On Mon, Jan 9, 2012 at 6:38 PM, Anssi Hannula wrote: I'm absolutely fine with either moving codecs to core or tainted, as long as we are at least somewhat consistent in what is in core and what is in tainted. However, I do not really like the reasoning "we do it like mandriva did no matter if it is sensible or not". I'd possibly understand "we do it like mandriva did because they didn't apparently have problems with these pkgs", but it IMHO wouldn't really fly as we could just s/mandriva/ubuntu/ in that statement (and Ubuntu is much more prominent than mdv IMO) and then everything would be in core... IMHO, for sake's of simplicity and user friendliness, we should leave everything in core until there's a real threat from someone about patents. Surely if it appears some day, we wouldn't be the first ones to be approached which would leave us plenty of time to correct this issue and move affected packages to tainted. I strongly agree with this approach. I don't. Especially not with this message now in a public forum admitting that we'd just be sticking our heads in the sand with regards to this issue. If any legal action was taken, any efforts to plan for and deal with the issues involved will be seen as a sign of good faith. This is very much the opposite and thus would lead to stronger legal action should it ever come to that. I really do not get the problem with splitting things out into the appropriate repos. The only real question is about whether to enable those repos by default and include the RPMs. We're talking about codecs, essentially the decoders which are used to read encoded files. If the patent claims are valid/enforceable (and most aren't), it is up to the patent holder to decide if it is in their interest to enforce the patent claims. Since they will normally attempt to collect royalties from those using the encoders to generate encoded content, it is in their interest avoid enforcing claims against users of decoders, as the more such decoders are used, the more the demand for the corresponding encoders, and thus the more royalties they will collect. So it seems to me entirely logical to await notification that they indeed intend to collect royalties for these codec decoders. However I do agree that we should put encoders that seem to be covered by valid patents in some countries in "tainted". This might seem to be not worth the effort, particularly since, to the best of my knowledge, even in software patent impacted countries such as the U.S., no Linux mirror has chosen to not carry all the supposedly patent-affected packages produced by the distro. However by including codec decoders on our isos, we will give users a much more friendly experience, particularly those that can not use online repos during installation. We have to decide whether we would consider a package affected by patents. I'm just trying to suggest that we hold off putting codec decoders in "tainted" until we know that the patent holder intends to enforce the patent (against us or other similar users). Of course we could always be dogmatic about it. It would be interesting producing a release the next time there is a claim against the Linux kernel. The split is a purely technical decision that should (in theory at least) have zero impact on a default install unless we specifically decide to allow it to. One could say that there is a considerable political side of the issue. Is the claim potentially valid ? (We probably already consider that, to some degree.) Does the patent holder intend to enforce it, in our context. (We should consider that.) As far as the impact goes, if we don't separate likely enforced from other patent claims, we won't be able to provide codecs on our DVD's, which will impact those who can not reliably do a network install. I'd rather that Mageia be known as a user-friendly distro. Col My 2 cents :) -- André
Re: [Mageia-dev] Fosdem 2012 - Mageia stand
On 11/01/12 10:15, Colin Guthrie wrote: 'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble: as you might already know from previous mails or from the blog post published yesterday, Mageia is (again) attending Fosdem this year. http://blog.mageia.org/en/2012/01/10/happy-new-mageia-year/ Aside from participating in some discussion sessions and a talk done by misc, we are also having a stand there for showing mageia to the public. For this we do still need some help from you. We should have two people there all the time and as you might imagine, nobody wants to stand there all day. So if you are attending FOSDEM this year and are willing to help us, please enter your name here: https://wiki.mageia.org/en/Fosdem_2012#Mageia_booth Looking forward to meeting many people there, In a stunning break from the norm, I've actually managed to not plan a skiing holiday over the FOSDEM weekend... Misc won't believe me but I WILL be there! Added my name to the list. Col Great :) You don't want to join the dinner saturday night? https://wiki.mageia.org/en/Fosdem_2012#Dinner_Saturday_night
Re: [Mageia-dev] Fosdem 2012 - Mageia stand
> 'Twas brillig, and Oliver Burger at 11/01/12 07:56 did gyre and gimble: [...] >> Looking forward to meeting many people there, > > In a stunning break from the norm, I've actually managed to not plan a > skiing holiday over the FOSDEM weekend... Misc won't believe me but I > WILL be there! > > Added my name to the list. Haha, no way! awesome though... don't forget to register on the wiki page for the saturday dinner
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On 10.01.2012 15:07, Pascal Terjan wrote: > On Tue, Jan 10, 2012 at 03:20, Anssi Hannula wrote: >> The problem is that that "balance" was achieved by sticking packages in >> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4 >> video encoders are in main/core, while e.g. AAC audio decoders are in >> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would >> be much more prominent and tainted candidates instead of AAC decoding... >> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted, >> e.g. we have ffmpeg in core, but xvid in tainted. > > I agree we need rules, but "being covered with patents" does not make > sense, as the patent owner may agree with using it in free software. > I think something like "No actively enforced patent" in core would be good. Possibly, but how do you define that, exactly? Does a licensing program count as "enforcing" or do you mean something else? >>> I suppose you can't blame a >>> US company like RedHat for being overly paranoid, but as you said, Mandriva >>> hasn't had any problems. Are there any there examples out of >>> there of distros trying to achieve this balance? Obviously we don't want >>> to follow Ubuntu or ROSA in pretending patents don't exist. >> >> Linux Mint provides a "No codecs" CD: >> http://www.linuxmint.com/download.php >> >> Ubuntu has a patent policy (which basically IIRC says "rights owner or >> packager, please contact us if you think there is an infringement, we >> will investgate"): >> https://wiki.ubuntu.com/PatentPolicy >> >> Note also that the Ubuntu Live CD and therefore the default Ubuntu >> installation do not contain any codecs. By default Totem is installed, >> however, and gstreamer is plugged into "gnome-codec-install" (which >> seems really nice, do we use it?), so that wen you try to play an >> unsupported video the first time, it will prompt to install the codecs >> (it will also show a warning dialog about patents etc, but AFAICS this >> comes from gnome-codec-install itself, not Ubuntu). > > This looks nice > -- Anssi Hannula
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
Am 11.01.2012 10:54, schrieb Wolfgang Bornath: > 2012/1/11 Marja van Waes : >> On 03/01/12 10:09, Wolfgang Bornath wrote: >>> 2012/1/3 Michael Scherer: Le lundi 02 janvier 2012 à 22:17 +0100, Maarten Vanraes a écrit : > Op maandag 02 januari 2012 21:40:31 schreef Michael Scherer: >> Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : >>> Hi everyone, >>> >>> Can someone please help to fix bug 1956? >>> >>> You don't need to be a regular forum visitor. >>> >>> We need someone to find and implement a probably existing MOD, needed >>> to keep forum posts history when unlimited edit time is enabled >>> >>> From wobo's comment #32: >>> Capabilities needed: >>> Well, one could say that anybody who >>> >>> - knows how to run phpBB as admin and >>> - has seen a line of php >>> - knows how to edit code (respecting tags and such) >>> - knows how to cut&paste >>> >>> should be able to install an existing MOD (if I'm not mistaken there >>> is >>> one or more). >>> >>> I know next to nothing about php coding. But I've been running a phpBB >>> forum for a couple of years and successfully implemented some MODs in >>> phpBB2 and phpBB3. With no help (except the phpBB-forum in case of >>> problems). >>> >>> In practice you have a detailed installation README for each MOD. Like >>> >>> - open file /foo/bar/doo.php >>> - Find the line which starts with '..' >>> - After that add >>> - "." >>> >>> And more such step-by-step guidance >> My eyes start to bleed dues to such "guidances". > i'm sure misc means to say that we should have all our changes in > packages/puppet config so that we can update without issues. and with > file > edits, that's a whole different thing. I was more thinking of proper patchs or better, proper modules, with files to deploy in a well know directory . >>> I only gave a part of an example. MODs are made as enhancement to the >>> standard software. The easiest MOD is like Michael wrote: "a module >>> with files to deploy in a well known directory". But in most cases >>> they consist of files to copy into various directories of the program >>> tree and changes to existing files of the software. There are other >>> MODs which can be implemented automatically - which is far worse IMHO. >>> This is where a modded phpBB3 could turn into a nightmare to maintain >>> - believe me, I've been there :( >>> >>> Of course no developper of a MOD could know what somebody has already >>> done to the standard files, so it's not possible do use only patches. >>> And it could be (and that happens quite often) that a MOD is not >>> compatible to your already "modificated" forum software (destroys >>> other modifications or whatever). >>> >>> IMHO the best way in this case here would be a mod written for our >>> setup, all changes well defined to make it maintainable in a proper >>> way. Saying this I beg to think again whether the issue justifies all >>> the time and work. >>> >> It would make me very, very happy, does that count a little? If I were sure >> that I'd be able to learn how to do it, I would now consider to halve the >> time I use for the Bug Squad and Doc Team and start learning. > Why? IMHO this complete issue is going out of proportions. Let's > remember why we *seem to need* this MOD in the first place. And what > will we find? The time-to-edit discussion, again. In the council > meeting where it was decided to have this mod It looked as the best > way to please a disturbing minority request, the more as that same > minority gave the impression that such a MOD could be implemented > within a reasonable time span. As we see now after 8 months, this was > never the case. > > Adding the fact that a test period of several months with a much > looser time-to-edit setting in the German Mageia forum showed not one > single case of misuse brings me to the conviction that we should > rather rethink the time-to-edit limitation itself than to waste > manpower on this issue. Manpower which is needed at more important > tasks, if I may say. > In general i don't like those +1 posts, but this ^^ one hits the nail on the head. +1
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On Wed, Jan 11, 2012 at 12:56, Anssi Hannula wrote: > On 10.01.2012 15:07, Pascal Terjan wrote: >> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula wrote: >>> The problem is that that "balance" was achieved by sticking packages in >>> PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4 >>> video encoders are in main/core, while e.g. AAC audio decoders are in >>> PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would >>> be much more prominent and tainted candidates instead of AAC decoding... >>> Also, in e.g. MPEG-4 case we have encoders both in core and in tainted, >>> e.g. we have ffmpeg in core, but xvid in tainted. >> >> I agree we need rules, but "being covered with patents" does not make >> sense, as the patent owner may agree with using it in free software. >> I think something like "No actively enforced patent" in core would be good. > > Possibly, but how do you define that, exactly? > > Does a licensing program count as "enforcing" or do you mean something else? Yes, that's what I meant
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Tue, 10 Jan 2012 20:28:15 -0600 Luis Daniel Lucio Quiroz wrote: > > You dont get me, > > I mean, stop asking updates for mageia 1 just because there is another > newversion. Uh. As a Mageia user I would expect Mageia to package significant *bugfix releases* and ship them in the updates for the stable distro. For example, it would be nice if an up-to-date Mageia 1 system had Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, but nice). There's more than a hundred bug fixes between the two versions and I don't expect Mageia to have independently fixed many of these bugs. If you think shipping bugfixes isn't part of the QA for a stable version then I'm not sure what said QA should be (apart from updating Firefox to new major versions that is :-)). Regards Antoine.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Le 11/01/2012 16:09, Antoine Pitrou a écrit : As a Mageia user I would expect Mageia to package significant *bugfix releases* and ship them in the updates for the stable distro. You'd rather read the current update policy, rather than expect blind assertions: https://wiki.mageia.org/en/Updates_policy For example, it would be nice if an up-to-date Mageia 1 system had Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, but nice). There's more than a hundred bug fixes between the two versions and I don't expect Mageia to have independently fixed many of these bugs. A bug may vary from a typo in a man page to a critical security update, which make the number of claimed bugfix a poor decision metric. A non-regression ensurance would be a better one, but it's quite difficult to assert. If you think shipping bugfixes isn't part of the QA for a stable version then I'm not sure what said QA should be (apart from updating Firefox to new major versions that is :-)). Welcome to our new QA team volonteer :) -- BOFH excuse #368: Failure to adjust for daylight savings time.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold wrote: > Well, 2) and 3) are not valid reasons here, because backports should get > a similar amount of QA testing as normal update candidates, and for > the updates policy require a bugreport for validation through QA. I think this is unrealistic in practice. For updates, QA will be testing one bug fix, with a backport you will have dozens or more new features to test, you can't expect for QA to test all of them to be able to give the OK, more if they even don't use the backported app in a daily basis. Testing of a backport has to be more relaxed and compromise to test some basic stuff like that it installs and starts correctly, maybe the package maintainer can give some hints on what else to test, but the rest we will have to trust in the maintainer's judgement. If you think that all version backports should be tested in the same way as updates by QA, then all versions upgrades in cauldron should be tested by QA before pushing them to the BS right ? why risk for a bug on a program when updating to a new mga version and not when doing a backport ?, it's exactly the same situation. -- Juancho
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
On 11/01/12 10:54, Wolfgang Bornath wrote: 2012/1/11 Marja van Waes: On 03/01/12 10:09, Wolfgang Bornath wrote: Le lundi 02 janvier 2012 à 19:41 +0100, Marja van Waes a écrit : Hi everyone, Can someone please help to fix bug 1956? IMHO the best way in this case here would be a mod written for our setup, all changes well defined to make it maintainable in a proper way. Saying this I beg to think again whether the issue justifies all the time and work. It would make me very, very happy, does that count a little? If I were sure that I'd be able to learn how to do it, I would now consider to halve the time I use for the Bug Squad and Doc Team and start learning. Why? IMHO this complete issue is going out of proportions. Let's remember why we *seem to need* this MOD in the first place. And what will we find? The time-to-edit discussion, again. In the council meeting where it was decided to have this mod It looked as the best way to please a disturbing minority request, the more as that same minority gave the impression that such a MOD could be implemented within a reasonable time span. As we see now after 8 months, this was never the case. I can't talk for that minority, of course. However, I can talk for myself: In such circumstances it is very possible that I'd agree to do something to later find out I can't concentrate on the task no matter how hard I try. I regret it wasn't decided that the people who wanted unlimited edit time should make the MOD, after which the unlimited edit time would be implemented. They were going to get what they wanted (the unlimited edit time), wouldn't that have "given them wings" to do that MOD? Regards, Marja
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, 11 Jan 2012 16:51:55 +0100 Guillaume Rousse wrote: > Le 11/01/2012 16:09, Antoine Pitrou a écrit : > > As a Mageia user I would expect Mageia to package significant *bugfix > > releases* and ship them in the updates for the stable distro. > You'd rather read the current update policy, rather than expect blind > assertions: > https://wiki.mageia.org/en/Updates_policy Thanks. > > For example, it would be nice if an up-to-date Mageia 1 system had > > Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, > > but nice). There's more than a hundred bug fixes between the two > > versions and I don't expect Mageia to have independently fixed many of > > these bugs. > A bug may vary from a typo in a man page to a critical security update, > which make the number of claimed bugfix a poor decision metric. A > non-regression ensurance would be a better one, but it's quite difficult > to assert. As both an user and an upstream developer, I would not expect a Mageia packager to know better than the upstream developers what can constitute a regression, and what is a good compromise to fix or not. At least for well-maintained upstream projects, that is :-) > Welcome to our new QA team volonteer :) Agreed that my advice would be more constructive if I got involved, but I don't have the time for that. Regards Antoine.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse wrote: > Le 11/01/2012 16:09, Antoine Pitrou a écrit : > >> As a Mageia user I would expect Mageia to package significant *bugfix >> releases* and ship them in the updates for the stable distro. > > You'd rather read the current update policy, rather than expect blind > assertions: > https://wiki.mageia.org/en/Updates_policy Whoa - this is a rather stupid policy. (my opinion, yours obviously differs). "For the most part, an update should consist of a patched build of the same version of the package released with the distribution," Welcome to distro-isolation, putting burden on maintainers, giving them all the reason to deny a reasonable request for a bugfix release because it just is too much work to hunt for a specific commit that fixed bug x. >> For example, it would be nice if an up-to-date Mageia 1 system had >> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, >> but nice). There's more than a hundred bug fixes between the two >> versions and I don't expect Mageia to have independently fixed many of >> these bugs. > > A bug may vary from a typo in a man page to a critical security update, And a typo-fix is not worthwhile to have? > which make the number of claimed bugfix a poor decision metric. A > non-regression ensurance would be a better one, but it's quite difficult to > assert. Don't assume all upstream projects are a bunch of clueless idiots. For upstream releases that have a clear version/release scheme, with micro releases being compatible bugfixes only, the above mentioned policy is completely nonsense, same for your fear of regressions, etc. Sure, you cannot be save of regressions, but what makes you think you are smarter than upstream? What makes you so sure that not the one commit you add as a patch to your package is the one that causes the regressions? Regressions have the nice habit of being triggered by changes in apparently unrelated code... My 0.02€ only, but I strongly suggest for that update policy to be clarified. When there is no dedicated bugfix release procedure in the upstream package, an update is a rebuild of the same version with a corresponding patch. That's reasonable (as opposed to using a newer minor or even major release, those are backports). But once again: if upstream has a major.minor.micro scheme with micro versions being bugfix releases, I really don't see any sane reason for not "allowing" those updates. ciao Christian
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 16:48, Christian Lohmaier wrote: > On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse > wrote: >> Le 11/01/2012 16:09, Antoine Pitrou a écrit : >> >>> As a Mageia user I would expect Mageia to package significant *bugfix >>> releases* and ship them in the updates for the stable distro. >> >> You'd rather read the current update policy, rather than expect blind >> assertions: >> https://wiki.mageia.org/en/Updates_policy > > Whoa - this is a rather stupid policy. (my opinion, yours obviously differs). > "For the most part, an update should consist of a patched build > of the same version of the package released with the > distribution," > > Welcome to distro-isolation, putting burden on maintainers, giving > them all the reason to deny a reasonable request for a bugfix release > because it just is too much work to hunt for a specific commit that > fixed bug x. > >>> For example, it would be nice if an up-to-date Mageia 1 system had >>> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, >>> but nice). There's more than a hundred bug fixes between the two >>> versions and I don't expect Mageia to have independently fixed many of >>> these bugs. >> >> A bug may vary from a typo in a man page to a critical security update, > > And a typo-fix is not worthwhile to have? > >> which make the number of claimed bugfix a poor decision metric. A >> non-regression ensurance would be a better one, but it's quite difficult to >> assert. > > Don't assume all upstream projects are a bunch of clueless idiots. Don't assume the opposite either, it really depend on each project. > For upstream releases that have a clear version/release scheme, with > micro releases being compatible bugfixes only, the above mentioned > policy is completely nonsense, same for your fear of regressions, etc. Yes, bugfix only release have always been accepted, this should be added to the exceptions on the wiki. > Sure, you cannot be save of regressions, but what makes you think you > are smarter than upstream? What makes you so sure that not the one > commit you add as a patch to your package is the one that causes the > regressions? Because the most changes you had, the most likely a regression is > Regressions have the nice habit of being triggered by changes in > apparently unrelated code... > > My 0.02€ only, but I strongly suggest for that update policy to be clarified. > When there is no dedicated bugfix release procedure in the upstream > package, an update is a rebuild of the same version with a > corresponding patch. That's reasonable (as opposed to using a newer > minor or even major release, those are backports). > But once again: if upstream has a major.minor.micro scheme with micro > versions being bugfix releases, I really don't see any sane reason for > not "allowing" those updates. Yes, they are actually allowed.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier wrote: > Welcome to distro-isolation, putting burden on maintainers, giving > them all the reason to deny a reasonable request for a bugfix release > because it just is too much work to hunt for a specific commit that > fixed bug x. > You don't do packaging, right ? it isn't that hard and is how all distro's do it. Look at Fedora or SuSE's packages and you will see a lot of patch files fixing single bugs. It's a matter of following upstream bugzilla reports and see which commit fixes the issue in question, create a patch from it and apply it to the package. Most of the time you can get the patches to fix single bugs from other distros packages. If there's a bugfix-only release it's better as it will be easier to update, but many times they aren't and include new features which could introduce regressions so we have to cherry pick those fixes. Also many times there isn't a new release from upstream so the only option we have is to backport a single fix. >> A bug may vary from a typo in a man page to a critical security update, > > And a typo-fix is not worthwhile to have? > I think that what was meant here is that there are priorities for QA, where a security update is much more important and deserves more attention than a typo-fix. Of course, you are welcome to join the QA team to help them test those not so critical fixes if you really care that much about them. > > Sure, you cannot be save of regressions, but what makes you think you > are smarter than upstream? What makes you so sure that not the one > commit you add as a patch to your package is the one that causes the > regressions? > Because as I said earlier, we backport the "commit" that fixes that single issue, based on the info found on the bugzilla report of the upstream project. Also as you say most of the times upstream is not a bunch of clueless idiots so they will document very well each commit, making it easier for us to find those fixes. Cheers, -- Juancho
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, 11 Jan 2012 12:43:35 -0500 Juan Luis Baptiste wrote: > > Sure, you cannot be save of regressions, but what makes you think you > > are smarter than upstream? What makes you so sure that not the one > > commit you add as a patch to your package is the one that causes the > > regressions? > > > > Because as I said earlier, we backport the "commit" that fixes that > single issue, based on the info found on the bugzilla report of the > upstream project. But how do you choose which patches you want to backport from the stream of bugfixes done by upstream? Should the packager monitor all bug fixing activity? (sure (s)he *can*, but that's a lot of work) Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker. (also, other users don't bother reporting bugs at all :-)) Regards Antoine.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 1:22 PM, Antoine Pitrou wrote: > On Wed, 11 Jan 2012 12:43:35 -0500 > But how do you choose which patches you want to backport from the > stream of bugfixes done by upstream? Because normally a single commit fixes a single bug and the commit message says it clearly, so it's easy to spot the fixes. > Should the packager monitor all > bug fixing activity? (sure (s)he *can*, but that's a lot of work) > No we don't need to, we just need to look for the fix we are interested in as I described before. > Just because someone doesn't file a bug against Mageia doesn't mean the > bug doesn't bother anybody, because many users don't report upstream > bugs to the distro's tracker. > (also, other users don't bother reporting bugs at all :-)) > Don't think that when we get a bug report in mga bugzilla is because only mga users are affected ;) most of the time there's already an upstream bug report so we start following it and give any useful information we have about it. If it isn't we create it and follow it. -- Juancho
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit : > On Wed, Jan 11, 2012 at 3:43 AM, Florian Hubold wrote: > > Well, 2) and 3) are not valid reasons here, because backports should get > > a similar amount of QA testing as normal update candidates, and for > > the updates policy require a bugreport for validation through QA. > > I think this is unrealistic in practice. For updates, QA will be > testing one bug fix, with a backport you will have dozens or more new > features to test, you can't expect for QA to test all of them to be > able to give the OK, more if they even don't use the backported app in > a daily basis. Testing of a backport has to be more relaxed and > compromise to test some basic stuff like that it installs and starts > correctly, maybe the package maintainer can give some hints on what > else to test, but the rest we will have to trust in the maintainer's > judgement. So trusting and having bugs are totally unrelated. And if you doubt that bugs appear, just see our bugzilla. We trust upstream ( most of them ), and yet there is bugs. > If you think that all version backports should be tested in the same > way as updates by QA, then all versions upgrades in cauldron should be > tested by QA before pushing them to the BS right ? No, they should be tested before being put in the stable release. And that's exactly what we do by freezing and testing before release. > why risk for a bug > on a program when updating to a new mga version and not when doing a > backport ?, it's exactly the same situation. That was already extensively discussed in the past, but if we do the same stuff than in Mandriva, we will end with the same result than in Mandriva. - people don't test backports, because that's not mandatory => some bugs slips. then users start to say "do not use backport if you do not know what you do or if you are not expert, because I had $problem once". With time, such advice start to impermeate the community, and people start to simply not use backports. Worst, some people just do cherry picking of backports, and take one or two or them, and this result in wierd bugs with 2 effects : - we lose time - user think we are doing a bad quality distribution, because he has a mix that he is the only one in the world to have. Non technical users tell him he should not mix ( and they are right ), and so he start to feel bad because we gave him something that do not ork. Some users also end with system unsupported, so no security update, nor bugfixes. In the end, users complain that distribution is broken, and that impact our image. We cannot tell "do not mix", because we cannot tell them to update backports without fear, as that would be lying. And in the end, saying "this is not supported, but we offer to you" is just sending a confusing message. If we start to give low quality stuff as Mageia, people will just think Mageia is low quality. -- Michael Scherer
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, 11 Jan 2012 13:33:41 -0500 Juan Luis Baptiste wrote: > On Wed, Jan 11, 2012 at 1:22 PM, Antoine Pitrou wrote: > > On Wed, 11 Jan 2012 12:43:35 -0500 > > But how do you choose which patches you want to backport from the > > stream of bugfixes done by upstream? > > Because normally a single commit fixes a single bug and the commit > message says it clearly, so it's easy to spot the fixes. > > > Should the packager monitor all > > bug fixing activity? (sure (s)he *can*, but that's a lot of work) > > > > No we don't need to, we just need to look for the fix we are > interested in as I described before. Uh, you have a hard time understanding a question don't you? I specifically asked *how* you come to be interested in a particular fix, rather than all of them. So, again, do you monitor all commits or is there another heuristic you apply to avoid that O(n) process? Regards Antoine.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit : > On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse > wrote: > > Le 11/01/2012 16:09, Antoine Pitrou a écrit : > > > >> As a Mageia user I would expect Mageia to package significant *bugfix > >> releases* and ship them in the updates for the stable distro. > > > > You'd rather read the current update policy, rather than expect blind > > assertions: > > https://wiki.mageia.org/en/Updates_policy > > Whoa - this is a rather stupid policy. (my opinion, yours obviously differs). > "For the most part, an update should consist of a patched build > of the same version of the package released with the > distribution," I am pretty sure that you can express yourself without starting by insulting people. That would surely help to be listened ( cause right now, I must tell that I am not very keen on that ) > Welcome to distro-isolation, putting burden on maintainers, giving > them all the reason to deny a reasonable request for a bugfix release > because it just is too much work to hunt for a specific commit that > fixed bug x. If that's too much work for a maintainer and if that's important for you, you can : - do your own package, supported by yourself for yourself or : - provide the patch If that's too much work for you too, then that's likely too much work for others too. > >> For example, it would be nice if an up-to-date Mageia 1 system had > >> Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, > >> but nice). There's more than a hundred bug fixes between the two > >> versions and I don't expect Mageia to have independently fixed many of > >> these bugs. > > > > A bug may vary from a typo in a man page to a critical security update, > > And a typo-fix is not worthwhile to have? When we take in account the fact it would still need proper QA, there is likely stuff that are more important than a typo. And a typo is just a extreme case, and a simplificaition. If we start to have a complex update policy, we are just losing time for almost nothing. > > which make the number of claimed bugfix a poor decision metric. A > > non-regression ensurance would be a better one, but it's quite difficult to > > assert. > > Don't assume all upstream projects are a bunch of clueless idiots. We didn't say that. We just assume that errors happen to everybody. > For upstream releases that have a clear version/release scheme, with > micro releases being compatible bugfixes only, the above mentioned > policy is completely nonsense, same for your fear of regressions, etc. Regressions do happens. > Sure, you cannot be save of regressions, but what makes you think you > are smarter than upstream? What makes you so sure that not the one > commit you add as a patch to your package is the one that causes the > regressions? For 1, we usually do not do distro patch. I personnaly think this should be avoided as much as possible, and that we should push as much patch upstream. We have a rather huge backlog to clean. For 2, we also usually take patch from upstream. Some of us are also good enough to understand patchs, and to see what they mean, if they fix something, etc. Of course, there is some software that are rather specialized or obscure, but that's far from being the majority. > Regressions have the nice habit of being triggered by changes in > apparently unrelated code... And that's why we should reduce the number of changes. > My 0.02€ only, but I strongly suggest for that update policy to be clarified. > When there is no dedicated bugfix release procedure in the upstream > package, an update is a rebuild of the same version with a > corresponding patch. That's reasonable (as opposed to using a newer > minor or even major release, those are backports). > But once again: if upstream has a major.minor.micro scheme with micro > versions being bugfix releases, I really don't see any sane reason for > not "allowing" those updates. Maybe if you started to be less insulting, and instead started to look at the discussion on the ml in the past on the list, when the policy was discussed ( and access to the old wiki too ), you would likely find the reasons saner. -- Michael Scherer
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wednesday 11 January 2012 19:33, Juan Luis Baptiste wrote: > > Should the packager monitor all > > bug fixing activity? > > No we don't need to, we just need to look for the fix we are > interested in as I described before. And how do one do that without monitoring most bugfixing activity or reviewing them, hunting for a particular fix? To some people, that magic trick is not obvious. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 2:19 PM, Antoine Pitrou wrote: > On Wed, 11 Jan 2012 13:33:41 -0500 >> > >> >> No we don't need to, we just need to look for the fix we are >> interested in as I described before. > > Uh, you have a hard time understanding a question don't you? > And you a hard time understanding an answer, don't you ? pfff... > I specifically asked *how* you come to be interested in a particular > fix, rather than all of them. > As I said, when there's a bug report on mga, we start investigating the problem and go and look at upstream for a bug report there for *that* particular bug. Then, when we see it fixed we go to the control versioning system ang create a patch from the commit that fixed *that* bug according to the upstream report and apply it to the mga package, what isn't clear about that ? > So, again, do you monitor all commits or is there another heuristic you > apply to avoid that O(n) process? > Again, read with attention what I said before and on this answer. -- Juancho
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 2:38 PM, Johnny A. Solbu wrote: > On Wednesday 11 January 2012 19:33, Juan Luis Baptiste wrote: > And how do one do that without monitoring most bugfixing activity or > reviewing them, hunting for a particular fix? > > To some people, that magic trick is not obvious. > As I said before, the upstream bug report will tell you which commit fixed the bug, so you go ahead and get that particular revision and create a patch to apply to the packages, there's no need to monitor *all* bugfixing activity, you just look for what you need when you need to. -- Juancho
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Le mercredi 11 janvier 2012 à 16:09 +0100, Antoine Pitrou a écrit : > On Tue, 10 Jan 2012 20:28:15 -0600 > Luis Daniel Lucio Quiroz > wrote: > > > > You dont get me, > > > > I mean, stop asking updates for mageia 1 just because there is another > > newversion. > > Uh. > As a Mageia user I would expect Mageia to package significant *bugfix > releases* and ship them in the updates for the stable distro. > > For example, it would be nice if an up-to-date Mageia 1 system had > Python 2.7.2 rather than Python 2.7.1 (not a deal-breaker, of course, > but nice). There's more than a hundred bug fixes between the two > versions and I don't expect Mageia to have independently fixed many of > these bugs. > > If you think shipping bugfixes isn't part of the QA for a stable version > then I'm not sure what said QA should be (apart from updating Firefox > to new major versions that is :-)). The policy ( as I remember when we discussed on this ml ) would allow to ship it, the specific case that I had in mind was postgresql, because it has a strict policy on backporting fixes, and regression testing, but python would fit too. However, my current workload and priority list do not place "doing a python update" on the top of the list. As you say, that's not a deal breaker, so I prefer to focus on what would be more important or urgent ( like for example, fixing servers and broken raid array ). -- Michael Scherer
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
Le mercredi 11 janvier 2012 19:22:23, Antoine Pitrou a écrit : > Just because someone doesn't file a bug against Mageia doesn't mean the > bug doesn't bother anybody, because many users don't report upstream > bugs to the distro's tracker. > (also, other users don't bother reporting bugs at all :-)) > That's it. This is why we provide the whole bugfix release from upstream as update when it is a PURE BUGFIX release (no new features). Backports are here for releases with new features.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, 11 Jan 2012 14:41:54 -0500 Juan Luis Baptiste wrote: > > As I said, when there's a bug report on mga, we start investigating > the problem and go and look at upstream for a bug report there for > *that* particular bug. So let me repeat myself from two messages above (!): “Just because someone doesn't file a bug against Mageia doesn't mean the bug doesn't bother anybody, because many users don't report upstream bugs to the distro's tracker.” Regards Antoine.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 2:10 PM, Michael Scherer wrote: > Le mercredi 11 janvier 2012 à 11:24 -0500, Juan Luis Baptiste a écrit : > > So trusting and having bugs are totally unrelated. And if you doubt that > bugs appear, just see our bugzilla. > We trust upstream ( most of them ), and yet there is bugs. No, they're not totally unrelated when we don't have the man power to do through QA on every package, we need to trust on the packager (and upstream of course) that he did his best to test the new version without expecting him to have tested all the new features, Or do you expect that a QA member get a list of all the new features of a backport and start testing them one by one ? that's what I call unrealistic in practice. > >> If you think that all version backports should be tested in the same >> way as updates by QA, then all versions upgrades in cauldron should be >> tested by QA before pushing them to the BS right ? > > No, they should be tested before being put in the stable release. And > that's exactly what we do by freezing and testing before release. > Of course but again, we can't test *all* the new features of *all* the programs that are going to a new release, we do our best for most of them. Critical components like installer, kernel, drak* tools, etc need more testing and that's where (our very small team) QA should spend their time after a freeze. The rest we have to do our best to test after each version update of a package. >> why risk for a bug >> on a program when updating to a new mga version and not when doing a >> backport ?, it's exactly the same situation. > > That was already extensively discussed in the past, but if we do the > same stuff than in Mandriva, we will end with the same result than in > Mandriva. > - people don't test backports, because that's not mandatory > => some bugs slips. > Of course and that will also happen when updating packages during the development cycle of cauldron. Yes, we do freeze to be able to test, but we cant test every new feature of all applications. We test the most critical stuff which we can't risk to have bugs (and they also slip some times). > > In the end, users complain that distribution is broken, and that impact > our image. We cannot tell "do not mix", because we cannot tell them to > update backports without fear, as that would be lying. And in the end, > saying "this is not supported, but we offer to you" is just sending a > confusing message. > > If we start to give low quality stuff as Mageia, people will just think > Mageia is low quality. > Users will complain anyway, they will complain because there aren't backports of their favorite application or because a backported version has a bug, so we need to find a balance between those two. Expecting to do the same amount of testing to a backport will put too much burden on QA and will make the process of backporting a version too slow for the users. So we need to have more lax tests for backports, enough to guarantee that the application works for it's main features and doesn't put too much burnden on QA, than for updates which need to gurantee that a bug is really fixed. How to define which should be those tests ? that's the issue as I see it. We could have a "backports team" thought, that would do QA for backports without taking time from the updates QA team... Also the other problem is the third-party repos which brings lots of problems because packages are of low quality and don't follow our standards, and if we don't have our own backports and move fast enough users will continue to use those third-party repos, which will also bring the "Mageia is of low quality" problem. -- Juancho
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 3:05 PM, Antoine Pitrou wrote: > > “Just because someone doesn't file a bug against Mageia doesn't mean the > bug doesn't bother anybody, because many users don't report upstream > bugs to the distro's tracker.” > Simple, we won't fix bugs that aren't reported or noticed by us, that's unrealistic, someone needs to bring the attention to us if they want it to be fixed. -- Juancho
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
On Wed, 11 Jan 2012, Marja van Waes wrote: > > I can't talk for that minority, of course. However, I can talk for myself: > > In such circumstances it is very possible that I'd agree to do something to > later find out I can't concentrate on the task no matter how hard I try. > > I regret it wasn't decided that the people who wanted unlimited edit time > should make the MOD, after which the unlimited edit time would be > implemented. They were going to get what they wanted (the unlimited edit > time), wouldn't that have "given them wings" to do that MOD? I think unlimited edit time should be enabled, but there is no need for a MOD. Creating a MOD to keep history of post edits is not really trivial, and could be difficult to maintain in the future. If we really want this feature, it would probably be better to have it implemented in upstream phpbb before we use it. But the main problem is not edit time, I don't really care about edit time myself. The main problem is that there seems to be a majority of people who think it should be enabled, that there is no good reason to not do it, or at least try it for a few months (as was proposed several times by different people), but it is still not done, because someone decided it shouldn't be done. It could have been enabled in 2 minutes 8 months ago and we would have avoided those endless debates.
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, 11 Jan 2012 15:13:05 -0500 Juan Luis Baptiste wrote: > On Wed, Jan 11, 2012 at 3:05 PM, Antoine Pitrou wrote: > > > > “Just because someone doesn't file a bug against Mageia doesn't mean the > > bug doesn't bother anybody, because many users don't report upstream > > bugs to the distro's tracker.” > > > > Simple, we won't fix bugs that aren't reported or noticed by us, > that's unrealistic, someone needs to bring the attention to us if they > want it to be fixed. And my point is that these bugs are fixed automatically if you follow bugfix releases from upstream... Apparently you like to create work for yourself, though :) Regards Antoine.
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
Op woensdag 11 januari 2012 21:13:50 schreef nicolas vigier: [...] > But the main problem is not edit time, I don't really care about edit > time myself. The main problem is that there seems to be a majority of > people who think it should be enabled, that there is no good reason to > not do it, or at least try it for a few months (as was proposed several > times by different people), but it is still not done, because someone > decided it shouldn't be done. It could have been enabled in 2 minutes > 8 months ago and we would have avoided those endless debates. in retrospect, i agree with you on this
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 6:43 PM, Juan Luis Baptiste wrote: > On Wed, Jan 11, 2012 at 11:48 AM, Christian Lohmaier > wrote: > [...] > You don't do packaging, right ? Wrong. I do packaging, although not for any distro. > it isn't that hard and is how all distro's do it. Look at Fedora or > SuSE's packages and you will see a lot of patch files fixing single > bugs. adding patches to the packages and releasing them instead of waiting for a new upstream release is different from having the policy to stick with whatever release was used when releasing the distro and then only apply fixes via patches. I'm not saying that you must not use patches to fix bugs. There are cases where a bug is homegrown/specific to the distro and thus not suitable for fixing upstream, there are cases where development cylce is too slow/it is not sensible to wait for upstream. > It's a matter of following upstream bugzilla reports and see > which commit fixes the issue in question, create a patch from it and > apply it to the package. Most of the time you can get the patches to > fix single bugs from other distros packages. It is not a question whether it is possible. It is a question whether it makes sense in the first place. And no doubt it creates a lot more work for package maintainers. Both for initially hunting for the commit that fixes the bug, and later when patches conflict, and later when a package is updated to a new release. > Because as I said earlier, we backport the "commit" that fixes that > single issue, Every change, also those that introduce a regression is a "commit". So implicitly you're saying that you will only fix the "easy" bugs, but anything that involves more than touching 10lines of code will not be chosen, since it might introduce regressions. ciao Christian
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 8:56 PM, zezinho wrote: > Le mercredi 11 janvier 2012 19:22:23, Antoine Pitrou a écrit : >> Just because someone doesn't file a bug against Mageia doesn't mean the >> bug doesn't bother anybody, because many users don't report upstream >> bugs to the distro's tracker. >> (also, other users don't bother reporting bugs at all :-)) > > That's it. This is why we provide the whole bugfix release from upstream as > update when it is a PURE BUGFIX release (no new features). This would be sane, but this is not what is written in the update policy wiki page. ciao Christian
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 8:32 PM, Michael Scherer wrote: > Le mercredi 11 janvier 2012 à 17:48 +0100, Christian Lohmaier a écrit : >> On Wed, Jan 11, 2012 at 4:51 PM, Guillaume Rousse >> wrote: >> > Le 11/01/2012 16:09, Antoine Pitrou a écrit : >> > >> >> As a Mageia user I would expect Mageia to package significant *bugfix >> >> releases* and ship them in the updates for the stable distro. >> > >> > You'd rather read the current update policy, rather than expect blind >> > assertions: >> > https://wiki.mageia.org/en/Updates_policy >> >> Whoa - this is a rather stupid policy. (my opinion, yours obviously differs). >> "For the most part, an update should consist of a patched build >> of the same version of the package released with the >> distribution," > > I am pretty sure that you can express yourself without starting by > insulting people. Well, if you feel insulted when I state my personal opinion about the policy, then I cannot help it. I also find a different word for it - In my opinion it is a stupid policy. It might not reflect what was discussed on the mailinglist, but that is not my fault either - I can only judge what is written on that wiki-page, and once again: that policy doesn't make any sense to me. Feeling insulted means that you apparently were deeply involved in formulating the policy, too bad, but cannot be helped. Sorry if your feelings are hurt. >> Welcome to distro-isolation, putting burden on maintainers, giving >> them all the reason to deny a reasonable request for a bugfix release >> because it just is too much work to hunt for a specific commit that >> fixed bug x. > > If that's too much work for a maintainer and if that's important for > you, you can : > - do your own package, supported by yourself for yourself I do for the packages I care of. > or : > - provide the patch No, that's pointless. I'd rather supply the patch upstream, so it will be integrated in the upstream package. > If that's too much work for you too, then that's likely too much work > for others too. You're mixing stuff around: We/I am talking about the case when there *is* an bugfix release available from upstream, but the policy dictates to extract individual patches for a subset of the fixes only- and that subset being bugs filed in mageia's bugzilla. This doesn't make sense. If the maintainer could use the fixed upstream release, then all that is needed is to bumb the version-tag in the spec and rebuild. You don't question that this is easier than hunting down a patch and adding that to the package, do you? Any cases where just bumping the version and rebuilding won't work are cases that don't fall in the bugfix-only category. >> > [...] >> > A bug may vary from a typo in a man page to a critical security update, >> >> And a typo-fix is not worthwhile to have? > > When we take in account the fact it would still need proper QA, there is > likely stuff that are more important than a typo. And a typo is just a > extreme case, and a simplificaition. If we start to have a complex > update policy, we are just losing time for almost nothing. No doubt about that - the above statement was more meant in the terms of only applying selective fixes by patch, as opposed to taking the release that has those bugs fixed+additional easy stuff. So why only fix "bug that is reported in mageia's bugzilla", but not "the typo that was fixed upstream". >> Sure, you cannot be save of regressions, but what makes you think you >> are smarter than upstream? What makes you so sure that not the one >> commit you add as a patch to your package is the one that causes the >> regressions? > > For 1, we usually do not do distro patch. I personnaly think this should > be avoided as much as possible, and that we should push as much patch > upstream. We have a rather huge backlog to clean. > > For 2, we also usually take patch from upstream. Some of us are also > good enough to understand patchs, and to see what they mean, if they fix > something, etc. Of course, there is some software that are rather > specialized or obscure, but that's far from being the majority. So then again: what makes selectively fixing bugs better in terms of regression prevention than applying a bugfix release from upstream? You an Juan Luis basically say: Less changes, less chance for breakage. This is a "Milchmädchenrechnung" (naive assessment of the situation). Fixed done by upstream are applied by people familiar with the code in question, usually way more familiar than the package maintainer. Yes the regressions do happen. Even if a fix looks simple, it can introduce a regression. And by only selectively applying patches it means that: You might have a "lesser chance" of regressions, but instead of the regressions you still have the other "regular bugs" that were fixed. >> Regressions have the nice habit of being triggered by changes in >> apparently unrelated code... > > And that's why we should reduce the number of changes. That's why reducing th
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 3:44 PM, Antoine Pitrou wrote: > And my point is that these bugs are fixed automatically if you follow > bugfix releases from upstream... > > Apparently you like to create work for yourself, though :) > No, it seems that you like to read what you like to read, On this thread has been clear that if there's a bugfix *only* release then we will update to that version, *but* when it isn't then we *can't* update to it, and we'll have to cherry pick fixes as I have described, according to the reported bugs. That's how we and any distro does it. -- Juancho
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
2012/1/11 Maarten Vanraes : > Op woensdag 11 januari 2012 21:13:50 schreef nicolas vigier: > [...] >> But the main problem is not edit time, I don't really care about edit >> time myself. The main problem is that there seems to be a majority of >> people who think it should be enabled, that there is no good reason to >> not do it, or at least try it for a few months (as was proposed several >> times by different people), but it is still not done, because someone >> decided it shouldn't be done. It could have been enabled in 2 minutes >> 8 months ago and we would have avoided those endless debates. > > in retrospect, i agree with you on this That's why I wrote what I wrote. :) A great majority wants no limitation of time-to-edit so it should be set instead of telling that majority something like "If you want it, develop that MOD, then you can have what you want." - at least everything I know about democratic decisions tells me that. I think I have made my point of view clear, 'nuff said. -- wobo
Re: [Mageia-dev] please stop doing "bugs" for updating magia 1
On Wed, Jan 11, 2012 at 3:53 PM, Christian Lohmaier wrote: > adding patches to the packages and releasing them instead of waiting > for a new upstream release is different from having the policy to > stick with whatever release was used when releasing the distro and > then only apply fixes via patches. > Some times you can't wait for an upstream release, think for example of a security update. Also not all projects do bugfix only releases, but include new features as well so per our policy, we can't update to that version and that's when we have to cherry pick updates to apply to package in the stable version of mga. The problem seems to be that that isn't clear on the policy. > I'm not saying that you must not use patches to fix bugs. There are > cases where a bug is homegrown/specific to the distro and thus not > suitable for fixing upstream, there are cases where development cylce > is too slow/it is not sensible to wait for upstream. > Exactly, plus the other case I just said. > It is not a question whether it is possible. It is a question whether > it makes sense in the first place. > And no doubt it creates a lot more work for package maintainers. > Both for initially hunting for the commit that fixes the bug, and > later when patches conflict, and later when a package is updated to a > new release. As I said, no one is talking about picking up a fix if there's a bug fix only release, it's for when it isn't and we need to reduce the chance of regressions by taking the modifications that *exactly* fix that bug. > >> Because as I said earlier, we backport the "commit" that fixes that >> single issue, > > Every change, also those that introduce a regression is a "commit". > So implicitly you're saying that you will only fix the "easy" bugs, > but anything that involves more than touching 10lines of code will not > be chosen, since it might introduce regressions. > No, I'm saying that we will look for the commit that fixes the issue in question and not anything else, it doesn't matter if the fix is one, 10, 50 lines and/or touches 1, 2 or 10 files. And again, if there's a bugfix *only* release available when we are working on a bug, or we know that there will be one soon, then we can update to that version. In the other cases we have to go the long route and patch the packges with individual fixes. -- Juancho
Re: [Mageia-dev] PHP + phpBB mod capabilities needed to fix bug 1956 - please help
On Wed, Jan 11, 2012 at 21:13, nicolas vigier wrote: > The main problem is that there seems to be a majority of > people who think it should be enabled, that there is no good reason to > not do it, or at least try it for a few months (as was proposed several > times by different people), but it is still not done, because someone > decided it shouldn't be done. It could have been enabled in 2 minutes > 8 months ago and we would have avoided those endless debates. So it goes back to a Council discussion/decision, where the above was decided. Next Monday meeting.
Re: [Mageia-dev] imported .src.rpm / .spec attribution
Le samedi 07 janvier 2012 14:53:59, vous avez écrit : > Le samedi 07 janvier 2012 13:58:05, Luc Menut a écrit : > > Le 07/01/2012 13:23, Florent Monnier a écrit : > > > Hi, > > > > > > In Mandriva I was using this command to make proper attribution of > > > imported .spec files: > > > > > > $ mdvsys import foo.src.rpm --message 'this spec file is imported from > > > Fedora where it was written by X' > > > > > > I'm trying to make the equivalent with this command: > > > > > > $ mgarepo putsrpm -m "this spec file is imported from Mandriva where it > > > was written by X" package.src.rpm > > > error: no such option: -m > > > > > > $ mgarepo putsrpm --message "this spec file is imported from Mandriva > > > where it was written by X" package.src.rpm > > > error: no such option: --message > > > > > > $ mgarepo putsrpm --help | grep -- -m > > > > > > -m LOG Log message used when commiting changes > > > > > > What is the right command line to achieve this? > > > > Can you try mgarepo putsrpm -l LOG ... ? > > Yes it does work, thanks Also I would like to know how to get the name of a mandriva packager from its mandriva nickname? (in order to make the proper attribution of the imported .spec file.) I have also noticed that several Mageia packagers don't do any proper attribution to the original authors of the spec files when importing. Is it considered optional ? because when I was a Mandriva packager, when I was importing Fedora spec files and debian patches I have been asked by them to make this proper attribution when importing. Why is it considered optional when it comes from Mandriva ? -- Cheers
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On 11.01.2012 16:01, Pascal Terjan wrote: > On Wed, Jan 11, 2012 at 12:56, Anssi Hannula wrote: >> On 10.01.2012 15:07, Pascal Terjan wrote: >>> On Tue, Jan 10, 2012 at 03:20, Anssi Hannula wrote: The problem is that that "balance" was achieved by sticking packages in PLF/main/contrib semi-randomly. For example, H.264 decoders and MPEG-4 video encoders are in main/core, while e.g. AAC audio decoders are in PLF/tainted. If one'd put them into an order, IMO H.264 and MPEG-4 would be much more prominent and tainted candidates instead of AAC decoding... Also, in e.g. MPEG-4 case we have encoders both in core and in tainted, e.g. we have ffmpeg in core, but xvid in tainted. >>> >>> I agree we need rules, but "being covered with patents" does not make >>> sense, as the patent owner may agree with using it in free software. >>> I think something like "No actively enforced patent" in core would be good. >> >> Possibly, but how do you define that, exactly? >> >> Does a licensing program count as "enforcing" or do you mean something else? > > Yes, that's what I meant So it doesn't change anything regarding my original post, since all the codecs I talked about have licensing programs. -- Anssi Hannula
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
andre999 wrote: > We're talking about codecs, essentially the decoders which are used to > read encoded files. > If the patent claims are valid/enforceable (and most aren't), it is up > to the patent holder to decide if it is in their interest to enforce the > patent claims. > Since they will normally attempt to collect royalties from those using > the encoders to generate encoded content, it is in their interest avoid > enforcing claims against users of decoders, as the more such decoders > are used, the more the demand for the corresponding encoders, and thus > the more royalties they will collect. So it seems to me entirely > logical to await notification that they indeed intend to collect > royalties for these codec decoders. > However I do agree that we should put encoders that seem to be covered > by valid patents in some countries in "tainted". If we really want a hard and fast rule, I agree that this makes the most sense.
Re: [Mageia-dev] [RFC] Moving various packages/codecs to tainted
On Wed, Jan 11, 2012 at 09:23:20PM -0500, David Walser wrote: > andre999 wrote: > > However I do agree that we should put encoders that seem to be covered > > by valid patents in some countries in "tainted". > > If we really want a hard and fast rule, I agree that this makes the most > sense. If you look hard enough, just about any significant software is probably violating a software patent in some country in the world (see http://www.nosoftwarepatents.com/en/m/dangers/linux.html). Any criteria used to determine "tainted" or not has to be more concrete than "seems" to be covered by valid patents. Under that criteria, the Linux kernel would have to go into tainted since it violates patents by Microsoft, Bedrock Computer Technologies, McDonnell Douglas, etc. >>> Dan
