On 21/01/2023 02:11, demerphq wrote:
>
> I feel that our community is in a long slow decline. We don't attract
> new devs. ...
>
> I want to make it easier for people to join our community, I want
> people to see perl as *fun*. Frankly if someone's first encounter with
> perl is a DZ github repo with no build instructions I think they will
> walk away thinking we are *fun*.
What you responded to me a couple of days earlier does not seem like a
way of encouraging new devs:
> And you have a copies amount of experience fixing Blead Breaks CPAN
> bugs do you? No doubt you did all that work under a synonym as I can
> find only a single patch to core under your name and that was a doc
> fix, not likely to create any fallout. Did I miss you feverishly
> working to fix BBC tickets under this alias?
>
> I'm being sarcastic because you post vehemently about how you disagree
> with me, but seem to more or less admit you have no shared context to
> understand what i am complaining about.
Obviously you have a different perspective.
It would be much more productive if instead of criticising the use of a
tool that makes CPAN author's lives easier, you come up with suggestions
on how they can change how they use it make things easier for people
like yourself who test modules against blead Perls.
Hint: maybe work with the Dist::Zilla author to add a setting or plugin
to make life easier for people testing modules against blead Perls.
The use of Dist::Zilla not only benefits authors, it benefits the entire
community since it limits common release breakages from being uploaded
to CPAN.
An author using Dist::Zilla means that they can focus on the code and
avoid many of bureaucratic errors that can break releases:
- Modules have consistent version numbers and documentation;
- Prerequisites are properly declared;
- Makefile.PL, MANIFEST and README are up-to-date;
- An up-to-date cpanfile is generated, which allows devs to work on the
module without installing prerequisites globally;
- Quality control author tests can be run before releasing, to avoid
other common mistakes like POD errors etc;
>
> I feel that our community is in a long slow decline. We don't attract
> new devs. ...
>
> I want to make it easier for people to join our community, I want
> people to see perl as *fun*. Frankly if someone's first encounter with
> perl is a DZ github repo with no build instructions I think they will
> walk away thinking we are *fun*.
What you responded to me a couple of days earlier does not seem like a
way of encouraging new devs:
> And you have a copies amount of experience fixing Blead Breaks CPAN
> bugs do you? No doubt you did all that work under a synonym as I can
> find only a single patch to core under your name and that was a doc
> fix, not likely to create any fallout. Did I miss you feverishly
> working to fix BBC tickets under this alias?
>
> I'm being sarcastic because you post vehemently about how you disagree
> with me, but seem to more or less admit you have no shared context to
> understand what i am complaining about.
Obviously you have a different perspective.
It would be much more productive if instead of criticising the use of a
tool that makes CPAN author's lives easier, you come up with suggestions
on how they can change how they use it make things easier for people
like yourself who test modules against blead Perls.
Hint: maybe work with the Dist::Zilla author to add a setting or plugin
to make life easier for people testing modules against blead Perls.
The use of Dist::Zilla not only benefits authors, it benefits the entire
community since it limits common release breakages from being uploaded
to CPAN.
An author using Dist::Zilla means that they can focus on the code and
avoid many of bureaucratic errors that can break releases:
- Modules have consistent version numbers and documentation;
- Prerequisites are properly declared;
- Makefile.PL, MANIFEST and README are up-to-date;
- An up-to-date cpanfile is generated, which allows devs to work on the
module without installing prerequisites globally;
- Quality control author tests can be run before releasing, to avoid
other common mistakes like POD errors etc;