Re: Fwd: [ExtUtils-MakeMaker] the future of EUMM's developmentmodel(#242)

[email protected] (bulk88)
Newsgroups perl.cpan.workers
Message-ID <[email protected]>
Leon Timmermans wrote:
> On Thu, Oct 29, 2015 at 11:13 PM, bulk88 <[email protected]
> <mailto:[email protected]>> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.