Arend wrote: > In particular, I would think it could obsolete our patches.html page. > This needs more discussion, of course.
There are two more resources which give superior functionality with less work than the corresponding parts of patches.html. 1. http://trac.gnugo.org/gnugo/report/9 (linked as "Pending patches" from the front page http://trac.gnugo.org). This lists all pending patches entered as tickets. 2. http://trac.gnugo.org/gnugo/log/?verbose=on (linked as "Recent CVS commits" from the front page). This shows all recent CVS mainline commits (mirrored to a subversion repository) with commit messages and links to the actual diff that went into CVS. To see how these differ in functionality and work, consider for 1 the case that someone submits a patch to the mailing list which we want to list as pending. With patches.html: a) Wait until it has reached the archive. b) Locate the URL in the archive. c) cvs update patches.html d) Add the archive link and a description in patches.html e) cvs commit patches.html With trac, alternative 1: a) Wait until it has reached the archive. b) Locate the URL in the archive. c) Click on new ticket. d) Fill in the ticket, including link to mail archive in description. e) Click on submit ticket. With these use cases there's a similar amount of work but I would say that trac is slightly faster. There's a major difference however; with patches.html only the maintainers can do the work, with trac anyone can do it, in particular the submitter of the patch. Moreover trac allows other approaches, including entering the patch directly as a ticket, bypassing the critical step a (it's easy to forget about it when you can't do it immediately) and the relatively time consuming step b. There are potential drawbacks with this method, related to the mailing list not being involved, which are worth discussing. They are not relevant to the question of the merits of patches.html, however, so for now I'll just state that using trac for this purpose is no more work, can be done by more people, and gives more options for the future. For 2, the list generated in trac has less information (only patch name) than patches.html (also describing text) for many of the older commits. To get full information the describing text needs to be included in the commit message, which is good practice anyway. A comparison of the work involved gives a clear picture. With patches.html, only patch name in commit message: a) cvs commit -m "patch name" b) cvs update patches.html c) Add link, patch name, and describing text in patches.html d) cvs commit patches.html With trac, patch name and describing text in commit message: a) cvs commit -m "patch name, describing text" Well, I'm probably partial, so please voice any concerns. However, I'm strongly of the opinion that we should get rid of the extra work involved in maintaining patches.html with lists of patches. /Gunnar _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
