-=| Damyan Ivanov, Sun, Aug 28, 2011 at 08:12:04AM +0300 |=- > -=| Dominique Dumont, Sat, Aug 27, 2011 at 07:17:04PM +0200 |=- > > Another approach is to upload padre to unstable and fix plugins when > > they are broken. This should take less time on your side and get > > more people actively packaging padre plugins. > > > > I grant you that this approach is more brutal, but given the > > available resources to package padre and its plugins, this may be > > the lesser of evils. > > Right. A call for testing on debian-perl could be useful too. What > I like about it is that the whole padre-api-X fiasco can go away. The > plugins could just depend on the padre version they were built with. > > An occasional testing using the just built padre should help too. At > least it would detect any incompatibilities that show themselves at > plugin load time. > > Let's see how far I could get with this. Alright, padre 0.90 uploaded to unstable (with unstable branch merged into master, thanks Dominique for the kindly TODO item :) Seven plugins fail to load. Upstream bugs filed and there is a will to fix the plugins so that they work with the new Padre. I suspect they'd gladly welcome help. I guess I should also file (RC) bugs for the corresponding Debian packages (as a reminder and maybe a warning to their users): - libpadre-plugin-autoformat-perl - libpadre-plugin-css-perl - libpadre-plugin-html-perl - libpadre-plugin-javascript-perl - libpadre-plugin-xml-perl - libpadre-plugin-perltidy-perl - libpadre-plugin-vi-perl It is getting late now, so if somebody feels like it, please go ahead.
Attachment:
signature.asc
Description: Digital signature