I don't expect everyone to tag their point releases.
I am not even that consistent about it; but I went back
using these tags:
- ran, "dzil build"
- deleted the tar.gz files
- moved all build directories into a ./releases directory
- committed these to the repo,
https://github.com/oodler577/p5-Util-H2O-More/tree/master/releases
And I hopefully will be consistent about doing this in the
future. I did this to demonstrate what I mean when I ask, would
something like this help for modules that actually matter far
upstream and also use Dist::Zilla? What I hope to show here is
potential value in keeping such artifacts around for recent
versions in the event someone needs to fix things. And I am
further hopeful that a module author/maintainer doing this is
an indication that they are willing to do the work necessary
to port changes made to "fix" the dist.ini file to ensure that
the fixes to artifact files persist.
Thoughts?
Brett
* Oodler 577 via perl5-porters <perl5-porters@perl.org> [2023-01-22 00:27:41 +0000]:
> * demerphq <demerphq@gmail.com> [2023-01-21 10:11:37 +0800]:
>
> > On Sat, 21 Jan 2023, 05:16 Christian Walde, <walde.christian@gmail.com>
> > wrote:
> >
> > > On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org>
> > > wrote:
> > >
> > > > I can imagine working on some forward
> > > > version of perl using a well tuned workflow, running into issues that
> > > > you can't build Dist::Zilla
> > >
> > > Maybe it's a language issue i am running into, not being a native speaker,
> > > but this seems to indicate to me you are indeed misunderstanding.
> > >
> > > As has been said multiple times now:
> > >
> > > Do not run dzil on your blead perl. There is no reason to think that is
> > > necessary at all.
> > >
> >
> > See that is part of the problem. You know that, I guess it's well known
> > amongst users. But how is someone how isn't a user supposed to know that?
> >
> <snip>
> >
> > The reason I think DZ is harmful to the Perl ecosystem is precise because
> > of this lack of transparency. Perl is already cryptic enough, having loads
> > of cpan related repos on github with no "readme" files or instructions etc
> > just makes it more likely that someone incidentally encountering them will
> > have no idea what to do with them get frustrated and go away thinking our
> > community is really backwards. People can disagree all they want with that
> > point of view, they can call it judgemental or think it's an insult. That
> > is ok, I'll just continue thinking they are in denial as our community
> > shrinks and withers away.
> >
> > I feel that our community is in a long slow decline. We don't attract new
> > devs. Many of the devs left seems more protective of their habits and
> > preferences and prerogatives than on ensuring our community grows. I love
> > perl, and I want to see it continue for many years to come and id like see
> > fresh faces get involved. that is why I continue hacking core and why I
> > focus on the parts I do. Bug fixes, stability, error handling, regex engine
> > (one of the few places where we still have a strong influence on the wider
> > computing community) etc.
> >
> > 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*.
>
> A community that "prides" it self in vices (pride, envy, sloth (laziness)) is in
> decline? *mild shock*; what we're facing here is the addition of gluttony.
>
> I mean, dzil.org's HTML starts with,
>
> <html>
> <head>
> <title>Dist::Zilla - Maximum Overkill for CPAN Authors</title>
> <link rel='stylesheet' type='text/css' href='style.css' />
> <meta name='viewport' content='width=device-width,initial-scale=1'>
> </head>
>
> > Maximum Overkill
>
> Maybe add anger? I am kidding of course, but this really sums it up. Do
> you want maximum overkill in fragile intersections of perl, critical
> modules, and a short list of developers willing to go there?
>
> Although, this does remind me of that 80s movie where the alien proble
> passes over the earth, and all machines turn on their humans. I hope
> that never happens to Perl <_< ... >_>
>
> >
> > I think the DZ community could pretty quickly turn this around if they
> > want. I was hoping that they would respond as I would have to my post "oh
> > shit, I didn't think of *that*, let's fix it".
> >
> > I guess my use of the historic term "x considered harmful" was counter
> > productive. I had expected the type of people who are on the p5p list to
> > know the history of that term which I believe goes back to Djikstra's paper
> > on goto from 1968.
>
> I appreciated it. There's also "no silver bullet" .. and look Perl has a C<goto>,
> and last time I checked is running low on silver bullets. xD
>
> >
> > The purpose of such statements is not to insult people who use the thing
> > considered harmful, nor necessarily to completely eliminate the thing
> > considered harmful but rather it is to encourage learning and innovation.
> > 55 years after that seminal paper we still have goto statements, but we
> > know that they should be used judiciously and usually in forms that make
> > them safe (loop operators, subroutine calls, etc).
> >
> > What I hope comes out of this thread is a recognition that the opaqueness
> > of the current DZ posture changes towards transparency. All it's got to do
> > is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
> > directory and over the following months I bet we'd start seeing those files
> > solve the transparency problem.
>
> If it counts, I agree with your point and you have a right say it. It's coming
> from a place of charity, and that is clear to me, at least. I hope some good
> will come from it, even if it's just documentation and to admit openly that I like
> Dist::Zilla like a fat kid likes cake.
>
> Cheers,
> Brett
>
> >
> > Sorry for the long post,
> >
> > Cheers
> > Yves
> > [1] whatever it's called. I didn't say README because cpan issues.
> >
> > >
>
> --
> --
> oodler@cpan.org
> oodler577@sdf-eu.org
> SDF-EU Public Access UNIX System - http://sdfeu.org
> irc.perl.org #openmp #pdl #native
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
I am not even that consistent about it; but I went back
using these tags:
- ran, "dzil build"
- deleted the tar.gz files
- moved all build directories into a ./releases directory
- committed these to the repo,
https://github.com/oodler577/p5-Util-H2O-More/tree/master/releases
And I hopefully will be consistent about doing this in the
future. I did this to demonstrate what I mean when I ask, would
something like this help for modules that actually matter far
upstream and also use Dist::Zilla? What I hope to show here is
potential value in keeping such artifacts around for recent
versions in the event someone needs to fix things. And I am
further hopeful that a module author/maintainer doing this is
an indication that they are willing to do the work necessary
to port changes made to "fix" the dist.ini file to ensure that
the fixes to artifact files persist.
Thoughts?
Brett
* Oodler 577 via perl5-porters <perl5-porters@perl.org> [2023-01-22 00:27:41 +0000]:
> * demerphq <demerphq@gmail.com> [2023-01-21 10:11:37 +0800]:
>
> > On Sat, 21 Jan 2023, 05:16 Christian Walde, <walde.christian@gmail.com>
> > wrote:
> >
> > > On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org>
> > > wrote:
> > >
> > > > I can imagine working on some forward
> > > > version of perl using a well tuned workflow, running into issues that
> > > > you can't build Dist::Zilla
> > >
> > > Maybe it's a language issue i am running into, not being a native speaker,
> > > but this seems to indicate to me you are indeed misunderstanding.
> > >
> > > As has been said multiple times now:
> > >
> > > Do not run dzil on your blead perl. There is no reason to think that is
> > > necessary at all.
> > >
> >
> > See that is part of the problem. You know that, I guess it's well known
> > amongst users. But how is someone how isn't a user supposed to know that?
> >
> <snip>
> >
> > The reason I think DZ is harmful to the Perl ecosystem is precise because
> > of this lack of transparency. Perl is already cryptic enough, having loads
> > of cpan related repos on github with no "readme" files or instructions etc
> > just makes it more likely that someone incidentally encountering them will
> > have no idea what to do with them get frustrated and go away thinking our
> > community is really backwards. People can disagree all they want with that
> > point of view, they can call it judgemental or think it's an insult. That
> > is ok, I'll just continue thinking they are in denial as our community
> > shrinks and withers away.
> >
> > I feel that our community is in a long slow decline. We don't attract new
> > devs. Many of the devs left seems more protective of their habits and
> > preferences and prerogatives than on ensuring our community grows. I love
> > perl, and I want to see it continue for many years to come and id like see
> > fresh faces get involved. that is why I continue hacking core and why I
> > focus on the parts I do. Bug fixes, stability, error handling, regex engine
> > (one of the few places where we still have a strong influence on the wider
> > computing community) etc.
> >
> > 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*.
>
> A community that "prides" it self in vices (pride, envy, sloth (laziness)) is in
> decline? *mild shock*; what we're facing here is the addition of gluttony.
>
> I mean, dzil.org's HTML starts with,
>
> <html>
> <head>
> <title>Dist::Zilla - Maximum Overkill for CPAN Authors</title>
> <link rel='stylesheet' type='text/css' href='style.css' />
> <meta name='viewport' content='width=device-width,initial-scale=1'>
> </head>
>
> > Maximum Overkill
>
> Maybe add anger? I am kidding of course, but this really sums it up. Do
> you want maximum overkill in fragile intersections of perl, critical
> modules, and a short list of developers willing to go there?
>
> Although, this does remind me of that 80s movie where the alien proble
> passes over the earth, and all machines turn on their humans. I hope
> that never happens to Perl <_< ... >_>
>
> >
> > I think the DZ community could pretty quickly turn this around if they
> > want. I was hoping that they would respond as I would have to my post "oh
> > shit, I didn't think of *that*, let's fix it".
> >
> > I guess my use of the historic term "x considered harmful" was counter
> > productive. I had expected the type of people who are on the p5p list to
> > know the history of that term which I believe goes back to Djikstra's paper
> > on goto from 1968.
>
> I appreciated it. There's also "no silver bullet" .. and look Perl has a C<goto>,
> and last time I checked is running low on silver bullets. xD
>
> >
> > The purpose of such statements is not to insult people who use the thing
> > considered harmful, nor necessarily to completely eliminate the thing
> > considered harmful but rather it is to encourage learning and innovation.
> > 55 years after that seminal paper we still have goto statements, but we
> > know that they should be used judiciously and usually in forms that make
> > them safe (loop operators, subroutine calls, etc).
> >
> > What I hope comes out of this thread is a recognition that the opaqueness
> > of the current DZ posture changes towards transparency. All it's got to do
> > is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
> > directory and over the following months I bet we'd start seeing those files
> > solve the transparency problem.
>
> If it counts, I agree with your point and you have a right say it. It's coming
> from a place of charity, and that is clear to me, at least. I hope some good
> will come from it, even if it's just documentation and to admit openly that I like
> Dist::Zilla like a fat kid likes cake.
>
> Cheers,
> Brett
>
> >
> > Sorry for the long post,
> >
> > Cheers
> > Yves
> > [1] whatever it's called. I didn't say README because cpan issues.
> >
> > >
>
> --
> --
> oodler@cpan.org
> oodler577@sdf-eu.org
> SDF-EU Public Access UNIX System - http://sdfeu.org
> irc.perl.org #openmp #pdl #native
--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native