New SRFI process proposal

Recently, one of the SRFI editors declared that he'll retire SRFI. When I read the post on c.l.s., it was shocking to me and on the same time I saw how much burden it was even he wasn't really a member of Scheme community for many years. Thank you so much for your service.

I think SRFI is one of the most important things for Scheme community. It can be pre-standard (see R6RS and R7RS-large). As a Scheme user, it is useful and convenient to write portable libraries. I can use it and just put a note that says this library requries SRFI-n. (well, if you aren't interested in writing portable libraries, then not that much. But I am.) So I hope it remains.

Needless to say, there are bunch of problems on the current SRFI process (not really the process but I use the word). Most of them are listed here. In short, it is heavily relied on only one person. If someone is willing to take over, then history might repeat again. So, in my opinion, we would need a new process.

How about using GitHub? GitHub has the ability to generate a web site. So finalised SRFIs can be located there. For new drafts, SRFI editors can create a new repositories for them and give the authors to commit right so that they can update their SRFI by themselves. The discussion can be done by issue based. All issues need to be closed before finalised. If mailing list is wanted, then  we can use Google group.

What can be the pros and cons for this? I can think of some.

  • No maintenance needed for server machine
  • Reducing the task of SRFI editors
    • making repositories
    • finalising SRFIs
  • More open
  • Easy to hand over
  • Too open?
  • Less control
  • Trusting SRFI authors too much?

In my opinion, the process should be outsourced as much as possible and amount of task for SRFI editors should be as less as possible.

Who should do it? Well, I would like to say 'me' but due to the personal reasons and luck of knowledge (especially domain transfer), it's kinda hard. (if I can, then earliest would be after October this year.) Plus, I'm not sure if this approach is acceptable for other Schemers. So for now, just thinking about it.


Shiro Kawai said...

Hmm? My comment seems to went void. So here's another try.

I second for github. Github organization seems to have enough features for the main site. Mailing list needs some more consideration---Google groups is one choice, but I kind of like the current pre-finalization/post-finalization archiving. Anyway we can gradually move things. I'm willing to do the chores.

danly said...

My comment went to the void as well. Heh.

Consider MELPA: it is an Emacs package repository that operates through GitHub. Packages developers send pull requests to have their work included in the repository. This is precisely the sort of thing I wish to do with Scheme/R7RS.

I've been raising the issue on #chicken, largely because it is amongst the more talkative and active Scheme IRC channels, and discovered that I'm not alone in wanting a multi-Scheme R7RS package repository. Seth Alves and Alex Shinn, amongst others, have been collaborating on Snow2. Seth has developed snow2-client, which works on virtually all the known R7RS-compliant Schemes, and pulls data from an aws-hosted repository.

I'd like to modify snow2-client to support pulling from a git-hosted repository, which seems to be the path of least resistance to attaining the goal you describe in your post.

Anyhow, I've just created a GitHub Team for the purposes of collaborating on this. If you're interested, or you simply wish to say "Hey, great idea, keep in touch, but I haven't the time." Please, do drop me a line.


danly said...

You can find me on as 'danly' on freenode.

kei said...

Hmmm, those are not even in spam box so no idea what happened.

> Shiro
I also like the pre/post finalisation/withdrawn thing so if we can get it, I would like to have it. I think details need to be discussed somewhere public (on my blog is fine as well :), though can't expect a lot of Schemers are reading... )

> danly
On my understanding, SRFI and package repositories are kinda different thing. I agree that Scheme should have common repository which implementations can use. But SRFI itself can be used to discuss next Scheme standard as well, which may require something can not be written in portable Scheme code (e.g. SRFI-18). To discuss these things, it is better to keep it, I think.

I'll check freenode :)

Post a Comment