Front page | perl.perl5.porters |
Postings from September 2014
>
> 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.
- 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"?
- 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.
- 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.
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.
Regards,
Abigail
Thread Previous
|
Thread Next