Front page | perl.perl5.porters |
Postings from December 2017
I've grafted the thread back together because I think the conversation is getting lost in pruning. On Dec 31, 2017, at 01:25, Father Chrysostomos <sprout@cpan.org> wrote: > Rocco Caputo wrote: >> On Dec 30, 2017, at 20:48, Father Chrysostomos <sprout cpan.org> wrote: >>> On Dec 30, 2017, at 15:36, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: >>>> On Sat, Dec 30 2017, Father Chrysostomos jotted: >>>>> Avar wrote: >>>>>> I think in the future it makes sense to hold >>>>>> ourselves to reviewing these features once they've been unchanged in say >>>>>> 2 or 3 releases, and for the policy to say that experimental features >>>>>> unchanged in 3 development cycles must either be promoted to >>>>>> non-experimental, removed entirely, or have their semantics changed in >>>>>> major ways. >>>>> >>>>> I don't think it makes sense. If a feature is significantly flawed >>>>> (and experimental) due to lack of tuits (e.g., refaliasing), do >>>>> we have to make meaningless design changes to it to avoid having >>>>> it yanked? >>>> >>>> Not meaningless design changes, but to have some sort of schedule >>>> (preferably enforced by code, i.e. as soon as we begun 5.25 we start to >>>> warn/die) giving these experimental features an explicit expiry date. >>> >>> This would be a good way to discourage people from implementing >>> new features. >> >> I'm okay with that as an alternative to half-baked things remaining >> incomplete indefinitely. > > Yes, but what benefit would such a policy provide? Give a practical > example. Policies to prevent unreasonable situations that do not hap- > pen anyway are needless cruft. The choice as presented above is to either let experiments run indefinitely or to be clearer and more definite about the state of their development. I voted for the latter even if your claim that it would stifle innovation is correct. I think it's the better option. I appreciate your desire that everyone agree on a single, logical, and consistent resolution, but I feel it's unreasonable to require me to debate my vote. >>>> Consider the situation we're now in. We're about to release 5.28 and >>>> we've chickened out on changing a supposedly "experimental" feature >>>> mainly because it breaks stuff on CPAN. >>> >>> Good. That means we are involving the *whole community* in the lan- >>> guage design process. Yay for popular-vote-by-CPAN! >> >> If the Porters want Perl to be defined by popular usage, it behooves them not to release experiments they aren't prepared to support. > > My point was that responding to user complaints or CPAN breakage by > reverting unpopular changes, especially if it does not seem that an > alternative will be ready in time for the next stable release, is just > common courtesy. You do not need a policy to be courteous. You could > call that 'support'. That seems tangential to what I responded to. My concern is your voiced support for "popular-vote-by-CPAN". It also can lead to bad changes being ratified because they're popular. You probably didn't intend to say that. On the other hand, if it's generally desirable for popularity to be a deciding factor in some but not all cases, the exceptions should probably be noted. -- Rocco Caputo <rcaputo@pobox.com>Thread Previous | Thread Next