That's an excellent argument.
First, the author never loses his existing PAUSE directory. Granting co-maintainership doesn't mean that he will lose his autograph from the project. I would think that most individuals picking up co-maintainership on a module would be respectful enough to maintain credit to the original author.
I think that it speaks highly of an author's maturity and integrity when he is willing to recognize that his level of interest and ability to devote time to a project is waning. Handing off the baton to someone else with the talent, time, and interest is in the best interest of the module's user. Taking that action when the time comes is another feather in the author's cap.
| [reply] |
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. I do realize that what I consider a bug, may not be considered a bug by someone else.
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? | [reply] |
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.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
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.
| [reply] |
