develooper Front page | perl.perl5.porters | Postings from February 2017

Re: [perl #130467] Default perl builds to not include . in @INC(default_inc_excludes_dot)

Thread Previous | Thread Next
From:
Kent Fredric
Date:
February 15, 2017 11:19
Subject:
Re: [perl #130467] Default perl builds to not include . in @INC(default_inc_excludes_dot)
Message ID:
CAATnKFBVDe1_9hPj8+VCZ--mh98HJKRwF7O1U+Zcepu76=YcJg@mail.gmail.com
On 15 February 2017 at 22:32, Sawyer X <xsawyerx@gmail.com> wrote:
> I think meetings don't have to be an
> automated schedule thing but can be based solely on "Is there something
> important to discuss". But having them is a very good idea.

My reasons for this idea stem more or less from your next comment and
how it plays out with the reality of being slightly more anarchic in
toolchain.

Basically, /because/ there is no central authority, some sort of
broadcast system to give interested parties fair warning that
"important discussion detailing X will happen, everyone who cares is
encouraged to be there"

Instead of relying on them being omnipresent and detecting it by
accident. ( Such notices could be spread to quite a few networks on
existing .MLs and pull in outsiders who aren't usually idling in
#toolchain )

But I won't force the idea, it just seems like something I'd expect to
happen already due to the size we are.

>
> I would like to raise one more issue that Todd and myself have observed
> and discussed: Toolchain lacks a person who is the one to contact when
> something comes up. If an issue is raised, who's on point? Who leads the
> effort? The reporter? The "lucky" person on IRC who read it first? The
> first to reply? The person with the commit bit? The person with the
> PAUSE rights? Who decides this? I would be happy if there was one (or
> even more than one) direct person to contact and lead (or delegate
> leading) an action plan to resolve a given issue. Todd's experience
> seemed (both from the outside, and from the lists, and from the tickets,
> and from IRC) to be running around a bit trying to figure out who says
> "Yes" or "No" on something.
>
> I would be happy if this is one thing toolchain changes as well, to make
> it easier for us all to coordinate efforts.

I guess it depends on the nature of the issue, if the issue only
affects one element of the system and has no side effects, then the
people to talk to are a narrower set.

The broader the impact, the more people who have to be involved
because it requires more tuit interactions.

Given the nature of toolchain, I don't think a "Central Authority"
model would really work for it, and maybe a roadmap for how to direct
various queries and expect their resolution would be better, with an
"If you have trouble navigating the roadmap, or the players in the
roadmap fail to play nicely with each other" fallback group of
contact.

Historically, I think toolchain has mostly been a "person with commit
bits makes a judgment call, except when there is yelling, and when
there is yelling, wait for the yelling to go away, and then make a
judgment call that results in the least yelling" ... more or less. Or
perhaps the person with most understanding of the problem leads the
discussion. ( The reporter is typically not good at divining the
solution, only defining the initial problem and then ascertaining if
the chosen solution satisfies it )

It seems disorganized, but I prefer to see it as "Self-Organised" :)

Sort of like when a small group of friends decide they want to go to a
pub/restaurant, but they start out with different opinions on which
pub/restaurant they want to go to. There's not necessarily a single
decider in charge, and the decision is just an emergent property, that
sometimes requires a bit of argumentation in order to equalize all the
different interests amicably.  Its just when nobody can agree and a
stalemate appears that problems emerge.

Ultimately in order for collective success, all the individuals have
to make personal sacrifices of some type. Just on toolchain, that
sacrifice is "my san bits" most of the time :)

We should probably re-hash this stuff as a new P5P thread though.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About