in reply to Re^5: Looking for the maintainer of Sendmail::Milter.
in thread Looking for the maintainer of Sendmail::Milter.

Don't know if I'm using the comment facility in the way that's intended, please be gentle.

Yes, it's been a while since I started this ball rolling.

No luck at all with the (alleged) maintainer of Sendmail::Milter.

I've re-written Sendmail::PMilter so that it doesn't need Sendmail::Milter.

I've been exercising it for a while and it's Been Reliable For Me.

I'd now like to work on the packaging, so I can get anyone who's interested to try a TRIAL version, and I'm looking at
https://www.cpan.org/modules/04pause.html#before

It's recommended there for newbies like me to use PrePAN, but unfortunately PrePAN wants me to log in using Twitter or Github.

I neither have nor want accounts on Twitter and Github.

Can anyone suggest alternatives?

Thanks.

  • Comment on Re^6: Looking for the maintainer of Sendmail::Milter.

Replies are listed 'Best First'.
Re^7: Looking for the maintainer of Sendmail::Milter.
by Arunbear (Prior) on Jul 04, 2019 at 15:52 UTC
    You could upload it to CPAN as a developer release (a mechanism designed for scenarios just like yours).
      Thanks for the replies. There are enhancements to the API, but it's basically the same API so I think it's going to be a developer release. That sounds right.

      The documentation isn't clear to me. For a developer release, do I need to do something with the $VERSION scalar in the .pm files themselves to make PAUSE recognize that it's a developer release, or will it be sufficient to name the uploaded tarball "sendmail-pmilter-1.21-TRIAL3.tar.gz" while in the two .pm files which it contains will be

      our $VERSION = '1.21';

      the intention being to leave $VERSION at that value after any fixes to the developer release are completed?

        I can see many disadvantages of having two releases of a module with different content and the same $VERSION value so I would never do that.

        Historically, Sendmail::PMilter has used the traditional X.XX_XX form for dev releases of the dist. Unless you have a tangibly good reason to stop that practice why not stick with it?

        Personally, I'd keep the $VERSION in the module and the version number of the dist in perfect sync as that way there can be no confusion.

        As recommended here I released the new module as sendmail-pmilter-1.20_01 and the testing bots seem to be happy with it so far.

        Almost by chance I saw that it's recommended to have a CONTRIBUTING file.

        The testing bots don't seem to have mentioned that I didn't have one, but I made one and now there's a 1.20_02 version in the works.

        I say 'almost' by chance because I was looking for help with quality.

        I'm sort of a fan of quality, in the sense of Title21, Chapter1, s820 or ISO9000 - both of which I've worked to.

        The closest I've got so far is a link on https://metacpan.org/release/Sendmail-PMilter labelled 'Kwalitee'. This links to a page which shows that a bot has done some useful checks on V1.00 of the module, but I don't see a way to get those checks dome on the development version.

        Am I looking in the wrong place?

        In https://www.cpan.org/modules/04pause.html there's mention of the QA mailing list (perl-qa-help@perl.org) so I checked the archives.

        Three posts in the last two years.

        I'm looking for help with bringing the content of Sendmail::PMilter-1.2x up to scratch - when I can find a definition of 'scratch'.

        Where else should I be looking?

Re^7: Looking for the maintainer of Sendmail::Milter.
by hippo (Archbishop) on Jul 04, 2019 at 21:36 UTC
    Can anyone suggest alternatives?

    If the user interface of Sendmail::PMilter is unchanged then I don't see that it needs to go to PrePAN anyway. All you will have done is changed how it performs its tasks internally which is something the module users won't care about. In which case, I agree with Arunbear and you should just roll a dev release.