Re^12: Fixing broken CPAN modules without author cooperation (years)

[BrowserUk]

Ah, but you're on a high horse where you think that what you consider to be outdated or a bug, is considered so by other as well.

There is nothing "high horse" about making a fix that works for me -- and may well work for others of the same module -- available in a way that allows those others to choose between my fix and the original authors version with a simple click of their mouse.

As for not making fixes available, I don't get it. Is it impossible to make fixes available in any other way than to release a module with the same name?

Other ways? Sure. Better ways? Emphatically no.

When I go to CPAN looking for a module XYZ::PQR; there is no other mechanism that will inform me that there is a later patched version of that module available from a different author that I might find better than the original.

With the "BIG RED UNAUTHORISED" banner, I can read the two pods, inspect the sources, and make an informed choice as to which I download. Any other mechanism -- whether a patch to the authorised version, or a module with a similar name -- leaves me uninformed of the choice available.

Unless of course the absent or uncooperative author/maintainer decides to reference the patch/renamed-fork in his POD which is about as likely as "green energy" saving the planet.

And all the 'usurped' author has to do to 'reclaim his heritage' is upload a new version. If he really wants to be bloody minded, he could just increment the version number by 2 and do nothing else and the unauthorised version will just sink into obscurity. I'd hope that no one would play such silly games, but it is available as an option.

[JavaFan]

When I go to CPAN looking for a module XYZ::PQR; there is no other mechanism that will inform me that there is a later patched version of that module available from a different author that I might find better than the original.

Ah, ok, so, if I think I have a better idea on how to implement XYZ::PQR, I should just release a version of XYZ::PQR with a higher version number, just to draw attention that I have a "patched" version?

When is something a bug fix? What if it fixes a bug, but breaks someones else code? I guess you'll be saying "well, screw him, let him do the work, find the documentation this is patched version by another author, and let him download older version". But that's not something I would like to do.

Well, good for you. I have a conscience. I'll just pick another name, and I'm not arrogant enough that my patch is so fucking important as to the steal the name.

[tye]

Ah, ok, so, if I think I have a better idea on how to implement XYZ::PQR, I should just release a version of XYZ::PQR with a higher version number, just to draw attention that I have a "patched" version?

Um... no. False dichotomy?

When is something a bug fix?

Depends on how many angels are dancing on the head of your pin. How about we skip the "extend the analogy to absurd extremes and then justify our argument from the resulting mess"?

If you want to re-implement the module, feel free. If you upload your re-implementation to masquerade as simply a new version, then you are probably being a jerk.

But we weren't talking about re-implementing. We were talking about a simple bug fix. If it isn't a simple bug fix, then it might be something between those extremes and one might have to exercise judgement.

I'm not so arrogant to think that my little patch to a simple bug deserves its own name and own lifespan outside the other module. Turning "contributing a bug fix and publishing it" into "stealing" is just comical.

If we want to go the "stealing" route with respect to IP, then I find "cut'n'paste somebody else's module, fix one bug, slightly change the name, upload under my name" to be a closer fit.

Modules usually end up having more than one bug. It doesn't take extremes, just two bugs solved by two different people and we've got 3 modules with slightly different names and no obvious ancestry tree. I much prefer bug fixes be handled in the "linear series of version numbers" with perhaps newer version(s) being "unofficial" for a while, when a module author can't manage to jump through the CPAN hoops very fast.

I'd actually like to empower module authors to declare how fast they consider "fast enough". It is my experience that most module authors want to and expect that they will update their modules relatively quickly but most eventually end up in a mode where their speed at support is drastically reduced. I think most would benefit from establishing a time span at which they've declared defeat and others can jump in and produce official versions of the module. Many times that will actually solve the motivation problem for the previous author, but when it doesn't, new author(s) can step in with their fresh motivation.

[Anonymous Monk]

I'd actually like to empower module authors to declare how fast they consider "fast enough".

:) So what kind of patch to CPAN::Meta::Spec / http://module-build.sourceforge.net/META-spec.html are you considering?

[BrowserUk]

... steal the name.

No one is "stealing" anything. And your attitude is preposterous and illogical.

S'funny, till now I had you down as a open source advocate; not an "ownership is everything" troll.

[JavaFan]

open source advocate

Open source is about giving, and accepting what you get. It isn't about taking or demanding.

If an author of a module doesn't reply to you in a time frame that's acceptable to you, too bad for you. (Sh/H)e donated to original code, and not someone else. I think it nothing to be decency to accept the gift as is, and, if I think I can do it better I can publish something else (if I'm lucky, the license allows me to reuse code).

S'funny, till now I had you down

I don't give a rats ass what you think of me.