Front page | perl.perl5.porters |
Postings from September 2014
Re: Roadmap/plan for Perl 5?
Thread Previous
|
Thread Next
From:
Sawyer X
Date:
September 7, 2014 18:05
Subject:
Re: Roadmap/plan for Perl 5?
Message ID:
CAMvkq_SNyEWY=KM0=EJXAxvAyRRog8ZQDGE1=dZxZdFoG2OS2w@mail.gmail.com
On Sun, Sep 7, 2014 at 12:43 PM, Abigail <abigail@abigail.be> wrote:
> >
> > However, it should be possible for everyone to know what *needs to be
> done*.
> >
>
>
> And I think that's the main hurdle for making a roadmap, and perhaps
> that's why it's not a good idea.
>
> Some questions/remarks:
>
> - Who gets to decide what "needs to be done"? The pumpkin? The people
> doing the most commits? The people with a commit bit? Anyone on p5p?
> We can't even reach concensus on the spelling of newly proposed
> operators, to the extend nothing gets implemented, so I really wonder
> who we're going to end up with a list of things that need to be done.
>
I think at this point it's only fair that the people who do the work get
the biggest say in what needs to be done. This doesn't mean the community
of users can't also pitch in their ideas, saying "this is something we
would really like to see". We need to start from somewhere.
I often notice it isn't a matter of "the user community would like a
feature but the core hackers don't care about it", but that core hackers
are aware of how difficult it would be to either implement a feature or to
actually get a change approved through the... well... let's say, the list.
The problem is the lack of a plan allows one to prevent any change at all.
If I may so, this is exactly how it seems to the community outside p5p:
there is no plan, and nothing is going to change. That's sad.
I don't think it's unreasonable for the starting points to be composed of
the intersection of what hackers would like to see happen. This could
constitute as the general agreement for future features or fixes. That can
later be extended to what some want and others don't object to, or what the
user community suggested or requested.
I think we really should have *something* and not give up because it won't
be perfect. No one will agree on everything, anywhere, ever. Let's at least
try to get the most before we give up because it's not all of it.
>
> - Suppose we do have a list of things that "need to be done". On which
> timeframe? Next major release? Within X year? But if it's something
> that doesn't have to be done quickly, does it really "need to be
> done"?
>
That depends on what works for us. If "by then" doesn't, maybe "when we get
to it" does. Maybe a list will help core hackers focus their efforts
wanting to achieve what more people want, or wanting to help with what many
people desire, or simply knowing a feature won't be a mess to discuss
because it's already in the plan.
When a feature needs to be done, it just needs to be done. You can attach a
time limit ("this is a security issue and must be dealt with ASAP, whether
we like it or not") or you can attach a resource limit ("we can only handle
this when we have enough people who know system X"), but it still falls
under "needs to be done". This is just like a feature that isn't that
necessary. "It would be nice to have this, but we don't care that much
about it". Perhaps someone will fix it, perhaps not.
>
> - Who's going to make things that need to be done actually happen?
> Suppose we have "Perl needs to be able to run on iOS" on the roadmap -
> then what? If there's noone actually doing the work, and noone making
> sure the work actually progresses, a roadmap with lists of things that
> need to be done is not very useful.
>
That also depends on what works for us. If p5p works under "we do what we
have time for and care personally about", that's fine. Perhaps a hacker
decides to work on something which isn't their itch, but they do so because
they realize it's important for the community. Perhaps work could be done
as part of a grant. The fun part is *we* get to decide this, no one else.
A roadmap doesn't have to prevent every other effort, nor does it have to
set time-frames in stone (or cheese, or whatever you set time-frames in).
>
> - IIRC, one of the reasons 5.10 took 5.5 years was that there was some
> kind of idea of the set of features that needed to be in the next
> major release. Which kept people from releasing 5.10 because the
> features weren't done yet. So, our trackrecord with roadmaps isn't
> exactly stellar.
>
Then saying "these have to be finished by version X.Y" doesn't work for us.
Live and learn, but not give up on trying to improve this.
>
> My concern is that the majority of the work on perl itself is done
> by a small set of people; and they all work on their own area of
> expertise/preference/itch. If that doesn't happen to match the roadmap,
> you either have to get them to work on something else, or find new
> people.
>
A roadmap allows hackers to make a more informed decision, and allows other
people to join in.
May I give my example again? I don't have any itch. According to the
current "plan", there is literally nothing I will contribute to p5p. I want
to see what needs to be done. And you know what? I don't care about the
TODO. I care about a prioritized TODO - a plan. The only contribution I've
made to core is ridiculous. It's not completely worthless, but I should
have gone for something that *advances* Perl way more - such as maybe
reworking the testing suite or documenting the C API properly. I didn't,
because I don't know what that will be. I can't find any plan that says
"out of the things you can do, these will be the most useful because they
will allow us to pursue this direction."
I should note that the only reason I even made a contribution is because
Rik had the foresight to make such possible contributions publicly
available on a repo he maintains. This is not a p5p thing, it's a Rik thing.
Thread Previous
|
Thread Next