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.

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?

Given the last responses I got from people who could actually make effective such a patch, writing such a patch would be a waste of time at this point. The next step is to just get anybody with access to make changes to CPAN infrastructure (search.cpan and/or pause) to actually admit that there is a problem and to also work out the outlines of improvements that would work.

Even if I implemented a solution that would perfectly address the problem (imagining a divine being or something that could determine that in advance) but the proposal caused people to react to it with shouts of "that's stealing!", it likely would do no good.

So, for now, I try to listen and to persuade.

- tye        

... 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.

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.

"Calm down deary. Calm down."