On Sun, Feb 06, 2011 at 11:41:13PM +0100, Reinhold Kainhofer wrote: > > This has been raised a few times, and will be discussed in GOP. At the > > moment, > > - undoc'd new features do not block a stable release > > - we can see alterations to regtests with diff, and therefore figure out > > what's new since 2.12.3. > > Not always. That mainly holds for bugfixes, while most new features will add > a new regtest, which does not show up in the diff.
Well, I'm sure there's some git instruction that will list all added files between revisions. > So I would prefer it if the developer writes some raw > documentation, which can then be improved by a dedicated doc > writer. There's five questions in my mind. 1) should we reject a patch which does not have complete documention? (IMNSHO: no) 2) once a code patch has been accepted, should we harass the contributor to write documentation? (IMNSHO: no. We should never harass any individuals. I readily admit to putting pressure on the bug squad, and the development team as a whole (via the "48-hour patch" emails), but nobody "owes" anything to lilypond. Patches are contributed with no warrantee or expectation of future work) 3) once a code patch has been accepted, should we reject any doc patch written by the programmer? (no, of course not! If a programmers *wants* to write docs, then of course that's great! I'm sorry if I was unclear about this) 4) once a code patch has been accepted, should we immediately add a doc-issue to the tracker for missing docs? (this one is arguable; at the moment I don't see the point of doing this, but if somebody is very excited about some particular piece of missing docs and enjoys playing with the google tracker, I'm not going to stop them) 5) once a code patch has been accepted, should we block any stable release until it has documentation? (this one is debateable, but the answer for 2.14 is a firm "no". During GOP, we will discuss this, and so the answer may be different for post-2.14 releases) Cheers, - Graham _______________________________________________ bug-lilypond mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-lilypond
