|
»
Re: SQL::Statement unusable in major Linux distributions
|
View:
New views
7 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: SQL::Statement unusable in major Linux distributions
by Paul Beardsell
::
Rate this Message:
Jonathan,
You are looking at this from a most Debian-centric POV. There are 100 distros. OK, there are only 20 popular ones, only 5 notable ones and only 1 great one :-) but perhaps if I phrased it thus: "The discoverer of a NON-DISTRO SPECIFIC bug cannot be responsible for contacting EACH distro." If I'm working on a Perl app on some other non-Debian distro and the bug I discover is pretty obviously not distro-specific then are you suggesting I report it to Debian? If so are you suggesting I report it also to Suse, RH, Ubuntu etc? No. The place to report it is to that distro's bug tracking system (if they have one) and rt.cpan.org. If I don't report it to CPAN how will Debian ever get to know of the bug? If I find a bug in a four year old version of a package but that is the current version that is distributed in every Linux distro then there needs to be a central place for the bug report. Where is that? It is rt.cpan.org. And I believe RT admin agrees (on this narrow point, at least). That's the position we are in with SQL::Statement This bug I have reported to Ubuntu via Launchpad. At the moment I have not reported it formally to Debian as I temporarily only have Woody because that's the last Debian with a working libsql-statement-perl i.e. SQL::Statement 0.1020. I have verified it on Etch and Lenny but that machine is dead so I cannot report version numbers etc exactly. I have reported it to CPAN for the benefit of everyone. And so the package maintainer can consider if it applies to the latest version of the package. It does and therefore, as it is such a critical bug, the package should perhaps not be accepted by Debian. But it has been! A few days before my bug report. And had I not been so tenacious the bug report would have remained "rejected" or "deleted", not "open", and you would not know of it. Ever. After a while you would stop including libsql-statement-perl in Debian because NOBODY uses it BECAUSE IT IS UNUSABLE by anyone who wants a simple SQL UPDATE statement to work. There is a lot of excellent code available from CPAN from a lot of most dedicated developers/maintainers and testers and documenters and, dare I say, bug reporters! Thanks to any of you who read this. However, it is *not* ALL of excellent quality, and being shy of saying so can be part of the problem. That doesn't mean to say that some packages are more challenging than others to maintain. Some maintainers have bravely taken on packages which are in a mess and which need lots of work. Some maintainers have an easy life! Others slog their guts out for no thanks. And in their spare time. But the quality of the packages and their maintenance does vary, package to package. Paul Beardsell 2009/11/4 Jonathan Yu <jonathan.i.yu@gmail.com> Hi Paul: |
|
|
Re: SQL::Statement unusable in major Linux distributions
by Jonathan Yu
::
Rate this Message:
Paul:
I think you misunderstood my point, and it was probably my mistake in articulating myself. Here is the essential dichotomy as I understand it: 1. If you install a package from a distro which contains a Perl module, then the distro is responsible for maintaining it. If you install a Debian package which is broken, it's Debian's fault. If you install a Ubuntu package which is broken, it's Ubuntu's fault (possibly Debian's fault indirectly, too, of course). 2. If you install a package from CPAN, then the maintainer is responsible for it. That makes sense. So if you have issues with the current version of a module from CPAN, then feel free to bug the maintainer. If you have issues with an older version you get from CPAN, then it's up to the upstream people whether or not they consider your issue a bug, and whether they want to fix it. However, there are many options/workarounds in case you are experiencing a non-distro-specific bug due to an older version of a module available in YOUR distro. 1. Install into /usr/local (in Debian and Ubuntu this is done by default via the CPAN shell). Modules placed there should be given priority over ones installed via your distro (in Debian /usr/local is higher in @INC than /usr/share and /usr/lib, where most other stuff is installed) 2. Install into your homedirectory or something else. local::lib (available on CPAN) is tremendously useful for this purpose, I hear. Actually, it's also available as a Debian package - liblocal-lib-perl. Next, I think it's up to the upstream people as to their maintenance policy. If they have decided, "the newest is the only one we will care about" -- then that's what you get. This is open source; H.Merijn Brand, Jens Rehsack and *many* many (countless!) others contribute their FREE TIME (okay, maybe their $work is just nice) to provide you a product which is FREE (both free as in beer and free as in freedom). Because this is open source, however, you are *always* free to fork a module and continue maintaining it as you choose. Either that, or you can try convincing upstream -- but based on the length of this discussion, it doesn't seem like you've been able to do that thus far. On Tue, Nov 3, 2009 at 9:34 PM, Paul Beardsell <paul@...> wrote: [snip] > If I find a bug in a four year old version of a package but that is the > current version that is distributed in every Linux distro then there needs > to be a central place for the bug report. Where is that? It is > rt.cpan.org. And I believe RT admin agrees (on this narrow point, at > least). That's the position we are in with SQL::Statement Fair enough. You have every right to file a bug and tag it with an older version; however, you're at the mercy of upstream if they decide to consider it a "I won't fix this" bug and reject it. However, you can also submit patches so that others who stumble on your bug report and are in the same position as you can fix theirs, and benefit from your work. > > This bug I have reported to Ubuntu via Launchpad. At the moment I have not > reported it formally to Debian as I temporarily only have Woody because > that's the last Debian with a working libsql-statement-perl i.e. > SQL::Statement 0.1020. I have verified it on Etch and Lenny but that You can always determine what version of a package we have by using the "madison" tool via dak ls: http://qa.debian.org/madison.php -- type any package name on this page, and it will show you the versions available in different releases of Debian. Here is the output for libsql-statement-perl: libsql-statement-perl | 1.15-2 | etch-m68k | source, all libsql-statement-perl | 1.15-2 | oldstable | source, all libsql-statement-perl | 1.15-3 | stable | source, all libsql-statement-perl | 1.22-1 | testing | source, all libsql-statement-perl | 1.22-1 | unstable | source, all http://qa.debian.org/madison.php?package=libsql-statement-perl&a=&b=&c=&s= > machine is dead so I cannot report version numbers etc exactly. I have > reported it to CPAN for the benefit of everyone. And so the package > maintainer can consider if it applies to the latest version of the package. > It does and therefore, as it is such a critical bug, the package should > perhaps not be accepted by Debian. But it has been! A few days before my > bug report. And had I not been so tenacious the bug report would have > remained "rejected" or "deleted", not "open", and you would not know of it. > Ever. After a while you would stop including libsql-statement-perl in > Debian because NOBODY uses it BECAUSE IT IS UNUSABLE by anyone who wants a > simple SQL UPDATE statement to work. I really don't know what to say here. You can always fork it (and Debian users are always able to install an older version from the archive, and pin it there using apt-pinning. Maybe not ideal, but that's a possible "solution", at least until you can get this issue fixed upstream) > > There is a lot of excellent code available from CPAN from a lot of most > dedicated developers/maintainers and testers and documenters and, dare I > say, bug reporters! Thanks to any of you who read this. However, it is > *not* ALL of excellent quality, and being shy of saying so can be part of > the problem. That doesn't mean to say that some packages are more The CPAN Ratings system, CPAN Testers, CPAN Testing Service (aka Kwalitee), FAIL100, and more are QA initiatives to help fix this. Many people have been working really hard on this particular problem, but everything needs to be in line with CPAN/Perl philosophy; there is more than one way to do it. Just because it doesn't work for you, doesn't mean it doesn't work for other people. I think it's best to keep that in mind. Given the current state of things, I think the onus is on users to consider these easily available bits of information via the various QA pages to determine whether or not the module is worth installing. Different people have different criteria to determine what they consider a "good" vs "crappy" package. CPAN Testers and the Kwalitee metrics provided via CPANTS are intended to help users make informed decisions. More work is forthcoming (particularly CPANHQ) to help make this information more easily available for people. PLEASE do not minimize the work of the aformentioned QA-related projects and THEIR various contributors to nothing. Change is happening, the problem is known, but HELP IS NEEDED. If you think Perl/CPAN QA could be improved, then either "crap or get off the pot" -- these are open projects, and I suggest you look into perhaps contributing to CPANHQ. You could be the next person to help shape the future direction of CPAN, and to help users make informed decisions when looking at modules they want to use for their next projects. I really suggest you channel your attitude in a more productive way. And again, if you can't convince upstream SQL::Statement maintainers that there is a problem, then the only recourse you can really have is to "fork off" (ie, fork your own module). Hopefully this helps you. I don't want to come off as someone flaming your response; on the contrary, I would really like to see your efforts here bear some fruit, even if not directly in SQL::Statement but in other QA-related projects like CPANHQ, CPANTS, etc. Cheers! Jonathan > challenging than others to maintain. Some maintainers have bravely taken on > packages which are in a mess and which need lots of work. Some maintainers > have an easy life! Others slog their guts out for no thanks. And in their > spare time. But the quality of the packages and their maintenance does > vary, package to package. > > Paul Beardsell > > > 2009/11/4 Jonathan Yu <jonathan.i.yu@...> >> >> Hi Paul: >> >> From the perspective of Debian in particular, I have the following >> statement to make. >> >> On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul@...> wrote: >> >> [snip] >> > >> > * It is beneficial to the Perl community (developers and users) that >> > bugs >> > are held centrally. I am sure this is also the position of the Perl >> > community. The discoverer of a bug cannot be responsible for contacting >> > each >> > distro. Distro maintainers cannot independently triage *all* bugs in >> > all >> > the packages they include. They need (we need!) "upstream", a central >> > repository. rt.cpan.org has the facility to record bugs against older >> > but >> > still current versions. It should be used as I think Jesse Vincent also >> > intended, for the benefit of the wider community, as this central >> > repository. >> > >> [snip] >> >> In Debian, we like to have everything that affects our packages filed >> in our bug tracker (the Debian Bug Tracking System). From time to time >> in the past, we have missed these bugs (ie, not forwarded them >> upstream), and this has been problematic for people. However, our bug >> tracker is entirely open and anyone is free to look at our packages >> and forward relevant issues upstream. >> >> One particular point I'd like to make is that sometimes bugs only >> exist downstream due to some modifications we've made in order to >> package things or for some other reason. As a result, it doesn't seem >> fair to bother the upstream maintainers about issues which are >> Debian-specific, or Fedora-specific, for example. >> >> Therefore, we ask that our users always file bugs against the Debian >> packages; we will coordinate with upstream appropriately to get things >> fixed, taking care to forward the bug and make whatever arrangements >> necessary to fix the package. >> >> In general, the CPAN Request Tracker has been where we forward most of >> our bug reports. Some maintainers do not like to use the RT system, >> and we have to respect their wishes. In that case, we file bugs by >> whatever means the maintainers tell us to in the POD of their >> packages, or otherwise in the RT or via direct mail. >> >> In defense of the SQL::Statement maintainers and all, I think if there >> are critical issues with older releases, they should be brought to the >> attention of each distro. Debian has policies for when things get >> synchronized between unstable <-> testing, and things that can be >> updated in stable. Things like security fixes and critical fixes are >> candidates for patches in stable, however this is the responsibility >> of Debian/Fedora/etc and not of the CPAN Maintainers. >> >> I urge you to let the CPAN maintainers do what they do best -- produce >> good software. Others (including those that package these modules) are >> responsible for distro-specific issues, and I encourage you to file >> bugs in those packages. >> >> Cheers, >> >> Jonathan > > -- To UNSUBSCRIBE, email to debian-perl-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: SQL::Statement unusable in major Linux distributions
by Paul Beardsell
::
Rate this Message:
Jonathan,
This bug is reported to exist in all versions tested 1.14 and later. This includes 1.22 recently accepted into Debian unstable and testing. It matters not what I do, I cannot install a version of SQL::Statement that works. But say I could! Say I could soon download the fixed 1.23 using some of the well-known workarounds you describe. That solves *my* problem. But we are left with the issue of how do we ensure that everyone else knows of the bug? If I report the bug to the last known distributor of Linux Crunx how does Debian get to hear of the bug? How would the maintainer at CPAN get to hear of the bug so as to know to provide a fix in 1.23? That's where your argument breaks down - in order to see the fix in 1.23 I need to let the maintainer know. If the world were just Debian and CPAN it would work well the way you describe. No, non distro specific bugs must be reported to rt.cpan.org and, as I said, this applies to old versions too and I thing RT admin agrees with me (on this very narrow point). Yes, yes, yes, I could fork SQL::Statement but I lack the skills. We (those who want a SQL engine which actually *works* on CSV files) need version 0.1020 to be resurrected. Or 1.15 fixed. Or 1.22 fixed. Those are the choices. If you want something quick perhaps only 0.1020 works. Or Sqlite. Paul Beardsell 2009/11/4 Jonathan Yu <jonathan.i.yu@gmail.com> Paul: |
|
|
Re: SQL::Statement unusable in major Linux distributions
by Jonathan Yu
::
Rate this Message:
Paul,
On Tue, Nov 3, 2009 at 10:11 PM, Paul Beardsell <paul@...> wrote: > Jonathan, > > This bug is reported to exist in all versions tested 1.14 and later. This > includes 1.22 recently accepted into Debian unstable and testing. It > matters not what I do, I cannot install a version of SQL::Statement that > works. > > But say I could! Say I could soon download the fixed 1.23 using some of the > well-known workarounds you describe. That solves *my* problem. But we are > left with the issue of how do we ensure that everyone else knows of the > bug? If I report the bug to the last known distributor of Linux Crunx how > does Debian get to hear of the bug? How would the maintainer at CPAN get to > hear of the bug so as to know to provide a fix in 1.23? That's where your > argument breaks down - in order to see the fix in 1.23 I need to let the > maintainer know. Sure. But as I said (quote): 2. If you install a package from CPAN, then the maintainer is responsible for it. That makes sense. So if you have issues with the current version of a module from CPAN, then feel free to bug the maintainer. If you have issues with an older version you get from CPAN, then it's up to the upstream people whether or not they consider your issue a bug, and whether they want to fix it. > > If the world were just Debian and CPAN it would work well the way you > describe. > > No, non distro specific bugs must be reported to rt.cpan.org and, as I said, > this applies to old versions too and I thing RT admin agrees with me (on > this very narrow point). You risk alienating the upstream this way, but it is your prerogative, of course. > > Yes, yes, yes, I could fork SQL::Statement but I lack the skills. We (those > who want a SQL engine which actually *works* on CSV files) need version > 0.1020 to be resurrected. Or 1.15 fixed. Or 1.22 fixed. Those are the > choices. If you want something quick perhaps only 0.1020 works. Or Sqlite. Here are the versions available in our package pool: http://ftp.debian.org/debian/pool/main/libs/libsql-statement-perl/ Unfortunately, the oldest version we have is: libsql-statement-perl 1.15-2 I tested this on my system (installing 1.15-2 doesn't work; I don't think I have oldstable in my apt configuration) > sudo apt-get install libsql-statement-perl=1.15-3 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: libsql-statement-perl 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 128kB of archives. After this operation, 438kB of additional disk space will be used. Get:1 http://ftp.ca.debian.org stable/main libsql-statement-perl 1.15-3 [128kB] You can always install older versions via CPAN manually too, and in Debian's case at least, you can also recommend we provide that older version for compatibility with things. I'm not sure of what other resolutions we could have; maybe someone else can chime in. > > Paul Beardsell > > > 2009/11/4 Jonathan Yu <jonathan.i.yu@...> >> >> Paul: >> >> I think you misunderstood my point, and it was probably my mistake in >> articulating myself. Here is the essential dichotomy as I understand >> it: >> >> 1. If you install a package from a distro which contains a Perl >> module, then the distro is responsible for maintaining it. If you >> install a Debian package which is broken, it's Debian's fault. If you >> install a Ubuntu package which is broken, it's Ubuntu's fault >> (possibly Debian's fault indirectly, too, of course). >> >> 2. If you install a package from CPAN, then the maintainer is >> responsible for it. That makes sense. So if you have issues with the >> current version of a module from CPAN, then feel free to bug the >> maintainer. If you have issues with an older version you get from >> CPAN, then it's up to the upstream people whether or not they consider >> your issue a bug, and whether they want to fix it. >> >> However, there are many options/workarounds in case you are >> experiencing a non-distro-specific bug due to an older version of a >> module available in YOUR distro. >> >> 1. Install into /usr/local (in Debian and Ubuntu this is done by >> default via the CPAN shell). Modules placed there should be given >> priority over ones installed via your distro (in Debian /usr/local is >> higher in @INC than /usr/share and /usr/lib, where most other stuff is >> installed) >> >> 2. Install into your homedirectory or something else. local::lib >> (available on CPAN) is tremendously useful for this purpose, I hear. >> Actually, it's also available as a Debian package - liblocal-lib-perl. >> >> Next, I think it's up to the upstream people as to their maintenance >> policy. If they have decided, "the newest is the only one we will care >> about" -- then that's what you get. This is open source; H.Merijn >> Brand, Jens Rehsack and *many* many (countless!) others contribute >> their FREE TIME (okay, maybe their $work is just nice) to provide you >> a product which is FREE (both free as in beer and free as in freedom). >> >> Because this is open source, however, you are *always* free to fork a >> module and continue maintaining it as you choose. Either that, or you >> can try convincing upstream -- but based on the length of this >> discussion, it doesn't seem like you've been able to do that thus far. >> >> On Tue, Nov 3, 2009 at 9:34 PM, Paul Beardsell <paul@...> wrote: >> [snip] >> > If I find a bug in a four year old version of a package but that is the >> > current version that is distributed in every Linux distro then there >> > needs >> > to be a central place for the bug report. Where is that? It is >> > rt.cpan.org. And I believe RT admin agrees (on this narrow point, at >> > least). That's the position we are in with SQL::Statement >> Fair enough. You have every right to file a bug and tag it with an >> older version; however, you're at the mercy of upstream if they decide >> to consider it a "I won't fix this" bug and reject it. However, you >> can also submit patches so that others who stumble on your bug report >> and are in the same position as you can fix theirs, and benefit from >> your work. >> > >> > This bug I have reported to Ubuntu via Launchpad. At the moment I have >> > not >> > reported it formally to Debian as I temporarily only have Woody because >> > that's the last Debian with a working libsql-statement-perl i.e. >> > SQL::Statement 0.1020. I have verified it on Etch and Lenny but that >> You can always determine what version of a package we have by using >> the "madison" tool via dak ls: >> >> http://qa.debian.org/madison.php -- type any package name on this >> page, and it will show you the versions available in different >> releases of Debian. Here is the output for libsql-statement-perl: >> >> libsql-statement-perl | 1.15-2 | etch-m68k | source, all >> libsql-statement-perl | 1.15-2 | oldstable | source, all >> libsql-statement-perl | 1.15-3 | stable | source, all >> libsql-statement-perl | 1.22-1 | testing | source, all >> libsql-statement-perl | 1.22-1 | unstable | source, all >> >> http://qa.debian.org/madison.php?package=libsql-statement-perl&a=&b=&c=&s= >> >> > machine is dead so I cannot report version numbers etc exactly. I have >> > reported it to CPAN for the benefit of everyone. And so the package >> > maintainer can consider if it applies to the latest version of the >> > package. >> > It does and therefore, as it is such a critical bug, the package should >> > perhaps not be accepted by Debian. But it has been! A few days before >> > my >> > bug report. And had I not been so tenacious the bug report would have >> > remained "rejected" or "deleted", not "open", and you would not know of >> > it. >> > Ever. After a while you would stop including libsql-statement-perl in >> > Debian because NOBODY uses it BECAUSE IT IS UNUSABLE by anyone who wants >> > a >> > simple SQL UPDATE statement to work. >> >> I really don't know what to say here. You can always fork it (and >> Debian users are always able to install an older version from the >> archive, and pin it there using apt-pinning. Maybe not ideal, but >> that's a possible "solution", at least until you can get this issue >> fixed upstream) >> > >> > There is a lot of excellent code available from CPAN from a lot of most >> > dedicated developers/maintainers and testers and documenters and, dare I >> > say, bug reporters! Thanks to any of you who read this. However, it is >> > *not* ALL of excellent quality, and being shy of saying so can be part >> > of >> > the problem. That doesn't mean to say that some packages are more >> The CPAN Ratings system, CPAN Testers, CPAN Testing Service (aka >> Kwalitee), FAIL100, and more are QA initiatives to help fix this. Many >> people have been working really hard on this particular problem, but >> everything needs to be in line with CPAN/Perl philosophy; there is >> more than one way to do it. >> >> Just because it doesn't work for you, doesn't mean it doesn't work for >> other people. I think it's best to keep that in mind. >> >> Given the current state of things, I think the onus is on users to >> consider these easily available bits of information via the various QA >> pages to determine whether or not the module is worth installing. >> Different people have different criteria to determine what they >> consider a "good" vs "crappy" package. CPAN Testers and the Kwalitee >> metrics provided via CPANTS are intended to help users make informed >> decisions. >> >> More work is forthcoming (particularly CPANHQ) to help make this >> information more easily available for people. >> >> PLEASE do not minimize the work of the aformentioned QA-related >> projects and THEIR various contributors to nothing. Change is >> happening, the problem is known, but HELP IS NEEDED. If you think >> Perl/CPAN QA could be improved, then either "crap or get off the pot" >> -- these are open projects, and I suggest you look into perhaps >> contributing to CPANHQ. You could be the next person to help shape the >> future direction of CPAN, and to help users make informed decisions >> when looking at modules they want to use for their next projects. >> >> I really suggest you channel your attitude in a more productive way. >> And again, if you can't convince upstream SQL::Statement maintainers >> that there is a problem, then the only recourse you can really have is >> to "fork off" (ie, fork your own module). >> >> Hopefully this helps you. I don't want to come off as someone flaming >> your response; on the contrary, I would really like to see your >> efforts here bear some fruit, even if not directly in SQL::Statement >> but in other QA-related projects like CPANHQ, CPANTS, etc. >> >> Cheers! >> >> Jonathan >> >> > challenging than others to maintain. Some maintainers have bravely >> > taken on >> > packages which are in a mess and which need lots of work. Some >> > maintainers >> > have an easy life! Others slog their guts out for no thanks. And in >> > their >> > spare time. But the quality of the packages and their maintenance does >> > vary, package to package. >> > >> > Paul Beardsell >> > >> > >> > 2009/11/4 Jonathan Yu <jonathan.i.yu@...> >> >> >> >> Hi Paul: >> >> >> >> From the perspective of Debian in particular, I have the following >> >> statement to make. >> >> >> >> On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul@...> >> >> wrote: >> >> >> >> [snip] >> >> > >> >> > * It is beneficial to the Perl community (developers and users) that >> >> > bugs >> >> > are held centrally. I am sure this is also the position of the Perl >> >> > community. The discoverer of a bug cannot be responsible for >> >> > contacting >> >> > each >> >> > distro. Distro maintainers cannot independently triage *all* bugs in >> >> > all >> >> > the packages they include. They need (we need!) "upstream", a >> >> > central >> >> > repository. rt.cpan.org has the facility to record bugs against >> >> > older >> >> > but >> >> > still current versions. It should be used as I think Jesse Vincent >> >> > also >> >> > intended, for the benefit of the wider community, as this central >> >> > repository. >> >> > >> >> [snip] >> >> >> >> In Debian, we like to have everything that affects our packages filed >> >> in our bug tracker (the Debian Bug Tracking System). From time to time >> >> in the past, we have missed these bugs (ie, not forwarded them >> >> upstream), and this has been problematic for people. However, our bug >> >> tracker is entirely open and anyone is free to look at our packages >> >> and forward relevant issues upstream. >> >> >> >> One particular point I'd like to make is that sometimes bugs only >> >> exist downstream due to some modifications we've made in order to >> >> package things or for some other reason. As a result, it doesn't seem >> >> fair to bother the upstream maintainers about issues which are >> >> Debian-specific, or Fedora-specific, for example. >> >> >> >> Therefore, we ask that our users always file bugs against the Debian >> >> packages; we will coordinate with upstream appropriately to get things >> >> fixed, taking care to forward the bug and make whatever arrangements >> >> necessary to fix the package. >> >> >> >> In general, the CPAN Request Tracker has been where we forward most of >> >> our bug reports. Some maintainers do not like to use the RT system, >> >> and we have to respect their wishes. In that case, we file bugs by >> >> whatever means the maintainers tell us to in the POD of their >> >> packages, or otherwise in the RT or via direct mail. >> >> >> >> In defense of the SQL::Statement maintainers and all, I think if there >> >> are critical issues with older releases, they should be brought to the >> >> attention of each distro. Debian has policies for when things get >> >> synchronized between unstable <-> testing, and things that can be >> >> updated in stable. Things like security fixes and critical fixes are >> >> candidates for patches in stable, however this is the responsibility >> >> of Debian/Fedora/etc and not of the CPAN Maintainers. >> >> >> >> I urge you to let the CPAN maintainers do what they do best -- produce >> >> good software. Others (including those that package these modules) are >> >> responsible for distro-specific issues, and I encourage you to file >> >> bugs in those packages. >> >> >> >> Cheers, >> >> >> >> Jonathan >> > >> > > > -- To UNSUBSCRIBE, email to debian-perl-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: SQL::Statement unusable in major Linux distributions
by H.Merijn Brand
::
Rate this Message:
On Tue, 3 Nov 2009 19:04:23 -0500, Jonathan Yu
<jonathan.i.yu@...> wrote: > Hi Paul: > > From the perspective of Debian in particular, I have the following > statement to make. > > On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul@...> wrote: > > [snip] > > > > * It is beneficial to the Perl community (developers and users) that bugs > > are held centrally. I am sure this is also the position of the Perl > > community. The discoverer of a bug cannot be responsible for contacting each > > distro. Distro maintainers cannot independently triage *all* bugs in all > > the packages they include. They need (we need!) "upstream", a central > > repository. rt.cpan.org has the facility to record bugs against older but > > still current versions. It should be used as I think Jesse Vincent also > > intended, for the benefit of the wider community, as this central > > repository. > > > [snip] > > In Debian, we like to have everything that affects our packages filed > in our bug tracker (the Debian Bug Tracking System). From time to time > in the past, we have missed these bugs (ie, not forwarded them > upstream), and this has been problematic for people. However, our bug > tracker is entirely open and anyone is free to look at our packages > and forward relevant issues upstream. > > One particular point I'd like to make is that sometimes bugs only > exist downstream due to some modifications we've made in order to > package things or for some other reason. As a result, it doesn't seem > fair to bother the upstream maintainers about issues which are > Debian-specific, or Fedora-specific, for example. > > Therefore, we ask that our users always file bugs against the Debian > packages; we will coordinate with upstream appropriately to get things > fixed, taking care to forward the bug and make whatever arrangements > necessary to fix the package. > > In general, the CPAN Request Tracker has been where we forward most of > our bug reports. Some maintainers do not like to use the RT system, > and we have to respect their wishes. In that case, we file bugs by > whatever means the maintainers tell us to in the POD of their > packages, or otherwise in the RT or via direct mail. > > In defense of the SQL::Statement maintainers and all, I think if there > are critical issues with older releases, they should be brought to the > attention of each distro. Debian has policies for when things get > synchronized between unstable <-> testing, and things that can be > updated in stable. Things like security fixes and critical fixes are > candidates for patches in stable, however this is the responsibility > of Debian/Fedora/etc and not of the CPAN Maintainers. > > I urge you to let the CPAN maintainers do what they do best -- produce > good software. Others (including those that package these modules) are > responsible for distro-specific issues, and I encourage you to file > bugs in those packages. Thanks for sharing your clear views from the Debian point of view, and I I wholeheartedly agree. Not only for perl Modules but also for the CORE, and I know things have been (very) bad in the past (in both directions) regarding up-/downstream changes to perl. Things have improved though. > Cheers, > > Jonathan -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ -- To UNSUBSCRIBE, email to debian-perl-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
|
|
Re: SQL::Statement unusable in major Linux distributions
by Jens Rehsack-2
::
Rate this Message:
2009/11/4 H.Merijn Brand <h.m.brand@...>:
> On Tue, 3 Nov 2009 19:04:23 -0500, Jonathan Yu > <jonathan.i.yu@...> wrote: > >> Hi Paul: >> >> From the perspective of Debian in particular, I have the following >> statement to make. >> >> On Tue, Nov 3, 2009 at 5:49 PM, Paul Beardsell <paul@...> wrote: >> >> [snip] >> > >> > * It is beneficial to the Perl community (developers and users) that bugs >> > are held centrally. I am sure this is also the position of the Perl >> > community. The discoverer of a bug cannot be responsible for contacting each >> > distro. Distro maintainers cannot independently triage *all* bugs in all >> > the packages they include. They need (we need!) "upstream", a central >> > repository. rt.cpan.org has the facility to record bugs against older but >> > still current versions. It should be used as I think Jesse Vincent also >> > intended, for the benefit of the wider community, as this central >> > repository. >> > >> [snip] >> >> In Debian, we like to have everything that affects our packages filed >> in our bug tracker (the Debian Bug Tracking System). From time to time >> in the past, we have missed these bugs (ie, not forwarded them >> upstream), and this has been problematic for people. However, our bug >> tracker is entirely open and anyone is free to look at our packages >> and forward relevant issues upstream. >> >> One particular point I'd like to make is that sometimes bugs only >> exist downstream due to some modifications we've made in order to >> package things or for some other reason. As a result, it doesn't seem >> fair to bother the upstream maintainers about issues which are >> Debian-specific, or Fedora-specific, for example. >> >> Therefore, we ask that our users always file bugs against the Debian >> packages; we will coordinate with upstream appropriately to get things >> fixed, taking care to forward the bug and make whatever arrangements >> necessary to fix the package. >> >> In general, the CPAN Request Tracker has been where we forward most of >> our bug reports. Some maintainers do not like to use the RT system, >> and we have to respect their wishes. In that case, we file bugs by >> whatever means the maintainers tell us to in the POD of their >> packages, or otherwise in the RT or via direct mail. >> >> In defense of the SQL::Statement maintainers and all, I think if there >> are critical issues with older releases, they should be brought to the >> attention of each distro. Debian has policies for when things get >> synchronized between unstable <-> testing, and things that can be >> updated in stable. Things like security fixes and critical fixes are >> candidates for patches in stable, however this is the responsibility >> of Debian/Fedora/etc and not of the CPAN Maintainers. >> >> I urge you to let the CPAN maintainers do what they do best -- produce >> good software. Others (including those that package these modules) are >> responsible for distro-specific issues, and I encourage you to file >> bugs in those packages. > > Thanks for sharing your clear views from the Debian point of view, and I > I wholeheartedly agree. Not only for perl Modules but also for the CORE, > and I know things have been (very) bad in the past (in both directions) > regarding up-/downstream changes to perl. Things have improved though. Here I fully agree. Not only as SQL::Statement maintainer, but as packager in pkgsrc, too. It's not always easy to report bugs upstream, and more: not each developer/packager of a module has the appropriate test environment the reporter has. That's why I always ask for easy, small tests (as you provide them to me always - and I'm very thankful for them). Even more useful is the filter functionality of the distribution bug tracking and upstream forwarding: it fills the bugs more carefully. In fact - I like to use it, even on NetBSD (my favorite distribution) as committer. If I encounter a problem I cannot solve on my own, I'm going to find a responsible committer and ask him for help transporting the issue upstream - and maybe, applying a fix into the packaging system until the next release is delivered. I think Debian is making a good job there (I have several Linux distributions on some test boxes running once all 3 month - and Debian costs me less effort of all). Best regards, Jens -- To UNSUBSCRIBE, email to debian-perl-REQUEST@... with a subject of "unsubscribe". Trouble? Contact listmaster@... |
| Free embeddable forum powered by Nabble | Forum Help |
