Hi folks!
I had this idea to ask implementators how they'd feel inclined about including Alexandria as part of their implementations as most nowadays do with ASDF.
For that to work, of course, there has to be Alexandria releases, and once something's officially released, backwards-compatiblity would have to be preserved. (I think there should be an official ALEXANDRIA package containing the stable API, and some -TESTBED or -BETA package with stuff being in flux, but for people to try out who are so inclined. Together with some ALEXANDRIA-VERSION<= stuff for conditionalization.)
I'd offer to step up, polish the existing code base, write tests where needed, write documentation, do releases, and try to push the things down the implementations. I'd hope that the quality of my existing libraries speak for how severe I take all these steps to produce well-rounded releases.
Nowadays, it's my impression that the only somewhat active people are Nikodemus and Attila, where Nikodemus seems to hold the power of ultimate decision making.
There are probably more who feel strongly about Alexandria so I wanted to ask you first, because it'd mean a shift of responsibility and power.
What do you think?
-T.
On 1 March 2010 14:47, Tobias C. Rittweiler tcr@freebits.de wrote:
I had this idea to ask implementators how they'd feel inclined about including Alexandria as part of their implementations as most nowadays do with ASDF.
This has always been in the long term gameplan.
For that to work, of course, there has to be Alexandria releases, and
I would settle for a single release, for now. :)
once something's officially released, backwards-compatiblity would have to be preserved. (I think there should be an official ALEXANDRIA package containing the stable API, and some -TESTBED or -BETA package with stuff being in flux, but for people to try out who are so inclined. Together with some ALEXANDRIA-VERSION<= stuff for conditionalization.)
Something along these lines has always been the plan.
Specifically: each released version of Alexandria will have as the package name ALEXANDRIA.N, which N is a version number. When Alexandria is loaded, if that version of Alexandria is the newest version in core, it will grab the nickname ALEXANDRIA. Non-release versions will have a package name that clearly indicates so.
(Details non-important, really, but I'm pretty sure package versioning along those lines is TRT for Alexandria.)
I'd offer to step up, polish the existing code base, write tests where needed, write documentation
For conservative changes I'm fine with giving you commit access. (Fixing bugs, adding tests, improving documentation, etc.)
For more adventurous stuff -- actually changing or adding stuff, hash it on the mailing list first. Because I attribute the success of Alexandria so far to the fact that its development has mostly been very conservative, I would suggest that unless there is a clear "yes!" from other stakeholders those changes should not go in at this point.
(Partly because I feel there is already too much stuff in Alexandria.)
I think the single most important thing to do is to complete the API review of Alexandria. This must happen here on the list. (See package.lisp for the sad state of that review -- 3 down, over 100 to go. Not every symbol needs to be reviewed separately, though -- related things can be reviewed in a bundle.)
It would be really great if you (and others who have the time & energy) could step up to this.
1. Take a function/macro or few.
2. Look at their API and documentation critically & fix obvious problems without changing them backwards incompabtibly. (We're not really afraid to break at this point yet, but we do want to avoid doing it needlessly -- Alexandria is already used in enough places that breaking things without a good reason is really bad PR.)
3. Post summary of the situation (including lambda-lists and docstrings) to the list, including your recommendation: Finalize(as-is)/Refactor(how?)/Remove/whatever.
4. Give people a week or two to respond. With luck we can call the items "good enough", with less luck we disagree with each other in which case we have to find a compromise or agree to drop the items from Alexandria. (I've said it before, and I say it again: I consider Alexandria a raging success if it ends up just containing ONCE-ONLY and WITH-GENSYMS plus coouple of aliases for those in released form...)
do releases, and try to push the things
Unless there is clear consensus that the doing a reasonably complete API review of Alexandria before release is a bad idea, I'm unwilling to allow a release until it has been completed.
Ideally after the release Alexandria would not need to see much more twiddling than TeX for the next few years, until there is sufficient pressure to do something better.
Nowadays, it's my impression that the only somewhat active people are Nikodemus and Attila, where Nikodemus seems to hold the power of ultimate decision making.
I'm the project owner, yeah, but vetos several people hold are real despite them not getting much exercise. I'm ok with handing out a bunch of additional vetos to sane people, if you have some suggestions. IMO those people should be more in the influentia Alexandria _user_ category than Alexandria hacker category, though.
There are probably more who feel strongly about Alexandria so I wanted to ask you first, because it'd mean a shift of responsibility and power.
Having been thinking about this for a while, I'm fine giving out practical responsiblity and power to people who have more time and energy than me. In other words, commit bits can be had.
However, as is probably clear at this point, I'm unwilling to let the reigns go until I see clear evidence that the person to pick them up has a vision compatible to mine, and has a vote of confidence from the veto-holders. It may be that my reticence on this count is ill-adviced, and I do have some misgivings about it -- but that's where I stand right now.
Cheers,
-- Nikodemus
alexandria-devel@common-lisp.net