FAQ

Time for a new Module::Build release manager

David Golden
Mar 5, 2011 at 8:46 pm
Looking at BackPAN, my first Module::Build release was 0.33_01 in
June, 2009. Here are some highlights of what has happened since then:

* Over 60 Module::Build tarballs -- most of them development
releases, admittedly
* Converted the Module::Build from Subversion to Git, attracting a
half-dozen or so new contributors
* Rigorous triage of the M::B RT queue -- every ticket was reviewed
to set the right severity and status
* About 70 RT tickets noted in Changes
* Updated release documentation and blead patching documentation

Since then, my own use of Module::Build has declined, as much of my
need for it as an author has been replaced by Dist::Zilla toolkit. At
the same time, I've taken on additional responsibilities with P5P,
CPAN PAUSE administration, and other parts of the toolchain.

Therefore, with the release of 0.3800, I am retiring as Module::Build
release manager. I will continue to contribute occasional patches,
particularly relating to any bugs uncovered in the new CPAN Meta Spec
v2 support added in 0.3800, but do not plan to release any more
tarballs to CPAN, short of a major flaw in 0.3800 requiring an
emergency fix.

I encourage interested parties to speak up and volunteer to take on
the release manager role.

Regards,
David Golden
reply

Search Discussions

13 responses

  • Leon Timmermans at Mar 7, 2011 at 12:06 pm

    On Sat, Mar 5, 2011 at 9:43 PM, David Golden wrote:
    Since then, my own use of Module::Build has declined, as much of my
    need for it as an author has been replaced by Dist::Zilla toolkit.  At
    the same time, I've taken on additional responsibilities with P5P,
    CPAN PAUSE administration, and other parts of the toolchain.

    Therefore, with the release of 0.3800, I am retiring as Module::Build
    release manager.  I will continue to contribute occasional patches,
    particularly relating to any bugs uncovered in the new CPAN Meta Spec
    v2 support added in 0.3800, but do not plan to release any more
    tarballs to CPAN, short of a major flaw in 0.3800 requiring an
    emergency fix.

    I encourage interested parties to speak up and volunteer to take on
    the release manager role.
    I'm not particularly interested in improving Module::Build. I am very
    much interested in cannibalizing pieces of its code to make them
    reusable for the second generation of Build.PL builders, which will
    hopefully obsolete Module::Build in the future. Depending on your
    point of view this would make me either the worst or best possible
    candidate to manage Module::Build. In either case I do not think I
    would be doing it for more than just a handful of releases though.

    Leon
  • John M. Gamble at Mar 7, 2011 at 7:34 pm

    On 3/7/2011 6:06 AM, Leon Timmermans wrote:
    On Sat, Mar 5, 2011 at 9:43 PM, David Goldenwrote:
    Since then, my own use of Module::Build has declined, as much of my
    need for it as an author has been replaced by Dist::Zilla toolkit. At
    the same time, I've taken on additional responsibilities with P5P,
    CPAN PAUSE administration, and other parts of the toolchain.

    Therefore, with the release of 0.3800, I am retiring as Module::Build
    release manager. I will continue to contribute occasional patches,
    particularly relating to any bugs uncovered in the new CPAN Meta Spec
    v2 support added in 0.3800, but do not plan to release any more
    tarballs to CPAN, short of a major flaw in 0.3800 requiring an
    emergency fix.

    I encourage interested parties to speak up and volunteer to take on
    the release manager role.
    I'm not particularly interested in improving Module::Build. I am very
    much interested in cannibalizing pieces of its code to make them
    reusable for the second generation of Build.PL builders, which will
    hopefully obsolete Module::Build in the future. Depending on your
    point of view this would make me either the worst or best possible
    candidate to manage Module::Build. In either case I do not think I
    would be doing it for more than just a handful of releases though.

    Leon
    Well ... this raises a question. Whither Module::Build?

    Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
    up as a Dist::Zilla::Simple?

    I'm on this list because once I found out about Module::Build, I transferred
    my modules over to it as fast as my little fingers could edit them, and I
    wanted to learn more as it developed. I like it, it was and is a much easier
    system to use, and if it doesn't have an independent future I'd like to see
    it become a bridge to an even easier system, not simply broken apart.

    -john
  • Alberto Simões at Mar 7, 2011 at 7:35 pm

    On 07/03/2011 19:34, John M. Gamble wrote:
    On 3/7/2011 6:06 AM, Leon Timmermans wrote:
    On Sat, Mar 5, 2011 at 9:43 PM, David Goldenwrote:
    Since then, my own use of Module::Build has declined, as much of my
    need for it as an author has been replaced by Dist::Zilla toolkit. At
    the same time, I've taken on additional responsibilities with P5P,
    CPAN PAUSE administration, and other parts of the toolchain.

    Therefore, with the release of 0.3800, I am retiring as Module::Build
    release manager. I will continue to contribute occasional patches,
    particularly relating to any bugs uncovered in the new CPAN Meta Spec
    v2 support added in 0.3800, but do not plan to release any more
    tarballs to CPAN, short of a major flaw in 0.3800 requiring an
    emergency fix.

    I encourage interested parties to speak up and volunteer to take on
    the release manager role.
    I'm not particularly interested in improving Module::Build. I am very
    much interested in cannibalizing pieces of its code to make them
    reusable for the second generation of Build.PL builders, which will
    hopefully obsolete Module::Build in the future. Depending on your
    point of view this would make me either the worst or best possible
    candidate to manage Module::Build. In either case I do not think I
    would be doing it for more than just a handful of releases though.

    Leon
    Well ... this raises a question. Whither Module::Build?

    Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
    up as a Dist::Zilla::Simple?
    AFAIK Dist::Zilla is NOT a substitute to Module::Build (or
    ExtUtils::MakeMaker).

    --
    Alberto Simoes
    CCTC-UM / CEHUM
  • David Golden at Mar 7, 2011 at 7:44 pm

    2011/3/7 Alberto Simões <albie@alfarrabio.di.uminho.pt>:
    On 07/03/2011 19:34, John M. Gamble wrote:
    Well ... this raises a question. Whither Module::Build?

    Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
    up as a Dist::Zilla::Simple?
    AFAIK Dist::Zilla is NOT a substitute to Module::Build (or
    ExtUtils::MakeMaker).
    That's correct. Dist::Zilla is a distribution packaging tool only.
    It *can* create a Makefile.PL or Build.PL for you (and most
    Dist::Zilla authors seem to do that) but your distribution still
    relies on EU::MM or M::B for the configure/make/test/install cycle for
    end-users.

    I wrote a little about which tools I think people should use here:
    http://www.dagolden.com/index.php/1173/what-tools-should-you-use-to-create-a-cpan-distribution/

    I think M::B still has a role for customized distribution needs.

    -- David
  • Marvin Humphrey at Mar 7, 2011 at 8:11 pm

    On Mon, Mar 07, 2011 at 01:34:04PM -0600, John M. Gamble wrote:
    Well ... this raises a question. Whither Module::Build?
    How about maintenance mode? Does Module::Build really need to be aggressively
    developed?

    Module::Build provides a fantastic improvement over MakeMaker: it allows us to
    write build actions in pure Perl. And it has matured into a build system with
    a lot of nice features.

    M::B wasn't core and had some bugs at first, so I could understand when people
    got impatient over it back in 2006. But it's been distributed with core Perl
    for years now and it's pretty darn stable.

    In a quick glance at Dist::Zilla, I see that it does stuff like incorporate
    POD::Weaver so that they can write their docs in a new language that extends
    POD - <http://dzil.org/tutorial/writing-docs.html>. That's cool, and I love
    to see people pushing the envelope, but it's not a feature I'd want to
    use. I just want to write my elaborate build scripts in Perl rather than
    Make.

    If nobody steps up and wants to maintain M::B within the confines of its
    current API, does it make sense to declare victory and remove it from
    dual-life status?

    Marvin Humphrey
  • Nicholas Clark at Mar 14, 2011 at 1:38 pm

    On Mon, Mar 07, 2011 at 12:10:26PM -0800, Marvin Humphrey wrote:
    On Mon, Mar 07, 2011 at 01:34:04PM -0600, John M. Gamble wrote:
    Well ... this raises a question. Whither Module::Build?
    How about maintenance mode? Does Module::Build really need to be aggressively
    developed?

    Module::Build provides a fantastic improvement over MakeMaker: it allows us to
    write build actions in pure Perl. And it has matured into a build system with
    a lot of nice features.

    M::B wasn't core and had some bugs at first, so I could understand when people
    got impatient over it back in 2006. But it's been distributed with core Perl
    for years now and it's pretty darn stable.

    In a quick glance at Dist::Zilla, I see that it does stuff like incorporate
    POD::Weaver so that they can write their docs in a new language that extends
    POD - <http://dzil.org/tutorial/writing-docs.html>. That's cool, and I love
    to see people pushing the envelope, but it's not a feature I'd want to
    use. I just want to write my elaborate build scripts in Perl rather than
    Make.

    If nobody steps up and wants to maintain M::B within the confines of its
    current API, does it make sense to declare victory and remove it from
    dual-life status?
    I don't think I'd use the word "victory" for that.

    "remove it from dual-life status is ambiguous"

    We've now got the core perl laid out in git such that

    modules in cpan/ are dual life, and the master repository is somewhere else
    generally we're not tracking that repository. We're merging CPAN releases
    modules in dist/ are dual life, the core git repository is master, but someone
    is prepared to (and does) make release of them to CPAN, which will (to some
    degree) support earlier versions of perl
    modules in ext/ are only shipped with the core perl


    A side effect of being in ext/ is that you can only upgrade a module there
    by upgrading your entire perl.


    Now, if no-one wants to volunteer to actually make CPAN releases of
    Module::Build, then

    a: in the short term cpan/Module-Build is going to be 100% stable
    b: in the medium term, if upstream is dead, and there are bugs to be fixed,
    it will be moved to signify that the perl core is upstream

    If *no-one* wants to volunteer to make the CPAN releases, then logically it
    will be moved to ext/

    At which point, if you hit a bug in Module::Build, your next fix comes by
    upgrading perl.


    I'm sure this is going to make some people scream.

    Sorry folks, that's how it is.

    Volunteer, find someone to volunteer, pay someone to "volunteer", or shut up.

    Nicholas Clark
  • Christopher J. Madsen at Mar 8, 2011 at 1:56 am

    On 3/7/2011 1:34 PM, John M. Gamble wrote:
    Well ... this raises a question. Whither Module::Build?

    Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
    up as a Dist::Zilla::Simple?
    First, a little background. The makefile created by ExtUtils::MakeMaker
    contains a number of targets that can be classified into 2 categories.
    First, there are the ones used by people installing modules from CPAN:
    primarily "make && make test && make install". We can call this the
    "installing" role.

    Second, there are the targets used only by people writing modules, like
    "make dist", "make manifest", generating META.yml (and now META.json).
    We can call this the "authoring" role.

    When Module::Build was conceived as a pure-Perl MakeMaker replacement,
    it also implemented both roles. But if you think about it, there's no
    particular reason that the same tool has to fill both roles, and good
    reasons why there should be a separate tool for each role.

    A tool implementing the "installing" role has to have minimal
    requirements, because they'll have to be installed on every system that
    uses a module that uses that installer. It needs to be able to run on
    pretty much every system that can run Perl, including systems that only
    have older versions of Perl. It needs to be as bulletproof as possible,
    because it'll be used by people who are just starting to learn Perl.

    An "authoring" tool, on the other hand, will only be used by people who
    are writing modules. As a result, it can assume a greater familiarity
    with Perl. It can have heavy prerequisites, like Moose, which makes it
    easier to implement more complex features, like rewriting POD, version
    control integration, uploading to CPAN, etc.

    Dist::Zilla is the first attempt to separate the authoring role from the
    installing role that's achieved significant traction. As such, it will
    never replace the "installing" side of MakeMaker or MB. There's been
    some talk about an "Install::Zilla" to implement the installing role,
    but AFAIK nobody's started working on that yet.


    I'd like to see MB work towards separating the two roles internally,
    with the goal of developing an install-only tool. Here's a possible
    scenario:

    Module-Installer would be a new dist containing the "installing" parts
    of MB. Ideally, you could convert a Build.PL to use Module::Installer
    by just doing s/Module::Build/Module::Installer/g.

    Module-Build would become a legacy dist containing the "authoring" parts
    of MB for backwards compatibility. It would depend on
    Module::Installer; Module::Build would become just an empty subclass of
    Module::Installer.

    If people want to continue developing the authoring side of MB, it could
    become a third distribution, say Dist-Builder. The reason for a new
    dist would be to allow it to gain prerequisites without influencing
    modules that are depending on MB for its installing role.

    --
    Chris Madsen perl@cjmweb.net
    -------------------- http://www.cjmweb.net --------------------
  • Adam Kennedy at Mar 9, 2011 at 5:15 am

    On 8 March 2011 12:56, Christopher J. Madsen wrote:
    Dist::Zilla is the first attempt to separate the authoring role from the
    installing role that's achieved significant traction.  As such, it will
    never replace the "installing" side of MakeMaker or MB.  There's been
    some talk about an "Install::Zilla" to implement the installing role,
    but AFAIK nobody's started working on that yet.

    *AHEM* Module::Install *COUGH*

    While M:I may be about 30% evil, it does essentially the same thing,
    detaching a small subset of itself (the non-Admin classes) and
    bundling them as the ::Installer half of itself.

    You're in crufty I-Didn't-Write-This-Stuff-I-Just-Maintain-It'ship

    Adam K
  • Christopher J. Madsen at Mar 9, 2011 at 8:09 pm

    On 3/8/2011 11:15 PM, Adam Kennedy wrote:
    On 8 March 2011 12:56, Christopher J. Madsen wrote:
    Dist::Zilla is the first attempt to separate the authoring role from the
    installing role that's achieved significant traction. As such, it will
    never replace the "installing" side of MakeMaker or MB. There's been
    some talk about an "Install::Zilla" to implement the installing role,
    but AFAIK nobody's started working on that yet.

    *AHEM* Module::Install *COUGH*

    While M:I may be about 30% evil, it does essentially the same thing,
    detaching a small subset of itself (the non-Admin classes) and
    bundling them as the ::Installer half of itself.

    You're in crufty I-Didn't-Write-This-Stuff-I-Just-Maintain-It'ship
    I don't think I understand your point. I've never used Module::Install,
    but I thought it was basically just a wrapper around MakeMaker.

    By "Install::Zilla" I mean a Module::Build-like tool, but one that has
    no support for the authoring role. It wouldn't bundle itself into
    dists; it would just use configure_requires along with a Build.PL that
    said "use Install::Zilla" instead of "use Module::Build". It wouldn't
    be tightly coupled to Dist::Zilla.


    I've thought of another way to split Module::Build into separate dists
    for installing and authoring that may work better than my first proposal.

    Module-Build would become the installer-only dist. The authoring-type
    actions would be replaced with stubs that tried to load
    Module::Build::Authoring and redispatch to that. If
    Module::Build::Authoring was not installed, the stub would print a
    message saying that you need to install it from CPAN in order to run
    that command.

    --
    Chris Madsen perl@cjmweb.net
    -------------------- http://www.cjmweb.net --------------------
  • Adam Kennedy at Mar 9, 2011 at 11:56 pm
    Module::Install is two separate wrappers around ExtUtils::MakeMaker,
    an install-time only wrapper and an author-time only wrapper.

    It just happens that as an author installing Module::Install you get
    both layers installed, and the two layers switch intelligently so that
    the same "requires" command could dispatch to two different functions
    for installers and authors.

    Adam K
    On 10 March 2011 07:09, Christopher J. Madsen wrote:
    On 3/8/2011 11:15 PM, Adam Kennedy wrote:
    On 8 March 2011 12:56, Christopher J. Madsen wrote:
    Dist::Zilla is the first attempt to separate the authoring role from the
    installing role that's achieved significant traction.  As such, it will
    never replace the "installing" side of MakeMaker or MB.  There's been
    some talk about an "Install::Zilla" to implement the installing role,
    but AFAIK nobody's started working on that yet.

    *AHEM* Module::Install *COUGH*

    While M:I may be about 30% evil, it does essentially the same thing,
    detaching a small subset of itself (the non-Admin classes) and
    bundling them as the ::Installer half of itself.

    You're in crufty I-Didn't-Write-This-Stuff-I-Just-Maintain-It'ship
    I don't think I understand your point.  I've never used Module::Install,
    but I thought it was basically just a wrapper around MakeMaker.

    By "Install::Zilla" I mean a Module::Build-like tool, but one that has
    no support for the authoring role.  It wouldn't bundle itself into
    dists; it would just use configure_requires along with a Build.PL that
    said "use Install::Zilla" instead of "use Module::Build".  It wouldn't
    be tightly coupled to Dist::Zilla.


    I've thought of another way to split Module::Build into separate dists
    for installing and authoring that may work better than my first proposal.

    Module-Build would become the installer-only dist.  The authoring-type
    actions would be replaced with stubs that tried to load
    Module::Build::Authoring and redispatch to that.  If
    Module::Build::Authoring was not installed, the stub would print a
    message saying that you need to install it from CPAN in order to run
    that command.

    --
    Chris Madsen                                          perl@cjmweb.net
    --------------------  http://www.cjmweb.net  --------------------
  • Leon Timmermans at Mar 10, 2011 at 12:46 am

    On Wed, Mar 9, 2011 at 9:09 PM, Christopher J. Madsen wrote:
    By "Install::Zilla" I mean a Module::Build-like tool, but one that has
    no support for the authoring role.  It wouldn't bundle itself into
    dists; it would just use configure_requires along with a Build.PL that
    said "use Install::Zilla" instead of "use Module::Build".  It wouldn't
    be tightly coupled to Dist::Zilla.
    See http://blogs.perl.org/users/leon_timmermans/2011/03/le-roi-est-mort-vive-le-roi.html
    for my ideas on that. Actually writing that module builder is not my
    first or most important goal (though it will be the one most visible
    to end-users). My primary goal is to make writing a module builder
    easy (or at least a lot easier than it is now). Currently there is a
    fairly large amount of accidental complexity in writing a Build.PL
    implementation. Those problems should have modules solving them,
    preferably refactored from well-tested Module::Build code.

    Leon
  • Adam Kennedy at Mar 9, 2011 at 11:54 pm
    Module::Build, like ExtUtils::MakeMaker and Module::Install, were
    written for a world where you don't have configure-time dependencies.
    Thus the trend to large and involved single packages with everything
    included, just as things like CGI.pm were before it in the days when
    we didn't have any dependencies at all.

    Once a CPAN with configure_requires becomes the toolchain
    back-compatibility target the age of the large self-contained build
    system will come to an end, and you'll see a trend to more diverse,
    dynamic and componentised build systems.

    This is largely inevitable, and Leon just represents the leading edge
    of this change.

    Adam K


    On 8 March 2011 06:34, John M. Gamble wrote:
    On 3/7/2011 6:06 AM, Leon Timmermans wrote:

    On Sat, Mar 5, 2011 at 9:43 PM, David Goldenwrote:
    Since then, my own use of Module::Build has declined, as much of my
    need for it as an author has been replaced by Dist::Zilla toolkit.  At
    the same time, I've taken on additional responsibilities with P5P,
    CPAN PAUSE administration, and other parts of the toolchain.

    Therefore, with the release of 0.3800, I am retiring as Module::Build
    release manager.  I will continue to contribute occasional patches,
    particularly relating to any bugs uncovered in the new CPAN Meta Spec
    v2 support added in 0.3800, but do not plan to release any more
    tarballs to CPAN, short of a major flaw in 0.3800 requiring an
    emergency fix.

    I encourage interested parties to speak up and volunteer to take on
    the release manager role.
    I'm not particularly interested in improving Module::Build. I am very
    much interested in cannibalizing pieces of its code to make them
    reusable for the second generation of Build.PL builders, which will
    hopefully obsolete Module::Build in the future. Depending on your
    point of view this would make me either the worst or best possible
    candidate to manage Module::Build. In either case I do not think I
    would be doing it for more than just a handful of releases though.

    Leon
    Well ... this raises a question. Whither Module::Build?

    Is its future simply to be the precursor to Dist::Zilla? Or to be wrapped
    up as a Dist::Zilla::Simple?

    I'm on this list because once I found out about Module::Build, I transferred
    my modules over to it as fast as my little fingers could edit them, and I
    wanted to learn more as it developed. I like it, it was and is a much easier
    system to use, and if it doesn't have an independent future I'd like to see
    it become a bridge to an even easier system, not simply broken apart.

    -john
  • Jonas B. Nielsen at Mar 7, 2011 at 9:15 pm
    Hi David,

    Your work and contributions have been and are much appreciated. It will most certainly be a challenge to live up to you and your tireless efforts and they will be missed. I am however very happy to hear than you will continue your work in other parts of the Perl toolchain.

    Thank you! from a long time Module::Build user,

    jonasbn
    On 05/03/2011, at 21.43, David Golden wrote:

    Looking at BackPAN, my first Module::Build release was 0.33_01 in
    June, 2009. Here are some highlights of what has happened since then:

    * Over 60 Module::Build tarballs -- most of them development
    releases, admittedly
    * Converted the Module::Build from Subversion to Git, attracting a
    half-dozen or so new contributors
    * Rigorous triage of the M::B RT queue -- every ticket was reviewed
    to set the right severity and status
    * About 70 RT tickets noted in Changes
    * Updated release documentation and blead patching documentation

    Since then, my own use of Module::Build has declined, as much of my
    need for it as an author has been replaced by Dist::Zilla toolkit. At
    the same time, I've taken on additional responsibilities with P5P,
    CPAN PAUSE administration, and other parts of the toolchain.

    Therefore, with the release of 0.3800, I am retiring as Module::Build
    release manager. I will continue to contribute occasional patches,
    particularly relating to any bugs uncovered in the new CPAN Meta Spec
    v2 support added in 0.3800, but do not plan to release any more
    tarballs to CPAN, short of a major flaw in 0.3800 requiring an
    emergency fix.

    I encourage interested parties to speak up and volunteer to take on
    the release manager role.

    Regards,
    David Golden

Related Discussions