there are a few release nodes in the system where we don't really want packages (re)generated. for example, the "x.y.z" release node in core, the "6.x-dev" release, etc. currently, i've just been forcing these to have a bogus tag via manual SQL. the packaging script still goes through the trouble to try to package, but fails with the faulty tag. this generates extra work for the script, and more noise in the watchdog logs. it'd be nice if there was a way (only for project admins) to be able to disable packaging on any given release node. there might be other use cases for this, too.
Comments
Comment #1
babbage commentedCleaning up old issues. Mindful dww is a maintainer of this module, so can add this feature if he likes! Given it is currently possible to have -dev releases not displayed to users on the module page, and given that anonymous CVS access is available to anyone, I'm not sure that this feature would add anything now—but perhaps those situations were different in 2006? If you don't want a package to be created, I would assume you simply wouldn't make a CVS commit.
Hmm, dww, sorry to create noise in your issue queue but don't want to decide for you. Will leave for you to close if you don't want to do this any longer?
Comment #2
dwwNo, we still need this. One use case is someone tags a broken translation, and the packaging script keeps trying to repackage it over and over, since even if the user fixes the translation and adds a new tag, the old broken tag still doesn't have a file and the packaging script keeps trying (and failing) to package it....
Comment #3
gábor hojtsyShould we have a flag (column) on releases which would count the attempts at packaging and stop trying packaging after the third try or something? Any better ideas for the approach?
Comment #4
dww@Gabor: Yes, that's basically what killes and I discussed both ages ago and a few days ago. ;) There's already a {project_release_package_errors} table for recording errors so they can be displayed on release nodes. Perhaps that's the best place for such a column. Or just directly in {project_release_nodes} perhaps.
Comment #5
killes@www.drop.org commentedI am increasing the prio on this one.
We have a lot of releases that are broken for one reason or other. It is a drain on resources to try to repackage them and all the messages about broken releases clutter the output and obscure the visibility of real problems.
Comment #6
dwwI agree it's major, but I don't think it makes any sense to try to solve this in D6. We should focus on the D7 launch and either fix this at the same time (scope creep) or soon after launch (my vote). If you think this is a launch blocker, you should add "Drupal.org D7, project" to the issue tags, but then you get to argue with drumm, tvn et al about it. ;)
Comment #7
drummThis hasn’t been a practical issue lately. The big change was storing what Git commit we have packaged, and not re-packaging when unnecessary: https://git.drupalcode.org/project/drupalorg/blob/7.x-3.x/drupalorg_proj...