]> git.donarmstrong.com Git - lilypond.git/blob - Documentation/contributor/administration.itexi
Doc-it: fix the wrong committishes (bad object) in .texidoc files
[lilypond.git] / Documentation / contributor / administration.itexi
1 @c -*- coding: utf-8; mode: texinfo; -*-
2 @node Administrative policies
3 @chapter Administrative policies
4
5 This chapter discusses miscellaneous administrative issues which
6 don't fit anywhere else.
7
8 @menu
9 * Meta-policy for this document::
10 * Meisters::
11 * Administrative mailing list::
12 * Grand Organization Project (GOP)::
13 * Grand LilyPond Input Syntax Standardization (GLISS)::
14 * Unsorted policies::
15 @end menu
16
17 @node Meta-policy for this document
18 @section Meta-policy for this document
19
20 The Contributor's Guide as a whole is still a work in progress,
21 but some chapters are much more complete than others.  Chapters
22 which are @qq{almost finished} should not have major changes
23 without a discussion on @w{@code{-devel}}; in other chapters, a
24 disorganized @qq{wiki-style dump} of information is encouraged.
25
26 Do not change (other than spelling mistakes) without discussion:
27
28 @itemize
29
30 @item
31 @ref{Introduction to contributing}
32
33 @item
34 @ref{Working with source code}
35
36 @end itemize
37
38 Please dump info in an appropriate @@section within these manuals,
39 but discuss any large-scale reorganization:
40
41 @itemize
42
43 @item
44 @ref{Compiling}
45
46 @item
47 @ref{Documentation work}
48
49 @item
50 @ref{Issues}
51
52 @item
53 @ref{Regression tests}
54
55 @item
56 @ref{Programming work}
57
58
59 @end itemize
60
61 Totally disorganized; do whatever the mao you want:
62
63 @itemize
64
65 @item
66 @ref{Website work}
67
68 @item
69 @ref{LSR work}
70
71 @item
72 @ref{Release work}
73
74 @item
75 @ref{Administrative policies}
76
77 @end itemize
78
79
80
81 @node Meisters
82 @section Meisters
83
84 We have four jobs for organizing a team of contributors:
85
86 @itemize
87
88 @item
89 Bug Meister: trains new Bug Squad volunteers, organizes who works
90 on which part of their job, checks to make sure that everything is
91 running smoothly, and has final say on our policy for Issues.
92
93 Currently: Phil
94
95 @item
96 Doc Meister: trains new doc editors/writers, organizes who works
97 on which part of the job, checks to make sure that everything is
98 running smoothly, and has final say on our policy for
99 Documentation.  Also includes LSR work.
100
101 Currently: Graham
102
103 @item
104 Translation Meister: trains new translators, updates the
105 translation priority list, and handles merging branches (in both
106 directions).
107
108 Currently: Francisco
109
110 @item
111 Frog Meister: is responsible for code patches from (relatively)
112 inexperienced contributors.  Keeps track of patches, does initial
113 reviewing of those patches, sends them to @w{@code{-devel}} when
114 they've had some initial review on the Frog list, pesters the
115 @w{@code{-devel}} community into actually reviewing said patches, and
116 finally pushes the patches once they're accepted.  This person is
117 @emph{not} responsible for training new programmers, because that
118 would be far too much work -- he job is @qq{only} to guide
119 completed patches through our process.
120
121 Currently: Carl
122
123 @end itemize
124
125 @node Administrative mailing list
126 @section Administrative mailing list
127
128 An mailing list for administrative issues is maintained at
129 @code{lilypond-hackers@@gnu.org}.
130
131 This list is intended to be used for discussions that should be kept
132 private. Therefore, the archives are closed to the public.
133
134 Subscription to this list is limited to certain senior developers.
135
136 At the present time, the list is dormant.
137
138 Details about the criteria for membership, the types of discussion
139 to take place on the list, and other policies for the hackers list
140 will be finalized during the
141 @ref{Grand Organization Project (GOP)}.
142
143
144
145 @node Grand Organization Project (GOP)
146 @section Grand Organization Project (GOP)
147
148 GOP has two goals:
149
150 @itemize
151 @item
152 Clarify the various development tasks by writing down the polices
153 and techniques and/or simplifying the tasks directly.
154
155 @item
156 Get more people involved in development: specifically, find people
157 to do easy tasks to allow advanced developers to concentrate on
158 difficult tasks.
159
160 @end itemize
161
162 @menu
163 * Motivation::
164 * Ongoing jobs::
165 * Policy decisions::
166 * Policy decisions (finished)::
167 @end menu
168
169 @node Motivation
170 @subsection Motivation
171
172 Most readers are probably familiar with the LilyPond Grand
173 Documentation Project, which ran from Aug 2007 to Aug 2008. This
174 project involved over 20 people and resulted in an almost complete
175 rewrite of the documentation. Most of those contributors were
176 normal users who decided to volunteer their time and effort to
177 improve lilypond for everybody. By any measure, it was a great
178 success.
179
180 The Grand Organization Project aims to do the same thing with a
181 larger scope -- instead of focusing purely on documentation, the
182 project aims to improve all parts of LilyPond and its community.
183 Just as with GDP, the main goal is to encourage and train users to
184 become more involved.
185
186 If you have never contributed to an open-source project before --
187 especially if you use Windows or OSX and do not know how to
188 program or compile programs -- you may be wondering if there's
189 anything you can do. Rest assured that you @emph{can} help.
190
191 @subheading "Trickle-up" development
192
193 One of the reasons I'm organizing GOP is "trickle-up"
194 development.  The idea is this: doing easy tasks frees up advanced
195 developers to do harder tasks.  Don't ask "am I the @emph{best}
196 person for this job"; instead, ask "am I @emph{capable} of doing
197 this job, so that the current person can do stuff I @emph{can't}
198 do?".
199
200 For example, consider lilypond's poor handling of grace notes in
201 conjunction with clef and tempo changes. Fixing this will require
202 a fair amount of code rewriting, and would take an advanced
203 developer a few weeks to do. It's clearly beyond the scope of a
204 normal user, so we might as well sit back and do nothing, right?
205
206 No; we @emph{can} help, indirectly. Suppose that our normal user
207 starts answering more emails on lilypond-user. This in turn means
208 that documentation writers don't need to answer those emails, so
209 they can spend more time improving the docs. I've noticed that all
210 doc writers tackle harder and harder subjects, and when they start
211 writing docs on scheme programming and advanced tweaks, they start
212 contributing bug fixes to lilypond. Having people performing these
213 easy-to-moderate bug fixes frees up the advanced developers to
214 work on the really hard stuff... like rewriting the grace note
215 code.
216
217 Having 1 more normal user answering emails on lilypond-user won't
218 have a dramatic trick-up affect all by himself, of course. But if
219 we had 8 users volunteering to answer emails, 6 users starting to
220 write documentation, and 2 users editing LSR... well, that would
221 free up a lot of current bug-fixing-capable contributors to focus
222 on that, and we could start to make a real dent in the number of
223 bugs in lilypond. Quite apart from the eased workload, having that
224 many new helpers will provide a great moral boost!
225
226 @node Ongoing jobs
227 @subsection Ongoing jobs
228
229 Although GOP is a short-term project, the main goal is to train
230 more people to handle ongoing jobs. The more people doing these
231 jobs, the ligher the work will be, and the more we can get done
232 with lilypond!
233
234 Also, it would be nice if we had at least one "replacement" /
235 "understudy" for each role -- too many tasks are only being done
236 by one person, so if that person goes on vacation or gets very
237 busy with other matters, work in that area grinds to a halt.
238
239 @subheading Jobs for normal users
240
241 @itemize
242 @item Consultant:
243 LilyPond is sometimes critized for not listening to users, but
244 whenever we ask for opinions about specific issues, we never get
245 enough feedback. This is somewhat aggravating.
246 We need a group of users to make a dedicated effort to test and
247 give feedback. If there's new documentation, read it. If there's
248 an experimental binary, download it and try compiling a score with
249 it. If we're trying to name a new command, think about it and give
250 serious suggestions.
251
252 @item lilypond-user support:
253 I think it would be nice if we had an official team of users
254 helping other users.
255
256 @item LilyPond Report:
257 Keeping a monthly newsletter running is a non-trivial task.  A lot
258 of work is needed to organize it; it would be great if we could
259 split up the work. One person could write the Snippet of the
260 Month, another person could do Quotes of the Month, another person
261 could do interviews, etc.
262
263 @item Documentation:
264 Although GDP (the Grand Documentation Project) did great work,
265 there's still many tasks remaining.
266
267 @item Translations:
268 Keeping the documentation translations is a monumental task; we
269 need all the help we can get!
270
271 @end itemize
272
273 @subheading Jobs for advanced users for developers
274
275 @itemize
276 @item Git help for writers:
277 We often receive reports of typos and minor text updates to the
278 documentation. It would be great if somebody could create
279 properly-formatted patches for these corrections.
280
281 Technical requirements: ability to run @ref{Lilydev}.
282
283 @item LSR editor:
284 LSR contains many useful examples of lilypond, but some snippets
285 are out of date and need updating. Other snippets need to be
286 advertized, and new snippets need to be sorted. We could use
287 another person to handle LSR.
288
289 Technical requirements: use of a web browser. LilyPond
290 requirements: you should be familiar with most of Notation
291 chapters 1 and 2 (or be willing to read the docs to find out).
292
293 @item Join the Frogs:
294 "Frogs" are a team of bug-fixers (because frogs eat bugs, and you
295 often find them in Ponds of Lilies) and new feature implementors.
296
297 Technical requirements: development environment (such as
298 @ref{Lilydev}), ability to read+write scheme and/or C++ code.
299
300 @end itemize
301
302
303 @node Policy decisions
304 @subsection Policy decisions
305
306 There are a number of policy decisions -- some of them fairly
307 important -- which we have been postponing for a few years.  We
308 are now discussing them slowly and thoroughly; agenda and exact
309 proposals are online:
310
311 @example
312 @uref{http://lilypond.org/~graham/gop/index.html}
313 @end example
314
315 Below is a list of policies which are not @qq{on the agenda} yet.
316
317 Note that the presence of an item on this list does @emph{not}
318 mean that everybody thinks that something needs to be done.
319 Inclusion in this simply means that one developer thinks that we
320 should discuss it.  We are not going to filter this list; if any
321 developer thinks we should discuss something, just add it to the
322 bottom of the list.  (the list is unsorted)
323
324 As GOP progresses, items from this list will be put on the agenda
325 and removed from this list.  I generally try to have one month's
326 discussion planned in advance, but I may shuffle things around to
327 respond to any immediate problems in the developer community.
328
329 There are some item(s) not displayed here; these are questions
330 that were posed to me privately, and I do not feel justified in
331 discussing them publicly without the consent of the person(s) that
332 brought them up. They will initially be discussed privately on the
333 lilypond-hackers mailing list -- but the first question will be
334 "do we absolutely need to do this privately", and if not, the
335 discussion will take place on lilypond-devel like the other items.
336
337 In most policy discussions in lilypond over the past few years,
338 the first half (or more) is wasted arguing on the basis of
339 incorrect or incomplete data; once all the relevant facts are
340 brought to light, the argument is generally resolved fairly
341 quickly.  In order to keep the GOP discussions focused, each topic
342 will be introduced with a collection of relevant facts and/or
343 proposals.  It is, of course, impossible to predict exactly which
344 facts will be relevant to the discussion -- but spending an hour
345 or two collecting information could still save hours of
346 discussion.
347
348 @warning{The estimated time required for "prep work", and the
349 following discussion, has been added to each item.  At the moment,
350 there is an estimated 30 hours of prep work and 140 hours of
351 discussion.}
352
353 @itemize
354 @item @strong{Patch reviewing}:
355 At the time of this writing, we have 23 (known) patches waiting
356 for review.  Some from main developers; some from new developers.
357 We desperately need more people helping with lilypond, but
358 ignoring patches is the best way to drive potential contributors
359 away.  This is not good.
360
361 (prep: 2 hours.  discuss: 10 hours)
362
363 @item @strong{Official links to other organizations?}:
364 There's something called the "software freedom conservancy", and
365 in general, there's a bunch of "umbrella organizations". Joining
366 some of these might give us more visibility, possibly leading to
367 more users, more developers, maybe even financial grants or use in
368 schools, etc.
369
370 (prep: 2 hours.  discuss: 5 hours)
371
372 @item @strong{Issue tracking with google code}:
373 We use the google issue tracker, but this means that we are
374 relying on a commercial entity for a large part of our
375 development. Would it be better (safer in the long run) to use the
376 savannah bug tracker?
377
378 (prep: 1 hour.  discuss: 5 hours)
379
380 @item @strong{Patch review tool}:
381 Reitveld is inconvenient in some respects: it requires a google
382 account, and there's no way to see all patches relating to
383 lilypond. Should we switch to something like gerritt?
384 @uref{http://code.google.com/p/lilypond/issues/detail?id=1184}
385
386 (prep: 5 hours.  discuss: 15 hours)
387
388 @item @strong{Clarity for sponsorships}:
389 We currently do not advertize bounties and sponsorships on the
390 webpage.  How much advertising do we want, and what type?
391 Should we change the "structure" / "framework" for bounties?
392
393 (prep: 2 hours.  discuss: 10 hours)
394
395 @item @strong{code readability}:
396 "Our aim when producing source code for Lilypond in whatever
397 language is that it should be totally comprehensible to a
398 relatively inexperienced developer at the second reading."
399
400 Rationale:
401 - aids maintainability of code base
402 - "second reading" so newer developers can look up unfamiliar
403   stuff
404 - will help to keep things simple, even if the code is doing
405   complex stuff discourages "secret squirrel" coding, e.g.  "how
406   much functionality can I squeeze into as few characters as
407   possible" "comments are for wimps"
408 - will aid not *discouraging* new developers to join the project
409
410 (prep: 2 hours.  discuss: 10 hours)
411
412 @item @strong{C++ vs. scheme}:
413 what should be in scheme, what should be in C++, what can/should
414 be ported from one to the other, etc.  Questions of
415 maintainability, speed (especially considering guile 2.0), and the
416 amount of current material in either form, are important.
417
418 (prep: 5 hours.  discuss: 15 hours)
419
420 @item @strong{always make an issue number for patches}:
421 there is a proposal that we should always have a google code issue
422 number for every patch.  This proposal is closely tied to our
423 choice of patch review tool; if we switch to a different tool (as
424 suggested in a different proposal), this proposal may become moot.
425
426 (prep: 1 hour.  discuss: 5 hours)
427
428 @item @strong{initalizer lists}:
429 shoudl we use initalizer lists for C++?  AFAIK they make no
430 difference for built-in types, but there's some weird case where
431 it's more efficient for objects, or something.
432
433 Probably not worth making this a weekly thing on its own, but we
434 can probably wrap it up with some other code-related questions.
435
436 (prep: 15 minutes.  discuss: 3 hours)
437
438 @end itemize
439
440 @node Policy decisions (finished)
441 @subsection Policy decisions (finished)
442
443 Here is a record the final decisions, along with links to the
444 discussions.
445
446 @menu
447 * GOP-PROP 1 - python formatting::
448 * GOP-PROP 2 - mentors and frogs::
449 * GOP-PROP 3 - C++ formatting::
450 * GOP-PROP 4 - lessons from 2.14::
451 * GOP-PROP 5 - build system output (not accepted)::
452 * GOP-PROP 6 - private mailing lists::
453 * GOP-PROP 7 - developers as resources::
454 * GOP-PROP 8 - issue priorities::
455 * GOP-PROP 9 - behavior of make doc::
456 @end menu
457
458 @node GOP-PROP 1 - python formatting
459 @subsubsection GOP-PROP 1 - python formatting
460
461 We will follow the indentation described in PEP-8.
462 @uref{http://www.python.org/dev/peps/pep-0008/}
463
464 @itemize
465 @item
466 use 4 spaces per indentation level
467
468 @item
469 never mix tabs and spaces (for indentation)
470
471 @item
472 Code indented with a mixture of tabs and spaces should be
473 converted to using spaces exclusively
474
475 Once this is done, we should add @code{python -tt} to the build
476 system to avoid such errors in the future.
477
478 @end itemize
479
480 There should be absolutely no tab characters for indentation in
481 any @code{.py} file in lilypond git.  All such files should be
482 converted to use spaces only.
483
484 @subsubheading Discussions
485
486 @smallexample
487 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00060.html}
488 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00084.html}
489 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00310.html}
490 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00574.html}
491 @end smallexample
492
493
494 @node GOP-PROP 2 - mentors and frogs
495 @subsubsection GOP-PROP 2 - mentors and frogs
496
497 Nothing much was decided.  The list of responsibilities was
498 slightly altered; see the new one in @ref{Mentors}.  We should
499 encourage more use of the Frogs mailing list.  There's a list of
500 contributor-mentor pairs in:
501
502 @smallexample
503 @uref{https://github.com/gperciva/lilypond-extra/blob/master/people/mentors.txt}
504 @end smallexample
505
506 That's pretty much it.
507
508 @subsubheading Discussions
509
510 @smallexample
511 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00311.html}
512 @uref{}
513 @uref{}
514 @end smallexample
515
516
517 @node GOP-PROP 3 - C++ formatting
518 @subsubsection GOP-PROP 3 - C++ formatting
519
520 Speaking academically, C++ code style is a "solved problem". Let's
521 pick one of the existing solutions, and let a computer deal with
522 this.  Humans should not waste their time, energy, and creativity
523 manually adding tabs or spaces to source code.
524
525 We have modified @code{fixcc.py} to use astyle, along with extra
526 regex tweaks.
527
528 @itemize
529 @item
530 the final script will be run @strong{blindly} on the lilypond
531 source code.  We will accept whatever formatting the final version
532 of this script produces, with no manual tweaking.
533
534 @item
535 patches which have been run through this tool will not be rejected
536 for style reasons.  Any code formatting @qq{desires} which are not
537 enforced by @code{fixcc.py} will not be considered grounds for
538 rejecting a patch.
539
540 @item
541 for now, this style will not be enforced.  It is not cause for
542 concern if patches which do not follow the formatting done by
543 @code{fixcc.py} are pushed.  From time to time, Graham will run
544 the formatter on the entire code base, and commit the resulting
545 changes.
546
547 In a few months, we will tighten up this policy item (with some
548 sort of automatic processing), but that is outside the scope of
549 this policy item and is a matter for later discussion.
550
551 @item
552 after the proposal is accepted, we will leave some time for
553 existing patches to be accepted and pushed.  The script was
554 run on the source code on @strong{2011 August 01}.
555
556 @end itemize
557
558 @subheading GNU code
559
560 LilyPond is a GNU project, so it makes sense to follow the GNU
561 coding standards.  These standards state:
562
563 @quotation
564 We don’t think of these recommendations as requirements, because
565 it causes no problems for users if two different programs have
566 different formatting styles.
567
568 But whatever style you use, please use it consistently, since a
569 mixture of styles within one program tends to look ugly. If you
570 are contributing changes to an existing program, please follow the
571 style of that program. 
572 @end quotation
573
574 (@uref{http://www.gnu.org/prep/standards/html_node/Formatting.html})
575
576 With that in mind, we do not think that we must blindly follow the
577 formatting given by the currrent version of Emacs.
578
579 @subheading Implementation notes
580
581 We can avoid some of the style change pollution in git history by
582 ignoring whitespaces changes:
583
584 @example
585 git diff -w
586 @end example
587
588 @subsubheading Discussions
589
590 @smallexample
591 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00526.html}
592 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00796.html}
593 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00200.html}
594 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00525.html}
595 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00751.html}
596 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00751.html}
597 @end smallexample
598
599
600 @node GOP-PROP 4 - lessons from 2.14
601 @subsubsection GOP-PROP 4 - lessons from 2.14
602
603 @subheading History
604
605 A brief history of releases:
606
607 @multitable @columnfractions .2 .2 .3
608 @headitem date (YYYY-MM-DD) @tab version @tab comment
609 @item 2008-10-28 @tab 2.11.63 @tab nobody checking regtests
610 @item 2008-11-17 @tab 2.11.64
611 @item 2008-11-29 @tab 2.11.65
612 @item 2008-12-23 @tab 2.12.0
613 @item 2009-01-01 @tab @tab somewhere around here, Graham becomes
614 officially release manager, but Han-Wen still builds the actual
615 releases
616 @item 2009-01-01 @tab 2.12.1
617 @item 2009-01-25 @tab 2.12.2
618 @item 2009-02-28 @tab 2.13.0
619 @item 2009-06-01 @tab 2.13.1 @tab note jump in time!
620 @item 2009-06-27 @tab 2.13.2 @tab first Graham release?
621 @item 2009-07-03 @tab 2.13.3
622 @item 2009-09-09 @tab @tab Graham arrives in Glasgow, gets a
623 powerful desktop computer, and begins serious work on GUB (sending
624 bug reports to Jan).  It takes approximately 100 hours until GUB
625 is stable enough to make regular releases.
626 @item 2009-09-24 @tab 2.13.4
627 @item 2009-10-02 @tab 2.13.5
628 @item 2009-10-22 @tab 2.13.6
629 @item 2009-11-05 @tab 2.13.7
630 @item ...
631 @item 2010-01-13 @tab 2.12.3
632 @item ...
633 @item 2010-03-19 @tab 2.13.16 @tab Bug squad starts doing a few
634 regtest comparisons, but IIRC the effort dies out after a few
635 weeks (BLUE)
636 @item ...
637 @item 2010-08-04 @tab 2.13.29 @tab Phil starts checking regtests (BLUE)
638 @item ...
639 @item 2011-01-12 @tab 2.13.46 @tab release candidate 1 (GREEN)
640 @item ...
641 @item 2011-05-30 @tab 2.13.63 @tab release candidate 7 (GREEN)
642 @item 2011-06-06 @tab 2.14.0
643 @end multitable
644
645 @c A graphical display of bugs:
646 @c 
647 @c @image{bugs-2.13-visualization,png}
648 @c @image{zoom-2.13-visualization,png}
649
650 @subheading Carl's analysis of the bugs
651
652 A @file{csv} spreadsheet is available.
653
654 @smallexample
655 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00852.html}
656 @end smallexample
657
658 @example
659 @uref{lilypond-issues-analysis.csv}
660 @uref{lilypond-issues-analysis-trim-duplicates.csv}
661 @end example
662
663 There 148 issues marked with Priority=Critical in the tracker.
664
665 I've done an analysis, and it looks to me like there was initially
666 a backlog of critical issues that weren't fixed, and little work
667 was being done to eliminate critical issues.
668
669 Somewhere about 2010-08-01, critical issues started to disappear,
670 but occasional new ones appeared.
671
672 There were a couple of major changes that introduced unanticipated
673 regressions (new spacing code, beam collision avoidance).  These
674 produced more than the expected number of regressions.
675
676 It appears to me that we didn't really get serious about
677 eliminating critical bugs until about 2010-06-15 or so.  After
678 that point, the number of critical bugs more-or-less steadily
679 decreased until we got to a release candidate.
680
681 Of particular interest, the first release candidate of 2.14 was
682 released on 2011-01-12.  Over the next 10 days, about a dozen bugs
683 were reported and fixed.  Release candidate 2 came out on
684 2011-02-09.   No surge of bugs occurred with this release.
685 Candidate 3 came out on 2011-03-13; we got 2 bugs per week.
686 Candidate 4 came out on 2011-03-29; 2 new bugs.  Candidate 6 came
687 out on 2011-04-07.  We got a couple of bugs per week.
688
689 @subheading Notes, commentary, and opinions
690
691 @example
692 Han-Wen: Overall, I think this cycle took too long
693 Mike: I agree
694 Graham: +1
695 @end example
696
697 @subsubheading Discussions
698
699 @smallexample
700 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-06/msg00797.html}
701 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00364.html}
702 @uref{}
703 @end smallexample
704
705
706 @node GOP-PROP 5 - build system output (not accepted)
707 @subsubsection GOP-PROP 5 - build system output (not accepted)
708
709 This proposal was too broad; after a month of discussion, Graham
710 withdrew the proposal.  Portions of it will be introduced in later
711 proposals.
712
713 @subsubheading Discussions
714
715 @smallexample
716 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00320.html}
717 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00527.html}
718 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00753.html}
719 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01042.html}
720 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00116.html}
721 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00310.html}
722 @end smallexample
723
724
725 @node GOP-PROP 6 - private mailing lists
726 @subsubsection GOP-PROP 6 - private mailing list
727
728 Potentially sensitive or private matters will be referred to
729 Graham.  He will then decide who should discuss the matter on an
730 ad-hoc basis, and forward or CC them on future emails.
731
732 For emphasis, the project administrators are Han-Wen, Jan, and
733 Graham; those three will always be CC'd on any important
734 discussions.
735
736 The lilypond-hackers mailing list will be removed.
737
738 @subheading History
739
740 There is some unhappy history about this idea in our development
741 community:
742
743 @example
744 @uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-09/msg00178.html}
745 @uref{http://news.lilynet.net/spip.php?article121}
746 @uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-11/msg00076.html}
747 @end example
748
749 @subheading Other projects
750
751 The idea of private mailing lists is hardly uncommon in
752 open-source software.  For example,
753
754 @example
755 @uref{http://lwn.net/Articles/394660/}   about debian-private
756 @uref{http://subversion.apache.org/mailing-lists.html}  private@@
757 @uref{http://www.freebsd.org/administration.html#t-core}
758 @uref{http://foundation.gnome.org/legal/}   board members pledge
759 to keep certain matters confidential
760
761 every security team of every linux distribution and OS
762 @end example
763
764 In fact, Karl Fogel's @qq{Producing Open Source Software}
765 explicitly suggests a private mailing list for some circumstances:
766
767 @example
768 [on granting commit/push access to a contributor]
769
770 But here is one of the rare instances where secrecy is
771 appropriate. You can't have votes about potential committers
772 posted to a public mailing list, because the candidate's feelings
773 (and reputation) could be hurt.
774
775 @uref{http://producingoss.com/en/consensus-democracy.html#electorate}
776 @end example
777
778 @subheading Board of governers, voting, etc?
779
780 Many projects have an official board of directors, or a list of
781 @qq{core developers}, with set term limits and elections and
782 stuff.
783
784 I don't think that we're that big.  I think we're still small
785 enough, and there's enough trust and consensus decisions, that we
786 can avoid that.  I would rather that we kept on going with
787 trust+consensus for at least the next 2-3 years, and spent more
788 time+energy on bug fixes and new features instead of
789 administrative stuff.
790
791 Project administrators are Han-Wen, Jan, and Graham.
792
793 @subsubheading Discussions
794
795 @smallexample
796 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg00783.html}
797 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01004.html}
798 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00117.html}
799 @end smallexample
800
801
802 @node GOP-PROP 7 - developers as resources
803 @subsubsection GOP-PROP 7 - developers as resources
804
805 We shall treat developers (and contributors) as
806 @strong{Independent volunteers}: each person does whatever they
807 want, whenever they want.  We have busy careers and lives; we make
808 no expectations of action from anybody (with the exception of the
809 6 people in @qq{Meister} positions).
810
811 @subsubheading Discussions
812
813 @smallexample
814 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-07/msg01092.html}
815 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00087.html}
816 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00497.html}
817 @end smallexample
818
819
820 @node GOP-PROP 8 - issue priorities
821 @subsubsection GOP-PROP 8 - issue priorities
822
823 We will delete the @qq{priority} field of the issue tracker
824 altogether.  The @qq{type} system will be tweaked.
825
826 Type-critical:
827
828 @itemize
829
830 @item
831 a reproducible failure to build either @code{make} or @code{make
832 doc}, from an empty build tree, in a first run, if
833 @code{configure} does not report any errors.
834
835 @item
836 any program behaviour which is @strong{unintentionally} worse than
837 the previous stable version or the current development version.
838 Developers may always use the @qq{this is intentional}, or even
839 the @qq{this is an unavoidable effect of an improvement in another
840 area}, reason to move this to a different type.
841
842 @item
843 anything which stops contributors from helping out (e.g.
844 lily-git.tcl not working, source tree(s) not being available,
845 lilydev being unable to compile git master, inaccurate
846 instructions in the Contributor's Guide 2 Quick start).
847
848 To limit this scope of this point, we will assume that the
849 contributor is using the latest lilydev and has read the relevant
850 part(s) of the Contributor's Guide.  Problems in other chapters of
851 the CG are not sufficient to qualify as Type-Critical.
852
853 @end itemize
854
855 @subsubheading More new/changed types and labels
856
857 Unless otherwise specified, the current types and labels will
858 continue to be used.  The new types introduced by this proposal
859 are:
860
861 @itemize
862
863 @item
864 Type-crash: any segfault, regardless of what the input file looks
865 like or which options are given.  Disclaimer: this might not be
866 possible in some cases, for example certain guile programs (we
867 certainly can't predict if a piece of scheme will ever stop
868 running, i.e. the halting problem), or if we rely on other
869 programs (i.e. ghostscript).  If there are any such cases that
870 make segfault-prevention impossible, we will document those
871 exceptions (and the issue will remain as a "crash" instead of
872 "documentation" until the warning has been pushed).
873
874 @item
875 Type-maintainability: anything which makes it difficult for
876 serious contributors to help out (e.g. difficult to find the
877 relevant source tree(s), confusing policies, problems with
878 automatic indentation tools, etc).
879
880 @item
881 Type-ugly: replaces Type-collision, and it will include things
882 like bad slurs in addition to actual collision.
883
884 @end itemize
885
886 A new label will be added:
887
888 @itemize
889 @item
890 (label) Needs_evidence: it is not clear what the correct output
891 should look like.  We need scans, references, examples, etc.
892
893 @end itemize
894
895 @subheading Reminding users about stars
896
897 We can remind users that they can @qq{star} an issue to indicate
898 that they care about it.  Since we resolved to treat developers as
899 independent volunteers, there is no expectation that anybody will
900 look at those stars, but if any developer want to organize their
901 work schedule according to the stars, they are welcome to do so.
902
903 @subsubheading Discussions
904
905 @smallexample
906 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00019.html}
907 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00277.html}
908 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00413.html}
909 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00624.html}
910 @uref{}
911 @end smallexample
912
913
914 @node GOP-PROP 9 - behavior of make doc
915 @subsubsection GOP-PROP 9 - behavior of make doc
916
917 If there are build problems, then it should be easier to find out
918 why it's failing.  This will be achieved with log files, as well
919 as possibly including scripts which automatically display portions
920 of those log files for a failing build.
921
922 We will also add targets for building a specific manual (for
923 quick+easy checking of doc work), as well as for building all
924 documentation in a specific language (either English or a
925 translated language).
926
927 When you run @code{make doc},
928
929 @itemize
930
931 @item
932 All output will be saved to various log files, with the exception
933 of output directly from @code{make(1)}.
934
935 Note that @code{make(1)} refers to a specific executable file on
936 unix computers, and is not a general term for the build system.
937
938 @item
939 By default, no other output will be displayed on the console, with
940 one exception: if a build fails, we might display some portion(s)
941 of log file(s) which give useful clues about the reason for the
942 failure.
943
944 The user may optionally request additional output to be printed;
945 this is controlled with the @code{VERBOSE=x} flag.  In such cases,
946 all output will still be written to log files; the console output
947 is strictly additional to the log files.
948
949 @item
950 Logfiles from calling lilypond (as part of lilypond-book) will go
951 in the relevant @file{build/out/lybook-db/12/lily-123456.log}
952 file.  All other logfiles will go in the @file{build/logfiles/}
953 directory.
954
955 A single @code{make doc} will therefore result in hundreds of log
956 files.  Log files produced from individual lilypond runs are not
957 under our control; apart from that, I anticipate having one or two
958 dozen log files.  As long as it is clear which log file is
959 associated with which operation(s), I think this is entirely
960 appropriate.  The precise implementation will be discussed for
961 specific patches as they appear.
962
963 @item
964 Both stderr and stdout will be saved in @code{*.log}.  The order
965 of lines from these streams should be preserved.
966
967 @item
968 There will be no additional @qq{progress messages} during the
969 build process.  If you run @code{make --silent}, a non-failing
970 build should print absolutely nothing to the screen.
971
972 @item
973 Assuming that the loglevels patch is accepted, lilypond (inside
974 lilypond-book) will be run with --loglevel=WARN.
975 @uref{http://codereview.appspot.com/4822055/}
976
977 @item
978 Ideally, a failing build should provide hints about the reason why
979 it failed, or at least hints about which log file(s) to examine.
980
981 @end itemize
982
983 If this proposal is accepted, none of these policies will be
984 assumed to apply to any other aspect of the build system.
985 Policies for any other aspect of the build system will be
986 discussed in separate proposals.
987
988 @subheading Don't cause more build problems
989
990 However, there is a danger in this approach, that vital error
991 messages can also be lost, thus preventing the cause of the
992 failure of a make being found.  We therefore need to be
993 exceptionally careful to move cautiously, include plenty of tests,
994 and give time for people to experiment/find problems in each stage
995 before proceeding to the next stage.
996
997 This will be done by starting from individual lilypond calls
998 within lilypond-book, and slowly moving to @qq{larger} targets of
999 the build system -- after the individual lilypond calls are are
1000 producing the appropriate amount of output and this is saved in
1001 the right place and we can automatically isolate parts of a
1002 failing build, we will work on lilypond-book in general, and only
1003 then will we look at the build system itself.
1004
1005 @subheading Implementation notes
1006
1007 There is an existing make variable QUIET_BUILD, which
1008 alter the amount of output being displayed
1009 (@uref{
1010 http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables}
1011 ).  We are not planning on keeping this make variable.
1012
1013 The standard way for GNU packages to give more output is with a
1014 @code{V=x} option.  Presumably this is done by increasing
1015 @code{x}?  If we support this option, we should still write log
1016 files; we would simply print more of the info in those log files
1017 to screen.
1018
1019 The command @code{tee} may be useful to write to a file and
1020 display to stdout (in the case of VERBOSE).
1021
1022
1023 @subsubheading Discussions
1024
1025 @smallexample
1026 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00378.html}
1027 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00703.html}
1028 @end smallexample
1029
1030
1031 @ignore
1032 @n ode GOP-PROP 10 - scheme indentation
1033 @s ubsubsection GOP-PROP 10 - scheme indentation
1034
1035 still under discussion
1036
1037 @subsubheading Discussions
1038
1039 @smallexample
1040 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00625.html}
1041 @uref{https://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg01026.html}
1042 @c @uref{}
1043 @end smallexample
1044 @end ignore
1045
1046
1047
1048 @node Grand LilyPond Input Syntax Standardization (GLISS)
1049 @section Grand LilyPond Input Syntax Standardization (GLISS)
1050
1051 @subheading Summary
1052
1053 @itemize
1054 @item
1055 Start: sortly after 2.14 comes out, which is currently estimated
1056 to happen in January 2011.
1057
1058 @item
1059 Length: 6-12 months.  We're not going to rush this.
1060
1061 @item
1062 Goal: define an input which we commit to being
1063 machine-updateable for the forseeable future.  Any future patches
1064 which change the syntax in a non-convert-ly-able format will be
1065 rejected.  (subject to the limitations, below)
1066 Once this is finished, we will release lilypond 3.0.
1067
1068 @end itemize
1069
1070
1071 @subheading The Problem
1072
1073 One of the biggest complaints people have with lilypond -- other
1074 than silly thing like "there's no gui" -- is the changing syntax.
1075 Now, inventing a language or standards is difficult.  If you set
1076 it in stone too soon, you risk being stuck with decisions which
1077 may limit matters.  If you keep on updating the syntax,
1078 interaction with older data (and other programs!) becomes complex.
1079
1080 @subheading Scope and Limitations
1081
1082 @itemize
1083 @item
1084 tweaks will not be included.  Anything with \override, \set,
1085 \overrideProperty, \tweak, \revert, \unset... including even those
1086 command names themselves... is still fair game for NOT_SMART
1087 convert-ly updates.
1088
1089 @item
1090 other than that, everything is on the table.  Is it a problem to
1091 have the tagline inside \header?  What should the default behavior
1092 of \include be?  When we abolish \times, do we move to \tuplet 3:2
1093 or \tuplet 2/3 or what (for typical triplets in 4/4 time)?
1094
1095 @item
1096 we need to get standards for command names.  This will help users
1097 remember them, and reduce the options for future names (and
1098 potential renamings later on).  \commandOn and \commandOff seem to
1099 work well (should we *always* have an Off command?), but what
1100 about the "command" part?  Should it be \nounVerbOn, or
1101 \verbNounOn ?  Or \verbNotesWithExtraInformationOn ?
1102
1103 @item
1104 we need standards for the location of commands.  Ligature
1105 brackets, I'm looking at you.  (non-postfix notation must die!)
1106
1107 @item
1108 this Grand Project doesn't affect whether we have a 2.16 or not.
1109 The main problem will be deciding what to do (with a bit of
1110 messiness anticipated for \tuplet); we should definitely release a
1111 2.16 before merging _any_ of these changes.
1112
1113 @item
1114 we obviously can't /guarantee/ that we'll /never/ make any
1115 non-convert-ly changes in the basic format.  But we *can*
1116 guarantee that such changes would force lilypond 4.0, and that we
1117 would only do so for overwhelmingly good reasons.
1118
1119 @end itemize
1120
1121 @subheading Workflow
1122
1123 @itemize
1124 @item
1125 We're going to have lots and lots of emails flying around.  The
1126 vast majority won't really fit into either -devel or -user, so
1127 we'll use a list devoted to syntax issues.
1128
1129 @item
1130 Once we have a serious proposal that gained general acceptance
1131 from the separate syntax mailing list, I'll bring it to -devel.
1132 We're not going to make any changes without discussing it on
1133 -devel, but if we're going to have huge threads about English
1134 grammar and silly ideas, and I don't want to clutter up -devel.
1135 Once whatever chaotic silliness on the syntax list is settled
1136 down, I'll bring the ideas to -devel.
1137
1138 @item
1139 as with GDP, I'll moderate the discussion.  Not as with mailist
1140 moderation, but rather by introducing issues at specific times.
1141 We don't want a free-for-all discussion of all parts of the syntax
1142 at once; nothing will get resolved.
1143
1144 @item
1145 Whenever possible, we'll decide on policies at the highest level
1146 of abstraction.  For example, consider \numericTimeSignature,
1147 \slurUp, \xNotesOn, \startTextSpan, and \verylongfermata.  One of
1148 them starts with the name of the notation first (slur).  One has
1149 an abbreviation (x instead of cross).  One has the verb at the end
1150 (On), another has it at the beginning (start).  The adjective can
1151 come at the beginning (numeric, x) or end (Up).  Most are in
1152 camelCase, but one isn't (verylongfermata).
1153
1154 @item
1155 Instead of arguing about each individual command, we'll decide on
1156 abstract questions.  Should each command begin the notation-noun,
1157 or the verb?  Should all commands be in camelCase, or should we
1158 make everything other than articulations in camelCase but make
1159 articulations all lower-case?  Are abbreviations allowed?
1160
1161 @item
1162 Once we've answered such fundamental questions, most of the syntax
1163 should fall into place pretty easily.  There might be a few odd
1164 questions left ("is it a span, or a spanner?"), but those can be
1165 settled fairly quickly.
1166
1167 @end itemize
1168
1169 @subheading Implementation
1170
1171 Nothing until the project is finished, then we declare the next
1172 stable release (2.16.0 or 2.18.0 ?) to be the final 2.x version,
1173 release it, then apply all the GLISS syntax changes and start
1174 testing a beta for 3.0 a week or two later.
1175
1176 @subheading Discussion
1177
1178 Don't respond to any of the specifics yet.  Yes, we all have our
1179 pet irritations (like "what's up with \paper and \layout?!").
1180 There will be plenty of time to discuss them once GLISS starts.
1181
1182 That said, we have a list of specific items that people really
1183 wanted to have written down.  See @ref{Specific GLISS issues}.
1184
1185 @menu
1186 * Specific GLISS issues::
1187 @end menu
1188
1189
1190 @node Specific GLISS issues
1191 @subsection Specific GLISS issues
1192
1193 @itemize
1194 @item
1195 add regtests for every piece of syntax (not one-command-per-file,
1196 but making a few files which, between them, use every single piece
1197 of syntax.)  This is a great test for convert-ly.
1198
1199 @item
1200 should GLISS cover suggested conventions?  (indentation,
1201 one-bar-per-line, etc -- the kind of stuff we list for the
1202 lilypond formatting in the docs ?)
1203
1204 @item
1205 how much (if any) syntactic sugar should we add?  i.e.
1206 @example
1207   \instrumentName #'foo
1208 % instead of
1209   \set Staff.instrumentName
1210 @end example
1211 ?  Carl: maybe yes, Neil: no.  (for example, it fails for
1212 pianostaff)
1213
1214 @item
1215 the values that are used as arguments to common used overrides.
1216 Sometimes they are a symbol (e.g. #'around), sometimes a
1217 predefined variable referring to a Scheme value or object (e.g.
1218 #LEFT, #all-visible ). The main trouble is that for novice users
1219 it is not clear when there should be an apostrophe and when not.
1220
1221 @item
1222 When do we need -\command and when is it just \command ?
1223
1224
1225 @item
1226 Command-line options to the lilypond binary.  -dfoo counts as a
1227 tweak; we won't be trying to pin those down.
1228
1229 @item
1230 @verbatim
1231 \layout {
1232   \context { \Score
1233 % vs.
1234 \layout {
1235   \context {
1236     \Score
1237 @end verbatim
1238
1239 @item
1240 If would be pedagogically simpler to realize this difference if
1241 the syntax was separate if you define a context from scratch (as
1242 is the case with \RemoveEmptyStaffContext) or if it's defined by
1243 adding onto an existing context. For example, a syntax like
1244
1245 @verbatim
1246 \context{
1247  % Copy the current settings of the Staff context:
1248  \use Staff
1249  % do whatever additional settings
1250 }
1251 %%% could be used to distinguish from
1252 \context{
1253  % Take settings from a variable:
1254  \Variable
1255  % do whatever additional settings
1256 }
1257
1258 %%% and
1259
1260 \context{
1261  % Start from scratch:
1262  \type ...
1263  \name ...
1264  \consists ...
1265  ...
1266 }
1267 @end verbatim
1268
1269 @item
1270 Capitalization of identifiers: \VoiceOne ?
1271
1272 @item
1273 @verbatim
1274 %%% Allow
1275 { music expression } * 4
1276 %%% instead of
1277 \repeat unfold 4 { music expression }
1278 @end verbatim
1279
1280 ?  patch here:
1281 @smallexample
1282 @uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00467.html}
1283 @end smallexample
1284
1285 @item
1286 Personally, I find it easier to understand when there's a repeated
1287 8 in the half-bar position; it's much easier to see that you have
1288 two groups of 4:
1289
1290 @example
1291 c8 c c c c8 c c c
1292 %%% instead of one group of eight:
1293 c8 c c c c c c c
1294 @end example
1295
1296 @item
1297 trivially simple bar-lines:
1298
1299 c1 | c1 |
1300
1301 encourage, allow, or discourage, or disallow?
1302
1303 @item
1304 indentation of \\ inside a @{@} construct.
1305
1306
1307 @item
1308 barline checks at the end of line should be preceded by at least 2
1309 spaces?  barline checks should line up if possible (i.e.  if you
1310 can use less than 4, 8, X empty spaces before a barline check to
1311 make them line up?)
1312
1313 @item
1314 Why doesn't \transpose respect \relative mode?
1315
1316
1317 @item
1318 on \score vs. \new Score
1319
1320 But in the light of a consistent syntax and semantic, I see no
1321 reason (from the users POV) to disallow it.  After all, the real
1322 top-level context is a \book @{@}, isn't it, and I don't see a point
1323 in disallowing a \new Score construct just like \new Staff.
1324
1325 From a syntactical POV, I see the following pros for \new Score:
1326 - You can write \with @{ ... @} for every other context but \Score,
1327 which (for consistency) should also work with \new Score.
1328 - When there's a \new Foo Bar, there's also a \context Foo Bar,
1329   which makes the same as a parallel instantiation of all Bar's.
1330 - [Quoting Rune from
1331 @uref{http://www.mail-archive.com/lilypond-devel@@gnu.org/msg14713.html}
1332   "I know that the \score-statement is a syntactical construct,
1333 but I think it would be nice to hide this fact from the users.  I
1334 think we could make the use of score-block much more intuitive if
1335 changing the syntax to \new \Score and adding an implicit
1336 sequential-statement to the score."
1337
1338
1339 @item
1340 Discussion on
1341 @uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
1342 about \new vs. \context.
1343
1344
1345 @item
1346 Let users add their own items to the parser?  comment 11 on:
1347 @uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
1348
1349 @item
1350 should engravers be pluralized (note_heads_engraver) or not
1351 (note_head_engraver) ?
1352
1353 @item
1354 should we allow numbers in identifier names?  Issue:
1355 @uref{http://code.google.com/p/lilypond/issues/detail?id=1670}
1356
1357 @item
1358 should we officially allow accented characters?  in general, how
1359 do we feel about utf-8 stuff?
1360
1361 @item
1362 for the sake of completeness/simplicity, what about *disallowing*
1363 the "one-note" form of a music expression?  i.e. only allowing
1364 stuff like
1365 @verbatim
1366   \transpose c d { e1 }
1367   \transpose c d << e1 >>
1368 @end verbatim
1369
1370 and never allowing
1371 @verbatim
1372   \transpose c d e1
1373 @end verbatim
1374
1375 @item
1376 What should be the officially encouraged way of writing music for
1377 transposing instruments? Maybe it should be simplified?
1378 See http://lists.gnu.org/archive/html/lilypond-user/2011-07/msg00130.html
1379
1380 @end itemize
1381
1382
1383 @node Unsorted policies
1384 @section Unsorted policies
1385
1386 @subsubheading Language-specific mailing lists
1387
1388 A translator can ask for an official lilypond-xy mailing list once
1389 they've finished all @qq{priority 1} translation items.
1390
1391 @subsubheading Performing yearly copyright update (@qq{grand-replace})
1392
1393 At the start of each year, copyright notices for all source files
1394 should be refreshed by running the following command from the top of
1395 the source tree:
1396
1397 @example
1398 make grand-replace
1399 @end example
1400
1401 Internally, this invokes the script @file{scripts/build/grand-replace.py},
1402 which performs a regular expression substitution for old-year -> new-year
1403 wherever it finds a valid copyright notice.
1404
1405 Note that snapshots of third party files such as @file{texinfo.tex} should
1406 not be included in the automatic update; @file{grand-replace.py} ignores these
1407 files if they are listed in the variable @code{copied_files}.
1408
1409
1410 @subsubheading Push git access
1411
1412 Git access is given out when a contributor has a significant
1413 record of patches being accepted without problems.  If existing
1414 developers are tired of pushing patches for a contributor, we'll
1415 discuss giving them push access.  Unsolicited requests from
1416 contributors for access will almost always be turned down.
1417