XML Sitemap 6.x-1.x-dev: Bugs, Typos & Quality
Hi everybody... since a couple of weeks i have permanent problems with the development snapshots of the XML Sitemap. O.K. i know these are dev-snapshots, but i don't really uderstand what happens here. if i would check out these files from CVS, i could live with the recent bugs (nearly all are typos, e.g. "columhn_exist" or forgotten semicolons, paranthesis, ...) but i really wonder how someone could package these broken files into a tar.gz and release it... This is very uncomfortable on my development servers as they nearly all run on lighttpd and you have to do some tricks to get it to work with drupals Clean-URLs, you allways have to change same line of code in settings-file, run the updates, get errors, fix all the stupid little typos, run updates again, add semikolon, ... I really would see the devs checking the code (or simply use something like eclipse and look for the underlined parts of their code...) before packaging it and releasing it to the website. On all my servers there are about 15 drupal-Sites and i never had these problems with any other modules. Jens -- Jens Reinemuth Ahornweg 23 51469 Bergisch Gladbach Germany
On Thursday 18 December 2008 20:47:07 Jens Reinemuth wrote:
O.K. i know these are dev-snapshots, but i don't really uderstand what happens here. if i would check out these files from CVS, i could live with the recent bugs (nearly all are typos, e.g. "columhn_exist" or forgotten semicolons, paranthesis, ...) but i really wonder how someone could package these broken files into a tar.gz and release it...
The answer is in your question. Those are dev snapshots and they are packaged *automatically* for those who want to test the said module and develop for it. It seems that this module could be better maintained, but that's irrelevant. Stick to published, stable versions to avoid surprises. (I've had quite a few myself using dev snapshots of other modules...) Augustin.
The issue queue for http://drupal.org/project/xmlsitemap is over there. Instructions for creating patches are at http://drupal.org/patch/create Development tarballs are created automatically by the Drupal.org packaging script and have big red Xs next to them to stop regular users downloading them. It's the same as checking it out from CVS, except a daily snapshot of whatever's in there at the time. Development tarballs are for people to try out and contribute back bug reports and patches back to the issue queue so they can be rolled into the next stable release - if you can fix things locally, you could have spent the time doing this instead of sending a complaint to however many thousand people subscribe to this list. Nat On Thu, Dec 18, 2008 at 12:47 PM, Jens Reinemuth wrote:
Hi everybody...
since a couple of weeks i have permanent problems with the development snapshots of the XML Sitemap.
O.K. i know these are dev-snapshots, but i don't really uderstand what happens here. if i would check out these files from CVS, i could live with the recent bugs (nearly all are typos, e.g. "columhn_exist" or forgotten semicolons, paranthesis, ...) but i really wonder how someone could package these broken files into a tar.gz and release it...
This is very uncomfortable on my development servers as they nearly all run on lighttpd and you have to do some tricks to get it to work with drupals Clean-URLs, you allways have to change same line of code in settings-file, run the updates, get errors, fix all the stupid little typos, run updates again, add semikolon, ...
I really would see the devs checking the code (or simply use something like eclipse and look for the underlined parts of their code...) before packaging it and releasing it to the website.
On all my servers there are about 15 drupal-Sites and i never had these problems with any other modules.
Jens
-- Jens Reinemuth Ahornweg 23 51469 Bergisch Gladbach Germany
Nathaniel Catchpole schrieb:
The issue queue for http://drupal.org/project/xmlsitemap is over there.
Instructions for creating patches are at http://drupal.org/patch/create
Development tarballs are created automatically by the Drupal.org packaging script and have big red Xs next to them to stop regular users downloading them. It's the same as checking it out from CVS, except a daily snapshot of whatever's in there at the time.
Development tarballs are for people to try out and contribute back bug reports and patches back to the issue queue so they can be rolled into the next stable release - if you can fix things locally, you could have spent the time doing this instead of sending a complaint to however many thousand people subscribe to this list.
Nat So it's better to submit a bunch of patches simply correcting typos than trying to get to know where (or who) the problem is?
Sorry for "spamming" those thousands of drupal-users here. But i don't get it: Even if i stay on dev-linuxes, with dev-kernels, dev-drivers, dev-software, ... the times someone submitted code with such simple typos in the recent years would be under 10. On the opposite i have a module where the devs (or maintainers) constantly check-in - easy to fix - bugged code. If this is common in the drupal-scene we would have to change something about it... But ok. I'll get a cvs-account and commit about 10 patches a week countaining commas or something like that... Jens
When you talk about the dev-linuxes, dev-kernels, etc. that would be comparable to drupal core. Each contributed module is it's own project (like the linux kernel) but on a much smaller scale. Some of these projects are well maintained and the issues noted aren't a problem. Some of them, just like projects all over, could use some love and attention. If you willing I imagine a lot of maintainers would welcome the help in creating better projects. I know I would. Quoting Jens Reinemuth <jens@reinemuth.info>:
Nathaniel Catchpole schrieb:
The issue queue for http://drupal.org/project/xmlsitemap is over there.
Instructions for creating patches are at http://drupal.org/patch/create
Development tarballs are created automatically by the Drupal.org packaging script and have big red Xs next to them to stop regular users downloading them. It's the same as checking it out from CVS, except a daily snapshot of whatever's in there at the time.
Development tarballs are for people to try out and contribute back bug reports and patches back to the issue queue so they can be rolled into the next stable release - if you can fix things locally, you could have spent the time doing this instead of sending a complaint to however many thousand people subscribe to this list.
Nat So it's better to submit a bunch of patches simply correcting typos than trying to get to know where (or who) the problem is?
Sorry for "spamming" those thousands of drupal-users here. But i don't get it: Even if i stay on dev-linuxes, with dev-kernels, dev-drivers, dev-software, ... the times someone submitted code with such simple typos in the recent years would be under 10.
On the opposite i have a module where the devs (or maintainers) constantly check-in - easy to fix - bugged code. If this is common in the drupal-scene we would have to change something about it...
But ok. I'll get a cvs-account and commit about 10 patches a week countaining commas or something like that...
Jens
On Thu, Dec 18, 2008 at 1:37 PM, Matt Farina wrote:
When you talk about the dev-linuxes, dev-kernels, etc. that would be comparable to drupal core.
Each contributed module is it's own project (like the linux kernel) but on a much smaller scale. Some of these projects are well maintained and the issues noted aren't a problem. Some of them, just like projects all over, could use some love and attention.
If you willing I imagine a lot of maintainers would welcome the help in creating better projects. I know I would.
This is very true, also note that the poor quality of so many contributed projects is a known issue, and Drupal.org has been introducing measures to deal with it - see http://drupal.org/project/usage for one. More are likely to come with the redesign too, and maybe via http://testing.drupal.org(which currently only runs core tests) in the future. Nat
I just took a look at the xmlsitemap issue queue - it looks like someone already submitted a bug report for the "columhn_exist" typo, and it was fixed this morning - http://drupal.org/node/348599 - so you won't need to fix that again next time the tarball is generated. That suggests there's at least some activity there, and no reason you couldn't expect an answer had you posted your query here rather than there. The chances of any one maintainer reading the development list are a lot lower though. Nat PS. you don't need to apply for a CVS account to submit patches. On Thu, Dec 18, 2008 at 1:21 PM, Jens Reinemuth wrote:
Nathaniel Catchpole schrieb:
The issue queue for http://drupal.org/project/xmlsitemap is over there.
Instructions for creating patches are at http://drupal.org/patch/create
Development tarballs are created automatically by the Drupal.org packaging script and have big red Xs next to them to stop regular users downloading them. It's the same as checking it out from CVS, except a daily snapshot of whatever's in there at the time.
Development tarballs are for people to try out and contribute back bug reports and patches back to the issue queue so they can be rolled into the next stable release - if you can fix things locally, you could have spent the time doing this instead of sending a complaint to however many thousand people subscribe to this list.
Nat So it's better to submit a bunch of patches simply correcting typos than trying to get to know where (or who) the problem is?
Sorry for "spamming" those thousands of drupal-users here. But i don't get it: Even if i stay on dev-linuxes, with dev-kernels, dev-drivers, dev-software, ... the times someone submitted code with such simple typos in the recent years would be under 10.
On the opposite i have a module where the devs (or maintainers) constantly check-in - easy to fix - bugged code. If this is common in the drupal-scene we would have to change something about it...
But ok. I'll get a cvs-account and commit about 10 patches a week countaining commas or something like that...
Jens
Nathaniel Catchpole schrieb:
I just took a look at the xmlsitemap issue queue - it looks like someone already submitted a bug report for the "columhn_exist" typo, and it was fixed this morning - http://drupal.org/node/348599 - so you won't need to fix that again next time the tarball is generated.
That suggests there's at least some activity there, and no reason you couldn't expect an answer had you posted your query here rather than there. The chances of any one maintainer reading the development list are a lot lower though.
Nat
PS. you don't need to apply for a CVS account to submit patches.
On Thu, Dec 18, 2008 at 1:21 PM, Jens Reinemuth wrote:
Nathaniel Catchpole schrieb: > The issue queue for http://drupal.org/project/xmlsitemap is over there. > > Instructions for creating patches are at http://drupal.org/patch/create > > Development tarballs are created automatically by the Drupal.org > packaging script and have big red Xs next to them to stop regular > users downloading them. It's the same as checking it out from CVS, > except a daily snapshot of whatever's in there at the time. > > Development tarballs are for people to try out and contribute back bug > reports and patches back to the issue queue so they can be rolled into > the next stable release - if you can fix things locally, you could > have spent the time doing this instead of sending a complaint to > however many thousand people subscribe to this list. > > Nat So it's better to submit a bunch of patches simply correcting typos than trying to get to know where (or who) the problem is?
Sorry for "spamming" those thousands of drupal-users here. But i don't get it: Even if i stay on dev-linuxes, with dev-kernels, dev-drivers, dev-software, ... the times someone submitted code with such simple typos in the recent years would be under 10.
On the opposite i have a module where the devs (or maintainers) constantly check-in - easy to fix - bugged code. If this is common in the drupal-scene we would have to change something about it...
But ok. I'll get a cvs-account and commit about 10 patches a week countaining commas or something like that...
Jens
Ok... So i will wait fot the next release... I really try to make things better, not to say "getting things done"... What about e.g. a simple cronjob running preivious to the packaging, which simply lets a php-cli parsing the files... so such errors would not occur in packages. This way you cannot fix logical errors, but those simple typos would vanish... Jens
On Thu, Dec 18, 2008 at 1:21 PM, Jens Reinemuth wrote:
I really try to make things better, not to say "getting things done"...
OK, that wasn't clear from your initial e-mail, but I'm glad you've responded .
What about e.g. a simple cronjob running preivious to the packaging, which simply lets a php-cli parsing the files... so such errors would not occur in packages.
This way you cannot fix logical errors, but those simple typos would vanish...
This is a great idea - opened a feature request - http://drupal.org/node/348678 Eventually we'd like to have test runs and coverage reports for contrib modules, but if it's straightforward to implement in the interim, would be a very nice addition. Nat
But ok. I'll get a cvs-account and commit about 10 patches a week countaining commas or something like that...
Jens
Please note that you do not need a CVS account to checkout code from CVS and create patches. You only need a CVS account for maintaining (i.e. committing code to) a project on drupal.org. Daniel
participants (5)
-
augustin (beginner) -
Daniel F. Kudwien -
Jens Reinemuth -
matt＠mattfarina.com -
Nathaniel Catchpole