What happened to the formatting of this email? It looks like section numbers are in wrong places and generally i'm getting lost while reading. If you have it in a text file or something, could you send it as an attachment?
cheers, Janek On Tue, Jun 19, 2012 at 2:32 PM, Graham Percival <gra...@percival-music.ca> wrote: > *** Project Requirements > > Requirement Source questions and implications for LilyPond > All authors of more than 15 lines of code need to be listed > somewhere. 6.3 can we cover this requirement by pointing > people at the git history? (answer: maybe for full source, but not > for tarball) > Hopefully we can automate this process to some degree with git? > Must have a copyright notice for all files longer than 10 lines, > including documentation, supporting files, images and sound files > (if the metadata allows this, or in a README or similarly-named > file in the same directory if not). Using a minimal form (such as > in Emacs and Elisp manuals) is ok. “Recursive” permissions (i.e. > “everything in this directory tree” are not ok. > Copy ranges are only acceptable if every year is really a > “copyrightable” year and if the README file details this usage. > Must use the “or any later version” license. > Copyright headers for each file do not need to include everybody > who edited the file, only the main copyright holder(s). 6.5 > This will take at least 10 hours to implement. > All features must work on GNU/Linux; other operating systems are > optional 8 nothing stops us from also requiring > features to work on other operating systems, so Windows and OSX > users don’t need to panic. > keep backups of source files, but git is sufficient for this 10 > on self-hosted websites, ensure that the site runs on Free > software alone. (unreleased custom software is ok) 12.2 > AFAIK lilypond.org is ok > don’t link to a website about lilypond, which the public might > perceive as connected with it and reflecting the position of its > developers, unless it also runs on free software. (unreleased > custom software is ok) 12.2 > avoid patented technologies as specified by GNU. For example, mp3. > 13 There is no definitive list of such patent-crippled > things, rather this is a general reminder to avoid things which > are known to be crippled. > do not recommend any non-Free programs, nor require a non-free > program to build 13 I’d better check the licenses of > the “Easier editing” programs. > do not refer to any non-Free documentation for Free software 13 > I think we’re fine here > do not use the term “open source”, instead of “Free software” > 14.1 German website main page not in compliance. > do not write “Linux”, instead write “GNU/Linux” (unless we are > specifically talking about the kernel) 14.2 the download pages > on the website need to be fixed. > > > *** Project Recommended > > Requirement Source notes and questions > assign copyright to FSF (this adds a bunch of obligations not > listed in this document) 6.1 we’re not going to do > this. > Thank everybody who reports a bug, but no requirement to help > users directly instead of improving code 9.3 I think > the Bug Squad already does this, but maybe add it to the Bug Squad > checklist? :) > Also, remind the two grumpy developers that they shouldn’t reply > to bug reports unless they feel amazingly un-grumpy that day. > use ftp.gnu.org for official source releases 11.3 would > require 10 hours of work; not worth it IMO > announce stable releases on info-gnu 11.6 do-able if > somebody makes a list of places to announce new stable releases. > http://code.google.com/p/lilypond/issues/detail?id=1719 > post release announcements on the savannah project site > would take 5-10 hours to set up > web pages should include manuals in HTML, DVI, Info, PostScript, > PDF, plain ASCII, and Texinfo format (source) 12.3 Ouch. dvi, > postscript, and plain ASCII? > make a diff between releases 11.2 let’s not bother; > interested parties can make a diff themselves from git. > manuals should be listed at http://www.gnu.org/manual as well as > our own website 12.3 points to old website docs; I need to find > out how to update this link. > if feasible, use Guile for extensions, although “For some programs > there’s a reason to do things differently, but please use GUILE if > that is feasible.” (email to new maintainers, not in the > guide yet) > > > *** Maintainer required > > These apply to the GNU maintainer(s) personally, not for normal > project members. > > Role of GNU maintainer (section 5): > > ... you cannot expect all contributors to support the GNU > Project, or to have a concern for its policies and standards. So > part of your job as maintainer is to exercise your authority on > these points when they arise. No matter how much of the work other > people do, you are in charge of what goes in the release. When a > crucial point arises, you should calmly state your decision and > stick to it. > > Requirement Source notes and questions > get an account on fencepost.gnu.org 3 > inform GNU when stepping down 4 > if using savannah, subscribe to savannah-announce mailing list 10 > in interviews and speeches in your role as GNU maintainer, don’t > include advertisements for any company, product, or service. > (previous rules about “open source” still apply) 15 > > > - Graham > > _______________________________________________ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel