Front page | perl.perl5.porters |
Postings from September 2014
Re: Roadmap/plan for Perl 5?
Thread Previous
|
Thread Next
From:
sawyer x
Date:
September 3, 2014 12:01
Subject:
Re: Roadmap/plan for Perl 5?
Message ID:
CAMvkq_QMQ5nKzg3EjCt2k2qNKrCduX8waX7g=fRZ2cY+83VoZQ@mail.gmail.com
On Wed, Sep 3, 2014 at 3:22 AM, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:
>
> perl5 does not have a road map. While I'm holding the pumpkin, I think it
> is
> *extremely* unlikely that it will. This is not to say that I think all the
> "we should"s in this thread are things we shouldn't.
>
> First, let me say what I mean by "roadmap," so it's clear what I'm saying
> we
> won't have. A roadmap lists the places that you are going to go, in the
> order
> you are going to go to them, and how you plan to get there. In software,
> of
> course, we're not traveling. Instead, the destinations are changes in
> behavior
> or implementation.
>
I think we have a different definition of roadmap. I will concede that mine
is ambiguous while yours isn't. Perhaps I should use a different word, like
"plan" or "vision".
To me, it represents the direction you want to take the project. Along the
way there, different people will work on different things (perhaps some
that aren't in the plan), but more information and requirements will be
collected in order to achieve the goals listed in the plan. People will be
able to focus their efforts and more people will join.
For example, if you want a smaller core, more issues will be open as part
of a meta-ticket about this. Efforts will be taken to identify what are the
bigger parts and discussions can be held on what to remove from the core.
I have worked on plenty of software that has a roadmap. They can be very
> nice
> to have, for a lot of reasons. Something you need for a roadmap to be
> useful,
> though, is a driver. Right now, nobody is driving perl5.
>
Why not? Couldn't we have someone (a person, a committee, an organization,
a group) doing it?
Is there a reason why many other projects have such a thing, but Perl
doesn't? Is there something special about Perl that means we can't or
shouldn't have it?
I'm genuinely wondering about this.
> What does that mean? Well, if you have a roadmap, and you're driving, you
> keep
> making sure that you're going the right way. If someone tries to get you
> off
> track, you decline. *If nobody else is making the car move, you keep your
> foot
> on the gas.*
>
Which is why "roadmap" is probably not the right term. I don't suggest
hitting Leon (sorry, Leon) because he's working on an itch he has that
isn't in the plan. What it means is simply working on fleshing out what
needs to be done and making the direction and the related tasks published
and available. Wasn't that something "Perl 5.16 and Beyond" tried to
achieve? Get people interested and focused on a direction of development?
I really want to contribute but I don't have an itch. I want to know where
the project is going and to help it get there.
There's nothing *wrong* with this situation, though. It just calls for its
> own
> kind of management. Instead of imagining perl5 moving along some
> planned-out
> road toward a goal, imagine it as a well-established city, being carefully
> expanded and rebuilt over time. The expansion and rebuilding are done by
> private citizens' groups, but they have to be of benefit to everyone, so
> there
> is a city planner who weighs these proposed changes in light of the
> existing
> city and of other projects currently underway, previously undertaken, or
> concurrently under discussion. Also, knowing how other cities do stuff
> helps.
>
Cities have city planners. Cities have committees that discuss how the
overall city looks like, what it conforms to, and what the budgetary
priorities are.
In our example, our city is not this organically-grown composition of life.
It's a staircase here because someone was able to build it without anyone
saying no (or not enough people saying no). It's a floor there because
someone had the tiles and time to lay them. It's a city that has no
direction and seems patched together by time and effort of random people
("private citizens' groups") and the sheer luck of introducing a change
without too much resistance, rather than by jointly deciding on what it
should look like and the accomplishments done by those who had the time or
joined together. We should have more of a community effort than random
assortment of changes.
Small somewhat-unrelated tidbit: in Jerusalem you *must* construct every
building using the same stone (named after Jerusalem) so the city maintains
a certain consistent look.
In the past, I have occasionally posted things that I personally think
> would be
> very valuable improvements to the system, and written down things that I
> think
> would be the vital behaviors of those improvements. Sometimes this goes
> nowhere (except a list post or todo file) but sometimes there's enough
> agreement that we end up with a new feature. q.v., postfix deref
>
This seems "by chance" rather than "by design".
I don't get it: why is it inherently wrong to have a direction? Why must
success come by chance of something somehow making it, rather than a goal
we know we want to achieve?
My idea is to do the reverse of "agreement on feature". My idea is
agreement on direction. That direction can extrapolate into various
features. Each can be discussed (and each person decides which discussion
to join) and then some will get accepted and some won't. Perhaps some
features will have multiple implementation attempts, and some of those will
get attempted and some won't.
Other times, the planning needs to be undertaken by others, like fixing our
> so-called API. I'm no position to hand down a plan for that, so it has to
> be
> constructed by the interested parties. The best thing that can be done
> here, I
> think, is for people to self-organize on projects that they think will be
> successful and valuable. "Fixing docs" is in the same category, along with
> tests.
>
"Fixing our so-called API" is a direction. It's an achievement. People can
then come together who are interested in that, suggest a way to do it, and
allow a discussion around that.
So: I don't see the future as something that we try to lay out in an ordered
> plan, nor do I think that's what we can do any time soon. Instead, I think
> what we have been doing, and doing well, is letting people come forward
> with
> suggestions that can then be considered, evaluated, and encouraged or
> discouraged for further work.
>
This is not how it seems to a lot of people outside p5p (but still in the
Perl community) - myself included. There was just a talk about p5p at
YAPC::Asia. While to some people here it seems like "we just facilitate
discussion and evaluate suggests", for a lot of other people (especially
those not on p5p) it seems completely different. That should be, at some
point, addressed, IMHO. But that seems to me off-topic.
And I do apologize if any of what I'm saying seems like ranting. I'm not
trying to rant. I'm seriously suggesting having a vision and trying to
formalize some kind of plan.
I will try to go into the direction of documenting different developers'
suggestions along with Peter. I think that will be a good start. However,
it will be worthless if we won't be able to create a vision out of it. It
will be impossible to create a vision if people do not see any purpose in
having a vision.
I think a project should have a vision.
Thread Previous
|
Thread Next