Re: [gnugo-devel] CCs on trac.gnugo.org not functional

[Gunnar Farnebäck]

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