FAQ
I'm highlighting this for the full list to be aware of and contribute to.
---------- Forwarded message ----------
From: "bulk88" <notifications@github.com>
Date: Oct 28, 2015 6:27 PM
Subject: [ExtUtils-MakeMaker] the future of EUMM's development model (#242)
To: "Perl-Toolchain-Gang/ExtUtils-MakeMaker" <
extutils-makemaker@noreply.github.com>
Cc:

Mohawk did a whole bunch of changes in 7.05 and 7.06, these changes were
deemed by the owner of EUMM, bingos, to be not releasable as stable on
CPAN, and all of them were reverted by bingos. Regardless of what the
public said in #236
<https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/236> ,
bingos and his appointed PAUSE comaints are under no obligation to listen
to the public and once they accept and publish a random member of the
public's opinion/work, they are responsible for it. This resulted in 7.08
and 7.10 branches being released that are much older than master branch.
Mohawk's activity in EUMM has slowed to none over the last couple months.

So my questions are, which branch am I and the rest of the community
supposed to fork and contribute to? 7.10 branch or master?

When will the mohawk 7.07 work be shipped to cpan?

I want an exact date. The P5P code freeze is less than 3 months away. Since
this is open source software and everyone is a volunteer, failure to
provide an answer automatically means never (see lwpng project) since
nobody will spend the hours needed to resolve whatever keeps 7.07 from
being shipped to cpan. If EUMM has been abandoned, I will plan accordingly
around that situation.

7.08 and 7.10 are git forks of master branch from Dec 2014.

How will this divergence be handled git wise? Will 7.07 be rebased ontop of
7.10 and master reset and force pushed to "7.07 on 7.10" branch or will
7.08 and 7.10 branches be deleted from the repo and 7.07 will jump to 7.12
without 7.08 and 7.10 ever existing in master branch?

Since P5P perl relies on timely releases of EUMM, there are certain
exceptions and responsibilities for planning and managing a project
correctly. If the owners of EUMM can not meet those expectations, a new
management structure and plan must be figured out for EUMM. If anyone with
official power (PAUSE) over EUMM responds with "by Christmas", they are
sanctioning a fork. I'll warn everyone ahead of time, think a little as to
what you are really saying before you respond with the mantra "we have no
time, we aren't paid".

While I will obviously read responses of everyone who posts, responses from
the general public (no PAUSE EUMM rights), aren't statements from the owner
of EUMM (bingos) and his appointed comaints
ANDK/CHORNY/ETHER/LEONT/MMML/MSCHWERN/MSTROUT.


Reply to this email directly or view it on GitHub
<https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/242>.

Search Discussions

  • Bulk88 at Oct 29, 2015 at 10:14 pm

    David Golden wrote:
    I'm highlighting this for the full list to be aware of and contribute to. >
    ---------- Forwarded message ----------
    From: "bulk88" <notifications@github.com
       Date: Oct 28, 2015 6:27 PM
    Subject: [ExtUtils-MakeMaker] the future of EUMM's development model (#242)
    To: "Perl-Toolchain-Gang/ExtUtils-MakeMaker"
    <extutils-makemaker@noreply.github.com
    Cc:
      >
    ***************CUT****************
    Since P5P perl relies on timely releases of EUMM, there are certain
    exceptions and responsibilities for planning and managing a project
    correctly. If the owners of EUMM can not meet those expectations, a new
    management structure and plan must be figured out for EUMM. If anyone
    with official power (PAUSE) over EUMM responds with "by Christmas", they
    are sanctioning a fork. I'll warn everyone ahead of time, think a little
    as to what you are really saying before you respond with the mantra "we
    have no time, we aren't paid". >
    While I will obviously read responses of everyone who posts, responses
    from the general public (no PAUSE EUMM rights), aren't statements from
    the owner of EUMM (bingos) and his appointed comaints
    ANDK/CHORNY/ETHER/LEONT/MMML/MSCHWERN/MSTROUT. >

    Reply to this email directly or view it on GitHub
    <https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/242>.
      >

    I'll add some more details and expand outside of EUMM specfically, in
    https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md#toolchain-charter-practices

    it says
    ------------------------------------------------------------
    2. Toolchain distributions should have more than one "primary"
    maintainer (regardless of actual PAUSE permissions) and a list should be
    published showing distributions and maintainers.
    ------------------------------------------------------------
    5. If discussions about the evolution of toolchain distributions fail to
    achieve consensus, toolchain authors agree to defer to a designated
    "tie-breaker" authority. The Perl pumpking (regardless of who that may
    be at any point in time) was the initial choice for tie-breaker.
    ------------------------------------------------------------

    There are THIRTY people in
    https://github.com/orgs/Perl-Toolchain-Gang/people .

    So here are my questions.

    Where is the list described in #2 for Perl-Toolchain-Gang controlled
    modules?

    Do all 30 people listed in PTG have the same perms and standing in PTG?

    Are all 30 people free to push to all ~27 PTG repos at any time?
    Technically free or socially free?

    Who has the root password to the PTG github account to add and remove
    members from that list? I'll assume there is more than 1 person.

    BINGOS does many CPAN releases for PTG modules for a number of years now
    but he rarely writes code. In PAUSE, there is a concept of owner, and
    comaint. Do these have relevance to who is the owner of a PTG module? I
    find any "Author" section in PTG module pod to be years or a decade out
    of date. Is the Pod's author the "owner" of the module and still
    responsible for it even though it is under PTG care?

    If a PTG module is always released by one person, and nearly every
    commit is by one person, page after page on GH, year after year, XDG's
    modules for example, it is obvious that he, and not the PTG collective
    is the owner of that.

    But for ExtUtils::MakeMaker, Bingos does all the CPAN releases and is
    the owner on PAUSE, but less than half of the commits, and less than
    1/8th of the commits if you exclude merge commits and version bumps. Who
    is the owner of ExtUtils::MakeMaker? Bingos alone? or all 30 members of
    PTG are jointly and severally liable? I'll expand on this later.

    Back to who is the owner, should the Author sections in PTG pod be
    changed to "Creator" or "Original Author" or the section deleted and the
    original author mentioned as the 1st line in in the pod's Contributors
    section?

    When a module is "donated" to PTG, is the donator still the owner of the
    module, or is PTG collectively now the owner and author of the module,
    and original owner can not be blamed for anything that happens under PTG
    development model?

    Who gets a free ride to the police station when a rootkit that calls
    home was shipped to CPAN in a PTG tarball?

    Now the chances of a rootkit shipping under PTG development is very low,
    short of stolen passwords, since PTG members know each other offline and
    there will be a camel stomping if someone does that if they are ever
    found offline. If the rootkit appears in the CPAN tarball and never in
    the PTG repo, it is obvious who to blame based on PAUSE ID, but for more
    complicated cases,

    The PTG member with a commit bit who pushed the rootkit to the PTG git
    repo responsible?

    Is the PTG member who published the tarball on CPAN (negligent to review
    the git log before making a tarball)?

    What are the responsibilities of a PTG member who cuts a CPAN tarball?
    Are they a cron job whose only purpose is to bump version numbers and
    verify the changelog contains a new version number, or are they required
    to review the git history (and perhaps GH issues/PRs) since the last
    CPAN release?

    ------------------------------------------------------------
    5. If discussions about the evolution of toolchain distributions fail to
    achieve consensus, toolchain authors agree to defer to a designated
    "tie-breaker" authority. The Perl pumpking (regardless of who that may
    be at any point in time) was the initial choice for tie-breaker.
    ------------------------------------------------------------

    Bullet #5 says RJBS is the "tie breaker". I dont personally think that
    sentence is the same as owner, but someone can interpret that sentence
    as meaning RJBS is the final say on PTG, and therefore the owner of PTG.

    I looked through a number of PTG module's PAUSE perms lists, local::lib
    stood out. PTG's local::lib has 26 comaints on PAUSE.

    userid: MSTROUT
    userid: APEIRON
    userid: ARCANEZ
    userid: ASH
    userid: BOBTFISH
    userid: DGL
    userid: DOY
    userid: EDENC
    userid: ELLIOTT
    userid: ETHER
    userid: FLORA
    userid: FREW
    userid: GETTY
    userid: GRODITI
    userid: HAARG
    userid: ILMARI
    userid: JBERGER
    userid: JJNAPIORK
    userid: LSAUNDERS
    userid: MITHALDU
    userid: PERIGRIN
    userid: PHAYLON
    userid: RIBASUSHI
    userid: SSCAFFIDI
    userid: VANSTYN
    userid: WSHELDAHL


    I understand if a module needs redundancy in maintainers, or for
    emergency releases, but at a certain point, when the COMAINT list full
    of people who haven't been active in the perl community in years, or are
    active in perl community, but never write open source code, I start to
    wonder about attack vectors. local::lib's perms list has many people not
    in https://github.com/orgs/Perl-Toolchain-Gang/people . What is going on
    with this module?

    There is a PAUSE ID called MMML
    http://www.nntp.perl.org/group/perl.modules/2000/10/msg3190.html A
    number of PTG modules have this in PAUSE, but not all. Who is MMML? What
    is the purpose of this account?

    After MST in his official administrator powers decided that no tough
    questions are allowed about EUMM,
    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/242
    ----------------------------------------------------------
    shadowcat-mst commented 7 hours ago

    I'm taking responsibility only for shutting this conversation down until
    it can be restarted with a more constructive and less combative attitude.
    ----------------------------------------------------------

    I will post the chatlog with mst from #toolchain.

    [19:37] <@mst> issue cleared and closed.
    [19:39] <@mst> leont: I hate github. you just replied to something I'd
    already deleted.
    [19:41] <@leont> I hate all bug-trackers, and have no illusion about
    hating whatever I could come up with myself too.
    [19:41] <@mst> of course.
    [19:41] <@leont> From recent experience I can tell you github is still
    better than gitlab :-/
    [19:46] * @mst notes that apparently closing wasn't sufficient, clicks
    the lock button
    ***cut***
    [19:54] <@mst> bulk88: if you want to find mohawk and ask him when he's
    going to fix the mess he caused, that would be helpful. otherwise I
    guess we need a volunteer to back it out fully and restore master to
    before the mess.
    [19:55] <@haarg> afaik everything has basically been fixed except for
    the _eumm thing
    [19:57] <bulk88> someone gave mohawk permission to do his extensive
    refactoring, and someone reviewed all his work, dont blame mohawk alone
    for the development stall
    [19:58] <@mst> we argued extensively against the changes being done the
    way they did and he insisted on it anyway
    [19:58] <@mst> ignoring about 98% of the advice given by the channel
    [19:58] <@haarg> development hasn't even stalled really
    [19:59] <@mst> hence why I edited out the conspiracy theory laden screed
    that started the issue on github
    [19:59] <@mst> I am only disappointed there's no 'tinfoil hat' badge
    [20:00] <@haarg> maybe try filing an issue/PR about the change you want
    before complaining that it isn't being done
    [20:05] <@mst> 23:53 -!- Irssi: Starting query in perl with bulk88
    [20:05] <@mst> 23:53 <bulk88> you realize trying to censor that
    development stopped on EUM
    [20:05] <@mst> isn't going to work out very well for you?
    [20:05] <@mst> bulk88: lol.
    [20:05] <bulk88> someone gave mohawk a commit bit, whether it is PTG in
    a vote, or Bingos personally doesn't matter that (and maybe it is a
    private discussion I dont need to know), but each piece of software has
    an author, and that author is responsible for progress of the project,
    if they can't continue progress on the project, they need to step aside,
    or the software must be forked
    [20:05] <@mst> (1) what haarg said (2) adjust your attitude
    [20:06] <@mst> throwing random accusations around when you don't even
    have an outstanding PR/issue that isn't being addressed is unconstructive
    [20:07] <@mst> and wouldn't meet the standards for normal PAUSE adoption
    given a vanished maintainer
    [20:07] <@mst> let alone a dist where the team is still active and
    specifically asking you for an actual problem
    [20:08] <bulk88> why should I submit PRs on a branch that may take
    months or a year or 2, or never before it is published? Blead has a code
    freeze in Jan 2016, after that, I am blocked for 6-7 months from doing
    veyr much.
    [20:08] <bulk88> I asked specifically, should I be PRing the 7.10 branch?
    [20:08] <@mst> so your complaint is "I have assumed my PR won't be
    applied, therefore I haven't submitted it, therefore development has
    stopped"
    [20:08] <@mst> awesome
    [20:08] <@mst> that makes *perfect* sense, clearly :P
    [20:08] <bulk88> mst are you going to roll a release on CPAN if I ask
    you to?
    [20:09] <@mst> highly unlikely given the fact that you're doing more
    dickwaving than contributing.
    [20:09] <@mst> how about you file an issue describing that you believe
    should be changed with a rough plan of how you'd change it, and then we
    can figure out where the PR should go from there?
    [20:09] <@mst> I mean, that would actually be constructive, no?
    [20:10] <bulk88> I filed a plan for getting EUMM back onto monthly or
    bimonthly releases and get the git repo back into sane plan, you deleted it.
    [20:11] <@mst> I'm not asking you to monday morning quarterback our
    branch management
    [20:12] <@mst> I'm asking you to file an issue representing the
    specific, concrete problem you're dealing with
    [20:12] <@mst> this was my response to your "should I be PRing the 7.10
    branch?" question
    [20:12] <bulk88> so daily bumps are fine on RTs?
    [20:12] <bulk88> *on PRs
    [20:12] <@mst> ...
    [20:13] <@mst> every time I answer your question, you move the goalposts
    to a different zip code
    [20:14] <@mst> until you have an issue number for a specific problem
    you're experiencing plus a proposed solution - and I mean a problem with
    the code, not your perception of the branch management process - there's
    nothing further to discuss
    [20:14] <bulk88> " <@mst> I'm not asking you to monday morning
    quarterback our branch management" so your responses in this room today
    officially reflect the decisions of PTG or not? can I quote everything
    you said today in this room?
    [20:18] <@mst> decisions are generally made by consensus, as you were
    told already; as such, your question is at best nonsensical and at worst
    intentionally disingenuous.
    [20:19] <@mst> that said, you may quote anything I've said as a thing
    I've said.

    So from this conversation, MST has taken on the role as the
    administrator and therefore owner of PTG. Is MST the actual owner of the
    PTG account (root password for GH) or just one of 30 members?

    [20:10] <bulk88> I filed a plan for getting EUMM back onto monthly or
    bimonthly releases and get the git repo back into sane plan, you deleted it.
    [20:11] <@mst> I'm not asking you to monday morning quarterback our
    branch management

    So MST says PTG is one closed group. In effect, a secret society, and it
    is none of the business of the public to criticize or question that
    secret society. And who is "our"? All 30 members?

    Is PTG a secret society? There are 30 members publicly listed, when one
    of you says something, if the other 29 don't say anything, are they
    approving what the 1 member said? Every member in PTG has a choice to be
    a member, and a choice to resign. In recent non-programming world
    history, failure to resign, means you will be tried for the [war] crimes
    of your peers. I am not saying "tried for the crimes of your peers"
    applies to PTG, but that is a possible outcome of this discussion after
    further posts.

    Both MST and leont
    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/242#issuecomment-152031305
    and
    https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md#toolchain-charter-practices
    section use the word "consensus" repeatedly.

    I can lookup word consensus in a dictionary, but that definition doesn't
    apply to PTG modules. Every software project has an human author or
    owner (this bot better not be writing software
    http://www.thegreenhead.com/imgs/xl/lifesize-terminator-t-800-endoskeleton-xl.jpg
    ). PTG is different, as leont said "but in practice most important
    decisions would likely be made by the broader toolchain gang (that is
    neither a complete subset not a complete superset of comaints)." To say
    there is no owner of PTG, means it is time to shutdown CPAN/PAUSE, and
    each perl user is to himself judge the provenance of each github fork of
    perl software. That is anarchy and wont work.

    As I see it (and someone correct me officially if I am wrong), everyone
    falls into 3 groups

    -root password holders of PTG

    -members of PTG (30 listed)

    -general public

    Currently, if you want to win a fight on PTG, just make the most number
    of posts in a ticket/issue/PR. Whether you are general public or PTG
    regular or PTG admin, doesn't matter, you will win.

    Currently, if you dont want to be held responsible for your words, just
    say you are speaking for yourself and not PTG even if you are one of the
    30 PTG members.

    People chime in on PTG tickets, if they are one of the 30 PTG members,
    are they talking as themselves, or are they talking in their capacity as
    a PTG member and project owner? I can't tell. While not being to tell
    who is PTG and who general public is an altruistic nice thing about perl
    development, there isnt classism, there is a downside.

    You can't identify any leadership for the software. There is no author.
    There is no owner. There are 30 PTG members who could be the owner, but
    none of them step up to take responsibility for the success or failure
    of a project. Who gave each one a commit bit/membership? You can't
    identify a scapegoat. For P5P, there is RJBS as the scapegoat, who is
    the scapegoat for PTG?

    There are 30 people, they hide behind the anonymous structure of PTG. If
    PTG is really consensus, all 30 people must vote on each ticket/PR, with
    their votes public record, and every member of the public has a right to
    hold those 30 people and their votes responsible for API design/merges.
    Step up and take responsibility for your work. If you don't like the
    responsibility, step down from PTG and become a random member of the public.

    If a quorum can't be assembled, nothing gets committed until one is
    created. If you can't get enough member volunteers, PTG GH should be
    disbanded to the actual day to day maintainers of each module and they
    should keep the repos in their own names on GH.

    Another way to disband PTG as it is currently structured is discard the
    charter in
    https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md#toolchain-charter-practices
    and say PTG is a GH user/org, that is a permanent archive of PRs and
    issues for high river CPAN modules, its only purpose it to permanently
    archive PRs and issues, which is not possible with repos held by
    individual people under their own name since if they leave, and delete
    their GH account or repo, while the git repo will live on with the new
    maintainer, the PRs and tickets are gone forever, which is not
    acceptable, so PTG is simply an archive of discussions, like a mailing
    list archive. Each PTG module has one owner/maintainer or atmost 3 of
    them. That owner/maintainer owns the PTG repo, not PTG. Anyone who
    thinks their module is high-river enough to need a permanent place to
    store their issues/PRs can join PTG. A PTG member can not commit to any
    repos but his own. The only difference with this hypothetical PTG, other
    than the archiving discussion feature is
    -------------------------------------------------------------------
    7. Toolchain authors agreed that when a primary maintainer steps down or
    becomes permanently unavailable, the toolchain authors as a group will
    jointly agree on a successor. PAUSE administrators should defer to the
    consensus (or decision of the tie-breaker) for handing over PAUSE
    permissions as needed. Any successor should agree to the practices
    described herein.
    -------------------------------------------------------------------
    which would say that a takeover happens in 1 or 2 weeks and without the
    formalities of documentation of unreachability of old maintainer, and
    not 1-6 months as with the public PAUSE takeover process.

    Now onto EU::MM.

    Here are some questions that do not necessarily need to be answered
    publicly one by one, since some level of private debate and thinking has
    to exist, but I've some of these seen them asked in IRC rooms before by
    PTG or non-PTG general public

    Why did EU::MM development stall (my question)?

    Why did mohawk's changes went in unsupervised (not my question)?

    Who gave him a commit bit (not my question)?

    Why "bugs" instead of "notabug" preventing EUMM stable (my question)?

    Why didnt mohawk take over releasing EUMM from bingos (my question)?

    I am not blaming mohawk. He isn't the failure, someone or some other
    people are.

    I dont expect those questions to be answered publicly, but someone needs
    to take responsibility for why EUMM dev stopped, and what the plan is
    (including finding or donating volunteer hours) for getting it on track.
    Hiding behind "I am a PTG member but I am not speaking for PTG just
    myself" is not acceptable. Who is the owner or leader of EUMM?

    If there is no owner, I'll file a takeover request on module-authors and
    the problem is fixed in a heartbeat (not sure if I am joking).

    ANY ONE PERSON in perl community can disappear forever at any time. The
    maintainer or owner of a module is responsible for not letting things go
    into a repo that they dont know how to maintain, and letting incomplete
    buggy features get into the master/blead/whatever central branch of the
    the repo. Experiments stay in branches, not the mainline repo. The
    maintainer of the module must assume the member of the public that
    submitted the patch will NOT provide followup support after it has been
    committed and can't get into a situation where they at the mercy of a
    member of the public who did the PTG patch on company time, and can't
    respond any further as they have moved on. Most Perl devs leave after
    2-3 years. 10 years of publishing FOSS makes you a senior citizen. The
    people here today, won't be here in a couple years.

    I don't like writing policy and regulations
    https://www.youtube.com/watch?v=p5-5a6Q54BM but since the current
    no-rules system failed for EUMM under PTG's watch, some reforms are
    needed to prevent another EUMM from happening in the future.
  • Leon Timmermans at Oct 30, 2015 at 12:15 am
    On Thu, Oct 29, 2015 at 11:13 PM, bulk88 wrote:

    Where is the list described in #2 for Perl-Toolchain-Gang controlled
    modules?
    The policy was decided, and I know it was implemented for some modules, but
    not necessarily on all yet. This is a goal, not an immediate reality.

    Do all 30 people listed in PTG have the same perms and standing in PTG?
    >

    PTG commit bits are mainly about practicality, IMO. Thinking about the PTG
    as a community is a far more useful concept to me.

    Are all 30 people free to push to all ~27 PTG repos at any time?
    Technically free or socially free?
    IMO anyone is free to push to a branch on any of the repos (unless there's
    a reason to believe otherwise), but if you need to ask if you can merge to
    master you probably shouldn't.

    Who has the root password to the PTG github account to add and remove
    members from that list? I'll assume there is more than 1 person.
    Andy, Ricardo, Schwern, mst, xdg and me. I do not consider us the owners of
    PTG in any way, more like caretakers.

    BINGOS does many CPAN releases for PTG modules for a number of years now
    but he rarely writes code. In PAUSE, there is a concept of owner, and
    comaint. Do these have relevance to who is the owner of a PTG module? I
    find any "Author" section in PTG module pod to be years or a decade out of
    date. Is the Pod's author the "owner" of the module and still responsible
    for it even though it is under PTG care?
    I don't think you can generalize these questions within the PTG, it's
    different for different projects. I do think we can and should document
    policies better. Tuits are always in short supply though.

    [20:10] <bulk88> I filed a plan for getting EUMM back onto monthly or
    bimonthly releases and get the git repo back into sane plan, you deleted it.
    [20:11] <@mst> I'm not asking you to monday morning quarterback our branch
    management

    So MST says PTG is one closed group. In effect, a secret society, and it
    is none of the business of the public to criticize or question that secret
    society. And who is "our"? All 30 members?
    Your way of arguing about this is rather frustrating for a lot of people,
    that's the «monday morning quarterback» he's talking about. You may find
    your enquiries to be a lot more effective if you had just asked something
    like «What is the current status of ExtUtils::MakeMaker? I'm worried about
    whether some functionality of 7.06 not making into a stable release on time
    for the next release of perl and I'm not sure what branch I should work
    from now». Currently you're coming off as a lot more hostile than you
    probably intend to.

    There are 30 people, they hide behind the anonymous structure of PTG. If
    PTG is really consensus, all 30 people must vote on each ticket/PR, with
    their votes public record, and every member of the public has a right to
    hold those 30 people and their votes responsible for API design/merges.
    Step up and take responsibility for your work. If you don't like the
    responsibility, step down from PTG and become a random member of the public.
    PTG is not a formal organization with voting procedures. It's more like a
    village where people live side-by-side but sometimes talk about issues that
    affect everyone else.

    Why did EU::MM development stall (my question)?
    >

    Mostly because of a lack of tuits really. Quite frankly, for most other
    people the current status-quo is fine (unlike 7.06), the regressions have
    been fixed so other changes aren't urgent. I think you're underestimating
    how conservative a lot of us are when it comes to MakeMaker.

    Why didnt mohawk take over releasing EUMM from bingos (my question)?
    He would have been insane to accept that, really.

    Leon
  • Bulk88 at Nov 7, 2015 at 9:54 pm

    Leon Timmermans wrote:
    On Thu, Oct 29, 2015 at 11:13 PM, bulk88 wrote:
    [20:10] <bulk88> I filed a plan for getting EUMM back onto monthly
    or bimonthly releases and get the git repo back into sane plan, you
    deleted it.
    [20:11] <@mst> I'm not asking you to monday morning quarterback our
    branch management

    So MST says PTG is one closed group. In effect, a secret society,
    and it is none of the business of the public to criticize or
    question that secret society. And who is "our"? All 30 members?


    Your way of arguing about this is rather frustrating for a lot of
    people, that's the «monday morning quarterback» he's talking about. You
    may find your enquiries to be a lot more effective if you had just asked
    something like «What is the current status of ExtUtils::MakeMaker? I'm
    worried about whether some functionality of 7.06 not making into a
    stable release on time for the next release of perl and I'm not sure
    what branch I should work from now». Currently you're coming off as a
    lot more hostile than you probably intend to.
    I've tried to not pay attention to EUMM for many months, trusting the
    right people know what they are doing. But
    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/235
    should've been a wake up call that something is very wrong, but it
    wasn't a wake up call. The revert should have never happened. It looks
    to me like it was done hastily to avoid "tough questions", kick the can
    down the road, and end the unpleasant discussion.

    Trusting people know what they are doing hasn't worked out very well, so
    5.24 will have a 2 year old EUMM, so it is time to turn the thermostat
    to 40C to get anything done (and something did get done but not enough
    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/tree/no-eumm-dir
    https://travis-ci.org/Perl-Toolchain-Gang/ExtUtils-MakeMaker/builds/88259533
    ). It won't get done on its own. Keeping silent isn't going to improve
    anything down the road since that just reinforce that the status-quo is
    fine and nobody cares. A number of people gave me answers to «What is
    the current status of ExtUtils::MakeMaker? I'm worried about whether
    some functionality of 7.06 not making into a stable release on time for
    the next release of perl and I'm not sure what branch I should work from
    now" but they aren't active devs in EUMM, they wont personally ship a
    tarball, and dont have any social (not technical) authority related to
    EUMM, so they are just guessing answers just like I can guess. No
    checklist exists with the unconditional list of bugs to fix before EUMM
    stable, and when those issues are fixed.

    GH looks like it has such a list, but this isn't that checklist

    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues?q=is%3Aopen+is%3Aissue+label%3A%22Blocking+Stable%22

    This is a disorganized list
    https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/235
    with no way of knowing what was resolved in EUMM master and wasn't. As
    individual people pile on tickets onto #235, there is no process or vote
    (even just 1 confirm or deny by anyone) to say "this ticket blocks
    stable" or "your regression bug is EUMM UB, and it is questionable if it
    is a bug, your ticket does not block stable".

    Looking through random tickets
    https://rt.cpan.org/Public/Bug/Display.html?id=106975 Why is the last
    post saying "fixed"? Why wasn't this ticket RT resolved?
    There are 30 people, they hide behind the anonymous structure of
    PTG. If PTG is really consensus, all 30 people must vote on each
    ticket/PR, with their votes public record, and every member of the
    public has a right to hold those 30 people and their votes
    responsible for API design/merges. Step up and take responsibility
    for your work. If you don't like the responsibility, step down from
    PTG and become a random member of the public.


    PTG is not a formal organization with voting procedures. It's more like
    a village where people live side-by-side but sometimes talk about issues
    that affect everyone else.
    A village has houses. Houses have to have building numbers. There is a
    tax assessor who says who is the owner of every house. Foreclosure and
    auction is the end game when you house looks like
    http://i.dslr.net/syms/bddd03923084af846367f7ace54192c1.jpg
    Why did EU::MM development stall (my question)?


    Mostly because of a lack of tuits really. Quite frankly, for most other
    people the current status-quo is fine (unlike 7.06), the regressions
    have been fixed so other changes aren't urgent. I think you're
    underestimating how conservative a lot of us are when it comes to MakeMaker.
    Again with the "us". I am arguing with a gang of guy fawkes masks (I am
    2 days late with this pun).

    ----------------------------------------------------------------------
    1. The toolchain has a wider scope of backwards compatibility goals than
    the Perl core, as toolchain aims to support every Perl from 5.8.1 onwards.
    ----------------------------------------------------------------------

    I think Clause 1 best describes the root problem with PTG module
    management. Since over one week, there have been only 2 responses, but I
    bet alot more pairs of eyes read it and never responded. I am starting
    to think this discussion doesn't belong on cpan-workers ML, and can't be
    solved on this ML, but elsewhere in perl world.
  • Neil Bowers at Nov 9, 2015 at 10:15 am
    I’ve been keeping well out of this, but I wanted to comment on one point:
    On 7 Nov 2015, at 21:54, bulk88 wrote:
    But https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/issues/235 should've been a wake up call that something is very wrong, but it wasn't a wake up call. The revert should have never happened. It looks to me like it was done hastily to avoid "tough questions", kick the can down the road, and end the unpleasant discussion.

    <imho>
    For critical modules like EUMM, if the latest non-developer release on CPAN is broken in a way that affects downstream dists, then it should be fixed in the most expeditious way. If that means a revert to give people time to look at the *correct way forward*, then so be it.

    Here “critical” for me essentially means “far enough up the CPAN river that a large percentage of CPAN is dependent on it”. And there ain’t much further upstream than EUMM.
    </imho>

    Neil
  • David Golden at Oct 30, 2015 at 4:11 pm
    Mostly, I concur with what Leon said. I'm going to pick off or clarify in
    several places.


    Do all 30 people listed in PTG have the same perms and standing in PTG?
    We recently flattened it. There are the "owners" who have ultimate control
    per github. Mostly, all we do is manage membership.

    There are "admins" who get admin control over repos for stuff like setting
    up git hooks or other things. These are generally the "lead" developers
    for the different projects and we trust people not to muck with settings on
    repos they don't contribute to.

    Everyone else (the "chain gang") has write access to all repos.

    Are all 30 people free to push to all ~27 PTG repos at any time?
    Technically free or socially free?
    Technically free. Socially, I think Leon put it well. We generally trust
    people to do the right thing on projects they are collaborating on. And
    since it's a VCS, if people abuse that trust, reversions are easy-ish.

    BINGOS does many CPAN releases for PTG modules for a number of years now
    but he rarely writes code. In PAUSE, there is a concept of owner, and
    comaint. Do these have relevance to who is the owner of a PTG module?

    I would distinguish PTG the Github organization from "toolchain
    maintainers" more generally/socially. PTG is a facility for
    collaboration. It reflects the social collaboration agreements among
    people who contribute to toolchain modules.

    The social organization is decentralized. In recent years, venues like
    #toolchain and the QA hackathons and this list (and sometimes p5p) have
    been where differences get debated and courses of action set.

    Generally, I think there has been little advanced planning and discussion
    and whoever was interested/active and had PAUSE permissions did whatever
    they wanted without much oversight. The Berlin discussions were an attempt
    to change that.

    I find any "Author" section in PTG module pod to be years or a decade out
    of date. Is the Pod's author the "owner" of the module and still
    responsible for it even though it is under PTG care?
    The author section accumulates. I personally consider the last person to
    ship to CPAN to be the person "on the hook" for any given module unless
    they specifically say they are stepping down from that role. (Ideally, by
    making someone else the primary maintainer on PAUSE.)


    If a PTG module is always released by one person, and nearly every commit
    is by one person, page after page on GH, year after year, XDG's modules for
    example, it is obvious that he, and not the PTG collective is the owner of
    that.
    By putting my modules on PTG, I'm explicitly taking myself out of the
    critical path for their development.

    When a module is "donated" to PTG, is the donator still the owner of the
    module, or is PTG collectively now the owner and author of the module, and
    original owner can not be blamed for anything that happens under PTG
    development model?
    PTG (the org) is a vehicle to facilitate collaboration. By putting it
    there, an author is inviting any of the PTG members to hack on it. It
    doesn't mean anything about "ownership".

    In my opinion, the only place of record for ownership is PAUSE. If there
    is one person to look to, that's the person listed as primary maintainer.
    Co-maints are also responsible parties, though many are inactive in
    practice.

    Who gets a free ride to the police station when a rootkit that calls home
    was shipped to CPAN in a PTG tarball?
    I think the LICENSE of most modules disclaims any warranty, but to your
    more general point, I would hold the person who uploaded to CPAN ultimately
    responsible for the quality of what they ship.

    The PTG member with a commit bit who pushed the rootkit to the PTG git
    repo responsible?
    That falls under the "breach of trust" point I made earlier.

    What are the responsibilities of a PTG member who cuts a CPAN tarball?
    Are they a cron job whose only purpose is to bump version numbers and
    verify the changelog contains a new version number, or are they required to
    review the git history (and perhaps GH issues/PRs) since the last CPAN
    release?
    As I said already, don't think of it as "PTG member". The PAUSE author who
    uploads is responsible for quality. If that person commits a breach of
    trust or is otherwise grossly negligent, the Berlin governance mechanisms
    would kick in to encourage that person to step down. Ultimately, that
    means the Pumpking has the power to fire a maintainer.

    Thus, I think the uploader ought to be more than a cron-job and should
    either review the code personally or delegate that to trusted 3rd parties.

    Bullet #5 says RJBS is the "tie breaker". I dont personally think that
    sentence is the same as owner, but someone can interpret that sentence as
    meaning RJBS is the final say on PTG, and therefore the owner of PTG.
    RJBS (and likely any future pumpking) would probably be put in the github
    "owners" group for convenience but he is not the "owner" of the group.
    Rik's authority over dual-life modules ultimately derives from Larry's
    delegation and perlpolicy. He is ultimately responsible for the quality of
    perl releases under his tenure.

    local::lib's perms list has many people not in
    https://github.com/orgs/Perl-Toolchain-Gang/people . What is going on
    with this module?
    Some people believe in giving out commit bits liberally as a way of
    encouraging contributors. That's up to the primary maintainer. I agree
    that your concern about attack vectors is a reasonable reason to prune such
    long lists.

    There is a PAUSE ID called MMML
    http://www.nntp.perl.org/group/perl.modules/2000/10/msg3190.html A number
    of PTG modules have this in PAUSE, but not all. Who is MMML? What is the
    purpose of this account?
    PAUSE has a concept of "mailing lists" which function as group
    permissions. Andreas would have to elaborate further.

    So from this conversation, MST has taken on the role as the administrator
    and therefore owner of PTG. Is MST the actual owner of the PTG account
    (root password for GH) or just one of 30 members?
    Matt has "owner" permissions and is empowered to moderate discussions. As
    I said on that ticket, process/governance questions are better discussed
    here.

    Is PTG a secret society?

    PTG is a shared code repository. What anyone says or commits doesn't imply
    any endorsement by other members.

    I can lookup word consensus in a dictionary, but that definition doesn't
    apply to PTG modules.

    It applies in the sense that "we" (parties interested in Perl toolchain
    issues) have generally agreed that we want major decisions to have general
    agreement by interested parties. (Yes, this is sort of a circular
    definition.)

    Think of it this way: even though I don't maintain (or want to maintain)
    parts of the toolchain, I have strong opinions about how those parts should
    work. And I want whoever is maintaining those other parts to take my
    opinion (and the opinions of others) into account.

    For P5P, there is RJBS as the scapegoat, who is the scapegoat for PTG?
    The owners group are the scapegoats for the technical (and social) issues
    involved in running a shared code repository. It has nothing to do with the
    ownership of modules.

    Personally, I consider the PAUSE primary maintainer to the be the owner of
    record and thus scapegoat and no one should remain in that role unless they
    are willing to take that responsibility.


    My answers to the following questions represent my personal opinion. I'm
    not speaking as a "PTG owner" or anything.

    Why did EU::MM development stall (my question)?
    I think EUMM is so complex and poorly understood that few people are
    comfortable reviewing and signing off on major changes.

    Why did mohawk's changes went in unsupervised (not my question)?
    I don't know. I suspect that some code review indicated that it was safe
    and that problems were discovered later after release. This may indicate a
    failure of the release testing process.

    Who gave him a commit bit (not my question)?
    Probably me, under the general principle that anyone credibly wanting to
    participate should get a bit until they abuse that trust.

    Why "bugs" instead of "notabug" preventing EUMM stable (my question)?

    I don't understand the question.
    Why didnt mohawk take over releasing EUMM from bingos (my question)?
    Because he doesn't have enough of a track record to be trusted with control
    of such a linchpin of CPAN.

    watch, some reforms are needed to prevent another EUMM from happening in
    the future.
    This mailing list is the right place to discuss ways to improve the
    governance of EUMM.

    David

    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Bulk88 at Nov 7, 2015 at 9:55 pm

    David Golden wrote:
    BINGOS does many CPAN releases for PTG modules for a number of years
    now but he rarely writes code. In PAUSE, there is a concept of
    owner, and comaint. Do these have relevance to who is the owner of a
    PTG module?


    I would distinguish PTG the Github organization from "toolchain
    maintainers" more generally/socially. PTG is a facility for
    collaboration. It reflects the social collaboration agreements among
    people who contribute to toolchain modules.

    The social organization is decentralized. In recent years, venues like
    #toolchain and the QA hackathons and this list (and sometimes p5p) have
    been where differences get debated and courses of action set.
    There is a group of people who have official power, people who are
    trusted with limited power, and a group of very interested members of
    the public. It is a venn diagram. Who is in PTG with limited power, who
    is an admin of PTG, who is on IRC in #toolchain, who is on SO/PMonks,
    who posts in GH/RT, and who shows up to QAH, are all different
    overlapping circles. The social organization is decentralized, but PAUSE
    absolutely isn't, you mention things supporting in the next paragraph
    and 3rd/4th/5th paragraph quotes. You (alone out of 6?) seem to support
    the idea that the PAUSE releaser is the owner of a module, not the
    limited power 30 PTG members, or the 6 PTG admins (and you xdg are one
    of the 6).

    \/\/\/\/\/\/\/\/\/
    I find any "Author" section in PTG module pod to be years or a
    decade out of date. Is the Pod's author the "owner" of the module
    and still responsible for it even though it is under PTG care?


    The author section accumulates. I personally consider the last person
    to ship to CPAN to be the person "on the hook" for any given module
    unless they specifically say they are stepping down from that role.
    (Ideally, by making someone else the primary maintainer on PAUSE.)
    ^^^^^^^^^^^^^^^^
    If a PTG module is always released by one person, and nearly every
    commit is by one person, page after page on GH, year after year,
    XDG's modules for example, it is obvious that he, and not the PTG
    collective is the owner of that.


    By putting my modules on PTG, I'm explicitly taking myself out of the
    critical path for their development.
    I dont know why you mean by "critical path". Do you mean that you will
    defer to the community over sub names, sub arguments, POD, module deps,
    and tabs vs spaces instead of your own opinion?

    If you spend the hours responding to tickets, writing patches, and
    making CPAN tarballs, other PTG people will still wait for your
    response, instead of pushing to the repo, and upload a new CPAN alpha
    tarball within 90 seconds.
    When a module is "donated" to PTG, is the donator still the owner of
    the module, or is PTG collectively now the owner and author of the
    module, and original owner can not be blamed for anything that
    happens under PTG development model?


    PTG (the org) is a vehicle to facilitate collaboration. By putting it
    there, an author is inviting any of the PTG members to hack on it. It
    doesn't mean anything about "ownership".
    \/\/\/\/\/\/\/\/\/
    In my opinion, the only place of record for ownership is PAUSE. If
    there is one person to look to, that's the person listed as primary
    maintainer. Co-maints are also responsible parties, though many are
    inactive in practice.
    ^^^^^^^^^^^^^^^^^^^^^^^
    What are the responsibilities of a PTG member who cuts a CPAN tarball?
    Are they a cron job whose only purpose is to bump version numbers
    and verify the changelog contains a new version number, or are they
    required to review the git history (and perhaps GH issues/PRs) since
    the last CPAN release?

    \/\/\/\/\/\/\/\/\/
    As I said already, don't think of it as "PTG member". The PAUSE author
    who uploads is responsible for quality.
    ^^^^^^^^^^^^^^^^^^
    Is PTG a secret society?


    PTG is a shared code repository. What anyone says or commits doesn't
    imply any endorsement by other members.
    *******cut********
    For P5P, there is RJBS as the scapegoat, who is the scapegoat for PTG?


    The owners group are the scapegoats for the technical (and social)
    issues involved in running a shared code repository. It has nothing to
    do with the ownership of modules.
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Personally, I consider the PAUSE primary maintainer to the be the owner
    of record and thus scapegoat and no one should remain in that role
    unless they are willing to take that responsibility.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    My answers to the following questions represent my personal opinion.
    I'm not speaking as a "PTG owner" or anything.
    Again the problem is, PTG is everyone, but no one. Since governance and
    management are tough questions with not rosy answers, nobody wants to
    respond.

    Leon Timmermans wrote:
    Who has the root password to the PTG github account to add and
    remove members from that list? I'll assume there is more than 1 person.

    Andy, Ricardo, Schwern, mst, xdg and me. I do not consider us the owners
    of PTG in any way, more like caretakers.
    Unless all 6 people respond, there is no governance since 1 out of 6
    people speaking changes nothing. I'll thank leont and xdg for responding
    in detail, but they are still 2 out of 6, or 2 out of 30, or 2 out of
    40-50, depending which circle you pick as the definition of "toolchain
    gang".
  • David Golden at Nov 9, 2015 at 3:35 pm
    Bulk,

    I don't understand what you're trying to achieve on this thread, so I'm
    going to pull up and try to address what I think you might be asking rather
    than go point by point.

    Do you want some acknowledgement that governance is shitty? I agree. Our
    governance is shitty, just like most of open source.

    Do you want to know what the deal with with PTG? I've said it's a shared
    repo. The "owners" are there for administrative purposes, not governance.
    Several are essentially silent partners now and continue to be on the
    owners list mostly to keep the bus number up.

    Do you want to know if there's a "plan" for EUMM? I think the evidence is
    "clearly not" (just as with p5p, development is mostly a random walk by
    motivated contributors).

    Do you want to know who's in charge of EUMM? I've said BinGOs is (along
    with other comaints to a lesser degree) and no one has stepped up to claim
    otherwise, so take that for what it's worth. All the community/governance
    discussions aside, the only authority that really matters is PAUSE
    permissions.

    Do you want to know what to do if you think BinGOs et al. aren't doing
    their jobs? I'd suggest emailing them privately to discuss your thoughts
    about what could be done better. If he's not responsive, I don't think
    PAUSE admins would consider BinGOs absent, so you should take it up with
    the pumpking as the final authority.

    Do you want to know where to continue EUMM development? master branch of
    the PTG repo.

    Do you want to know what work would be deemed "acceptable" by
    BinGOs/others? I think small, targeted fixes are likely to get applied
    (and eventually shipped). By which I mean a PR with a test that
    demonstrates a problem and a narrow fix that is easy to grok by reviewers.

    Do you want to know whether the mohawk work will ever be revived? I don't
    know but I suspect not -- or at least not in the form it was. It was too
    invasive and too hard to review. I consider it a well intentioned, but
    failed experiment. Given that the entire Perl community already lives with
    EUMM's existing flaws, substantial changes bring huge risk for uncertain
    benefit.

    Do you want to know if work you do would be accepted/shipped in time for
    5.24? I think that's part of the discussion you need to have with BinGOs
    and other co-maints with the power to ship, along with RJBS for how urgent
    he sees the fixes and whether he wants to use his institution authority to
    lean on people.

    Does any of that provide useful guidance? If not, please let me know. I'd
    like to channel your frustration into some sort of practical action you can
    take to move things forward so we don't keep spinning in discussion.

    Regards,
    David


    On Sat, Nov 7, 2015 at 4:55 PM, bulk88 wrote:

    David Golden wrote:
    BINGOS does many CPAN releases for PTG modules for a number of years
    now but he rarely writes code. In PAUSE, there is a concept of
    owner, and comaint. Do these have relevance to who is the owner of a
    PTG module?


    I would distinguish PTG the Github organization from "toolchain
    maintainers" more generally/socially. PTG is a facility for
    collaboration. It reflects the social collaboration agreements among
    people who contribute to toolchain modules.

    The social organization is decentralized. In recent years, venues like
    #toolchain and the QA hackathons and this list (and sometimes p5p) have
    been where differences get debated and courses of action set.
    There is a group of people who have official power, people who are trusted
    with limited power, and a group of very interested members of the public.
    It is a venn diagram. Who is in PTG with limited power, who is an admin of
    PTG, who is on IRC in #toolchain, who is on SO/PMonks, who posts in GH/RT,
    and who shows up to QAH, are all different overlapping circles. The social
    organization is decentralized, but PAUSE absolutely isn't, you mention
    things supporting in the next paragraph and 3rd/4th/5th paragraph quotes.
    You (alone out of 6?) seem to support the idea that the PAUSE releaser is
    the owner of a module, not the limited power 30 PTG members, or the 6 PTG
    admins (and you xdg are one of the 6).

    \/\/\/\/\/\/\/\/\/
    I find any "Author" section in PTG module pod to be years or a
    decade out of date. Is the Pod's author the "owner" of the module
    and still responsible for it even though it is under PTG care?


    The author section accumulates. I personally consider the last person
    to ship to CPAN to be the person "on the hook" for any given module
    unless they specifically say they are stepping down from that role.
    (Ideally, by making someone else the primary maintainer on PAUSE.)
    ^^^^^^^^^^^^^^^^

    If a PTG module is always released by one person, and nearly every
    commit is by one person, page after page on GH, year after year,
    XDG's modules for example, it is obvious that he, and not the PTG
    collective is the owner of that.


    By putting my modules on PTG, I'm explicitly taking myself out of the
    critical path for their development.
    I dont know why you mean by "critical path". Do you mean that you will
    defer to the community over sub names, sub arguments, POD, module deps, and
    tabs vs spaces instead of your own opinion?

    If you spend the hours responding to tickets, writing patches, and making
    CPAN tarballs, other PTG people will still wait for your response, instead
    of pushing to the repo, and upload a new CPAN alpha tarball within 90
    seconds.

    When a module is "donated" to PTG, is the donator still the owner of
    the module, or is PTG collectively now the owner and author of the
    module, and original owner can not be blamed for anything that
    happens under PTG development model?


    PTG (the org) is a vehicle to facilitate collaboration. By putting it
    there, an author is inviting any of the PTG members to hack on it. It
    doesn't mean anything about "ownership".

    \/\/\/\/\/\/\/\/\/
    In my opinion, the only place of record for ownership is PAUSE. If
    there is one person to look to, that's the person listed as primary
    maintainer. Co-maints are also responsible parties, though many are
    inactive in practice.
    ^^^^^^^^^^^^^^^^^^^^^^^

    What are the responsibilities of a PTG member who cuts a CPAN tarball?
    Are they a cron job whose only purpose is to bump version numbers
    and verify the changelog contains a new version number, or are they
    required to review the git history (and perhaps GH issues/PRs) since
    the last CPAN release?


    \/\/\/\/\/\/\/\/\/
    As I said already, don't think of it as "PTG member". The PAUSE author
    who uploads is responsible for quality.
    ^^^^^^^^^^^^^^^^^^

    Is PTG a secret society?

    PTG is a shared code repository. What anyone says or commits doesn't
    imply any endorsement by other members.

    *******cut********
    For P5P, there is RJBS as the scapegoat, who is the scapegoat for PTG?


    The owners group are the scapegoats for the technical (and social)
    issues involved in running a shared code repository. It has nothing to
    do with the ownership of modules.

    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Personally, I consider the PAUSE primary maintainer to the be the owner
    of record and thus scapegoat and no one should remain in that role
    unless they are willing to take that responsibility.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    My answers to the following questions represent my personal opinion.
    I'm not speaking as a "PTG owner" or anything.
    Again the problem is, PTG is everyone, but no one. Since governance and
    management are tough questions with not rosy answers, nobody wants to
    respond.

    Leon Timmermans wrote:
    Who has the root password to the PTG github account to add and
    remove members from that list? I'll assume there is more than 1 person.

    Andy, Ricardo, Schwern, mst, xdg and me. I do not consider us the owners
    of PTG in any way, more like caretakers.
    Unless all 6 people respond, there is no governance since 1 out of 6
    people speaking changes nothing. I'll thank leont and xdg for responding in
    detail, but they are still 2 out of 6, or 2 out of 30, or 2 out of 40-50,
    depending which circle you pick as the definition of "toolchain gang".


    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Graham Knop at Nov 11, 2015 at 10:35 am

    On 11/9/15 10:34 AM, David Golden wrote:
    Do you want to know what work would be deemed "acceptable" by
    BinGOs/others? I think small, targeted fixes are likely to get applied
    (and eventually shipped). By which I mean a PR with a test that
    demonstrates a problem and a narrow fix that is easy to grok by reviewers.
    Larger changes are certainly welcome, but given EUMM's position in the
    ecosystem, we have to be very careful when making them.
    Do you want to know whether the mohawk work will ever be revived? I
    don't know but I suspect not -- or at least not in the form it was. It
    was too invasive and too hard to review. I consider it a well
    intentioned, but failed experiment. Given that the entire Perl
    community already lives with EUMM's existing flaws, substantial changes
    bring huge risk for uncertain benefit.
    I don't think this is accurate. The revert done for 7.08 was intended
    as a temporary measure until the issues introduced could be resolved.
    The master branch is still based of what was released in 7.06, and at
    this point, all of the known issues caused by 7.06 have been addressed.
      We will hopefully be getting back to releases from there soon.

    The problem with mohawk's work wasn't really that any given part of it
    was invasive. For the most part the changes were reasonable and not
    that large. But we accumulated a large number of changes into a single
    release, which made it hard to review as a whole.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 28, '15 at 11:10p
activeNov 11, '15 at 10:35a
posts9
users5
websitecpan.org

People

Translate

site design / logo © 2018 Grokbase