I couldn't agree more. I have always fe;t that we went into a deprecation policy far too early and this is holding parrot development back.
I would recommend that we scrap the deprecation policy and try and move forward. We need to make sure that we have a good liaison with HLL;s, particularly rakudo. Fix things as needed and make sure that they are good for our monthly releases, which I think we should continue with, avoiding emphasizing other releases at the moment until we have something much more stable. Cheers, Michael (mikehh) (For some reason I seem to have sent this to Darren, rather than to the list - correcting now) On 5 September 2011 22:02, Christoph Otto <[email protected]> wrote: > masak made the offhand remark in #perl6 recently that I used as the > title of this message. Now that I'm done giving State of the Parrot > talks, I'm free to take off my optimist hat and realize that Parrot is > going to die a slow death if we don't do something drastic. I love the > vision that Parrot has, so as architect I want to do what's needed to > make it kick ass. > > First of all, Parrot isn't mature and stable enough to justify our > deprecation policy. Mature projects with a stable API and lots of > production users need a deprecation policy like ours. We need to take > out the trash. Parrot has evolved from a heritage where it was > acceptable for our C interface to be a batch of poorly-encapsulated > functions that poked into Parrot's internals in a fairly indiscriminate > way. Until we've moved completely away from the code from that era, we > need to get that mentality out of our tree. We have all kinds of junk > that we're "supporting" because it happened to exist when we adopted our > policy, and us keeping it around isn't doing ourselves any favors. We > need to start thinking of DarkPAN for Parrot as a fairy tale and avoid > invoking its name in policy discussion. We can only help users when we > know they exist. Silent users will have to either make themselves known > or deal with it. > > The right solution for Parrot is to break things and fix them as needed > in users' projects. This implies some infrastructure to detect HLL > breakage. Since we can't seem to come up with a proper infrastructure, I > hacked together tools/dev/all_hll_test.pl. It's a barely-maintainable > script to glue HLL build processes together in the most delicate and > brittle way possible which doesn't involve magnets and a slingshot. It's > guaranteed not to work on all platforms, but it will be good enough > point out when tests fail in HLLs. It also tries to provide enough > logging that you don't need to go back and re-run the test suite again > to find out what exactly broke. If it doesn't, see the next paragraph. > > Improvements to the script are welcome, especially the addition of every > single HLL and library which can be expected to pass its test suite. > It's my sincere hope that the script is painful enough to use that we'll > be forced to find something better. If not, we can at least require an > all_hll_test run before any non-trivial branches get merged. > > Additionally, teams as a requirement are a distraction. We have a > handful of full-timeish developers. git-summary lists 30 developers > who've pushed to parrot.git since 3.6.0 was cut, including duplicates. > The number is 11 for those with 10 or more commits. For a project of > Parrot's size, the team-based structure is a poor fit. The redundancy we > tried to accomplish with teams is a good thing and their dissolution > does leave us open to the possibility that a role will go unfilled. The > solution is to react to our shortcomings as they become problems. We can > create, retire and reassign roles as the need arises. We have a smart > bunch hacking on Parrot; we'll figure it out. > > I'm also convinced that we're trying to impose too much structure on > Parrot in the way we implement roadmap goals. We've gone through the > motions of putting together roadmap plans, but we all individually tend > work on what we see as important. Starting with the next PDS, I would > like to dissolve most of the formality involved in roadmap goals. > They'll still need to be mostly well-defined and completable, but > that's it. A brief one-sentence goal like "move imcc out of libparrot" > is perfectly acceptable, if the hacker proposing it is capable. > Anything between a sentence and an essay is fine, if it describes a > completable goal. > > The next year or two will be a much more turbulent time for Parrot as we > start tearing down and rebuilding Parrot. It will be harder to predict > what the Parrot of January 2012 will look like and harder to form goals > around it. That said, roadmap goals are useful and there's value in > long- > term planning and execution. Still, few teams meet their roadmap goals > 100%. If we don't, Parrot will continue. If an important goal slips, > we'll reschedule. If it ends up being unnecessary, we can drop it. > > While I'm cutting down our roadmap goals, I also need to add one. HLL > interoperability is a core feature of Parrot that's been broken/missing > since 2008. We need to get it documented and working again, and it needs > to be a roadmap goal even if doesn't have a champion. HLL interop is a > core differentiator of Parrot, a major selling point, and for HLL > implementers something that no other VM can offer. We need to make this > happen if Parrot is to have a distinguising feature that will attract > users apart from hosting Rakudo. If we can't get Tene++ motivated enough > to get on this, someone else needs to pick up where he left off. HLL > interop is too important to drop. > > All of this might seem to put M0 into question. We need a better Parrot > right now in addition to a much better Parrot after M0, Mole and Lorito > land. I'll be continuing to lead the M0 effort, but will be putting more > emphasis on improving Parrot's existing internals and ensuring a > coherent vision as we move forward. M0 isn't magical fairy dust that we > can sprinkle on bad code to turn it into good code. Parrot will need a > number of changes before moving 100% to M0 becomes possible, and those > changes need as much attention as anything. > > Finally, this begs the question of what we expect users to build their > code on. We're going to be gutting PIR, but that doesn't mean we don't > want anyone building on Parrot. We will be recommending the use of > languages and libraries like nqp, Winxed and Rosella as the primary > interface for user-level interaction with Parrot. We will test these > mid- > level languages extensively and ensure that they continue to work and > provide a stable foundation that people can use to build awesome things. > > masak's full send on #perl6 was "well, Parrot is a foundering project on > top of a wonderful vision. meaning, it could still be great if it gets > its act together. M0 could be that, who knows?" I agree with this. > Parrot's goal of being a top-flight VM for self-hosted interoperable > languages is a great vision worth working toward. We as a project need > to get our act together, but we have a talented and motivated group of > hackers. We can build Parrot into what it should be, and I'm excited to > help make it happen. > > Thanks, > Christoph > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev > -- Michael H. Hind Cell: +44 (0) 7877 224 745
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
