Hi, just noticed that this module seems to have been released.

One feature I would be interested in is auto patching the updated module. This is not useful for everyone, but I have a couple of modules that are modified from their release on drupal.org:

1. Allow apostrophe's in Drupal core usernames. Patch has been submitted and applied for Drupal 7, but the drupal 6 version seems to be languishing with noone moving it to RTBC.

2. I have also supplied a patch for image.module to make the imagesize selectable in the content-type settings.

It would be good if there was an option for the plugin manager to track such things, or apply integration with other modules to track such things (I think there is a logging module out that does that) and upon download of a new release, give an option to attempt to patch the module.

Comments

kbahey’s picture

kbahey CreditAttribution: kbahey commented
Status: Active » Postponed

I think this is out of scope for what this module does.

Cramming it up with features like this which are developer oriented is not a good idea.

We need to first make it do what it was set to do, stabilize it, and work on getting it in D7 core. We don't need scope creep and featuritis.

I am tempted to mark this won't fix, but went for postponed in case we can revisit this at some time in the distant future.

dman’s picture

dman CreditAttribution: dman commented
Status: Postponed » Active

I see what you are describing, but can you imagine the UI for this?!
- Trying to track all open issues on all available modules,
- looking for *.patch files in the comments, many of which are alternative versions of the same functionality,
- then presenting them all to the user out of context saying :

Here are 142 badly named, untested patches found in the queues that may or may not apply to your assorted modules, some of which are very likely to conflict with each other, many of which are outdated, none of which are sanctioned by the maintainers. Please check the ones you wish to try and apply. May the Lord have mercy on your system.

Although I can just about imagine a system that allows users to check out unofficially patched projects, trying to imagine how to do that sanely through an abstracted update notifier is really hard.

Importantly - unofficially patching any module will immediately make it incompatible with later automated official updates - especially if the premature patch is one which addresses a fix that then eventually gets rolled in to the official module. You end up with revision conflicts immediately - and that's a lot deeper water than anyone who doesn't want to play with CVS (ie, the target audience of this module) deserves to be in.

I've said it before - applying patches is for developers. If you patch your own system, you are creating a branch. If you can't maintain your own branch (or in this case build a UI to maintain CVS branching for you!) then don't patch prematurely!

Not that your idea isn't an interesting wishlist item, it's just that it necessitates the entire overhead of building a web GUI for CVS plus interaction with remote web services within d.o project module (!). And documenting it.
:-B

dman’s picture

dman CreditAttribution: dman commented
Status: Active » Postponed

Didn't mean to change status.

NaheemSays’s picture

NaheemSays CreditAttribution: NaheemSays commented

Yeah, it is feature creep, so I do understand it not going in.

As for the later question, I do not see this module tracking all the issues on drupal.org.

There is already a module out there (the name of which escapes me atm) where you can specify modifications made to the core/modules so when the times comes to update you know which modules you have modified.

What I was asking for was for this module to actually recognise that a module has been modified (through the admin telling it so) and to store the patch.

When the time comes to update the module, this module (or more likely, another module extending the functionality) could give an option to patch or not. If patch fails, give option to either remove the patch from the log (in the case the patch has been accepted upstream), ignore this time or upload a replacement patch.

dman’s picture

dman CreditAttribution: dman commented

So you mean to keep track of locally changed modules that are no longer in a pristine state, so as to take special care of them when running updates? That at least is sane :)

Your description of the patches in the issue queues that you wanted to be applied automatically sounded like you wanted the ability to apply patches from the issue queues automatically. :-}
Not the same thing at all, as it turns out.

FWIW, the tool I use to track what I've changed on my copy is cvs diff :-B

NaheemSays’s picture

NaheemSays CreditAttribution: NaheemSays commented

yup, your first para explains it. (and I mostly use plain diff to get the patches - should not really be an issue either way.)

As for mentioning the issue queue, if someone is crazy/brave enough, the extending module could be extended so that in the case that a issue has been submitted, it could try and figure out if the patch has been merged upstream and no longer try to apply it.

But all this is up in the cloud thinking and I have no idea how it would be made to work.

NaheemSays’s picture

NaheemSays CreditAttribution: NaheemSays commented
Title: automatic custom patch support? » Mark modules as tainted and not upgrade.
Status: Postponed » Active

Actually, there is another thing that this module COULD do. Allow the user/admin to mark modules which should NOT be updated by it and just give the message that it needs to be manually updated.

Extra pointss for having a field where the admin/user gives a reason for marking as tainted.

(I am thinking of multi user/admin situations where others may have access to update the modules, but not necessarily the knowledge that a certain module has been altered.)

NaheemSays’s picture

NaheemSays CreditAttribution: NaheemSays commented
Title: Mark modules as tainted and not upgrade. » Ability to mark modules as tainted and exclude their updates.
Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The ability to tell the plugin manager "Do not upgrade this module" does sound quite useful. I will try to add this (as soon as I get the update feed patched.) Granted, it would probably make it in much sooner if someone would like to submit a patch. ;) *hint* *hint*

jabapyth’s picture

jabapyth CreditAttribution: jabapyth commented

currently, PM doesnt 'automatically' upgrade modules -- you go to the upgrade page, and you select the modules you want to upgrade. This functionality is already present.

jabapyth’s picture

jabapyth CreditAttribution: jabapyth commented
Status: Active » Closed (won't fix)

and by wont fix i mean theres no need

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Closed (won't fix) » Postponed

As a compromise, I believe that we could label any release that has been modified since it was installed.

DrewMathers’s picture

DrewMathers CreditAttribution: DrewMathers commented

You can manually exclude modules from PM's update using

http://drupal.org/project/update_advanced

I have tested this and it works.

http://drupal.org/project/patch_manager might solve the patch issue, but I have not tested it.

DrewMathers’s picture

DrewMathers CreditAttribution: DrewMathers commented

Further to the above post, when you exclude an update using the Update Advanced Settings module, you have to re-run the Admin > Reports > Available Updates report before PM will recognize the change.