Re: Guile project submissions draft

[Greg Harvey <Greg.Harvey@thezone.net>]

Klaus Schilling <Klaus.Schilling@home.ivm.de> writes:

> Greg Harvey writes:
>  > 
>  > This is a hastily jotted format for the email submission
>  > format. Ideas, advice, and opinions appreciated (let's try to keep it
>  > at least pg-13, though ;')
> 
> What is pg-13? something to do with GNU Privacy Guard?

Movie rating... they generally don't include hard-core profanity,
which was the point I was obtusely getting at.

>  > %name (name of project): Must be unique.
> 
> How would this be achieved? Maybe something like emacs does when encountering
> several buffers with the same name, giving an automatic enumeration?

Actually, I think it would be better to force uniqueness, so what
would happen if you were submitting a project with the same name as a
current one is that you won't have the right password or public key to
update it, and you'd get a reply like:

Couldn't update project [name]. Check that:

1) [name] isn't already used for an existing project.
2) You aren't being a loser and trying to screw with someone else's
   project.

>  > a paragraph) of the project. 
>  > 
>  > %author (name): the main author of the project (should this be authors?)
>  > 
> Would multiple appearances of this field be possible?

I think it might be better to change this to authors, and have this be
a set of entries like:

%authors (A guy <a.guy@some.place>, A second guy, A gal, Someone's Cat)
(email addresses are optional).

>  > %contact (addr): an email contact for the maintainer (should this be
>  > folded into author(s)?)
>  >
> What if authors and maintainers are different? May a mailing list be used
> here? 

Actually, I think a %mailinglist field would be best, which would
contain the mailing list address, and instructions on exactly how to
subscribe. If this is the only contact desired, then contact doesn't
have to be given.

%mailinglist (project@someplace.org; send mail to
	     project-request@someplace.org with Subject: subscribe to
	     subscribe to the list.)

or (for more complex projects)

%mailinglist (project-user@someplace.org is the list for users of
	      project, project-devel@someplace.org is for people
	      working on the project, bug reports, and discussion of
	      new features. 
	      
	      Send mail to project-request@someplace.org with Subject:
	      subscribe project-user [email] or subscribe
	      project-devel [email] to subscribe to one of the lists.)

>  > %status (status): the status of the project (maybe this should be
>  > called news? I'd expect that you'd want to update this whenever
>  > something interesting happens)
> 
> So this should be more precise than just expressions like `planned' `alpha' 
> `beta' `pre-release' `stable' `abbandoned' ?

It doesn't have to be. My thinking is that you'd want something fairly
short here, with more information at the webpage or in a file at the
ftp site (so you could put a link in there to
ftp://some.place/project/Changes).

A sample from my text buffers would probably go like this

%status (This are at best alpha quality right now... see
http://www.thezone.net/~gharvey/guile/tbuffers-braindamage.html for
all the gory details. A new release has been coming soon for a while
now, which should fix the more insane problems.)

That link doesn't actually exist right now, but it probably should ;)

>  > 
>  > %help_wanted bool: indicates whether additional programmers are
>  > wanted/needed. 
>  > 
>  > %testers_wanted bool: indicates whether the project wants people to
>  > test (this may be a bit superfluous).
> 
> What when help or testers are wanted especially for certain purposes,
> such as ports for some platforms, or request for a server machine to 
> run the software on?

Yeah, those will be changed to descriptions of exactly what's
wanted.

> > 
> 
> How about some example? 
> A HYPOTHETICAL one:
> %start
> %name (guilemacs)
> %password (guessme)
> %location (ftp://ftp.gnu.org/pub/gnu/guilemacs-1.0)
> %category (application)
> %description (patches for GNU Emacs 22.0 or above , enabling it to use
> 	     guile as the macro language. Contains a translator from
> 	     emacs lisp to guile, which can be invoked on the fly or
> 	     precompiling to a dynamically linkable guile module.
> 	     The latter feature requires Hobbit-4.0 or better.)
> %author (Richard M. Stallman)
> %contact (bug-emacs@gnu.org)
> %status (The direct emacs lisp reader feature is now stable on all Posix
> 	3.0 Platforms and the GNU Hurd 2.0.* or better. The library module 
> 	generator is yet experimental, but turned sufficiently stable on 
> 	the GNU Hurd 2.1.17)
> %help_wanted true
> %testers_wanted true

Exactly (the format looks rather clean, too, which I think's an added
bonus). I've added an example for guile in the doc, which I'll post in
a little bit after I finish going through the replies.
 

-- 
Greg