cvs commit: doc/en_US.ISO8859-1/articles/committers-guide article.sgml doc/en_US.ISO8859-1/articles/releng article.sgml doc/en_US.ISO8859-1/books/developers-handbook/policies chapter.sgml

[Gabor Kovesdan]

>  No offense and no explicit objection from me here.  I am just nervous
>  about handling this sort of information which can be used in our
>  document more than once.
>   
Yes, I agree, that would be nice to have, especially because that 
detailed contributors list as a single DocBook document looked well.
> Gabor Kovesdan <gabor at kovesdan.org> wrote
>   in <48A8001E.1000104 at kovesdan.org>:
>
> ga> separately, so I think it would be complicated to implement. I think
> ga> there are other overlapping parts, like &os; and the current release
> ga> entities. Maybe it would make sense to separate them to a common part
> ga> somehow and use it for the web and the doc?
>
>  Yes, I think we should go for that direction somehow.  And in a long
>  term, maybe we should merge www and doc into a single repository
>  (like www/en -> doc/en_US.ISO8859-1/htdocs or so) because of making
>  reuse of information easier.  Currently www build heavily depends on
>  doc tree (www only build can be done but the result is not complete),
>  so I think the merged repository with an option for htdocs-only build
>  would also work without a serious problem.
>   
Good idea. And we can have a website.ent in share/sgml, just like 
articles.ent and books.ent to easily pull in the necessary entities. 
About this I have more ideas as I've been looking at the opportunities 
with XML. I already have something in a local repo, but it's highly wip. 
I think that doc/en_US.ISO8859-1/share/sgml should only contain some 
"glue" .ent files, for example imho newsgroups.ent should go into 
doc/share/sgml so that translators can use them in an early phase of the 
translation or simply reuse them if there is something to reuse.


>  BTW, for teams/hats related information, what do you think about
>  adding files including who it is on per developer basis?  An
>  experimental one for showing the concept is attached.  It includes
>  pgpkey, hats, commit bit array, mentors, and location.  Most of
>  member descriptions of teams/hats can be generated from the files,
>  and also the traditional first commit by a new committer can be
>  simplified.
>   
The idea seems good, but with the DTD I have some ideas and doubts:
- We have the location data in ports/astro/xearth, in this way we would 
introduce one more duplication
- We have the birthday data in src/usr.bin/calendar, which may not be a 
problem as it cannot change
- If someone leaves core and returns, or simply resigns his commit bit 
and returns the from-to attributes cannot be precise. Or maybe we could 
for example merge 1995-1997 and 1999-2000 as 1995-2000?
- There might be a website or comment element or attribute to put 
personal websites or additional info (e.g. we have at least 2 deceased 
committers)

Regards,
Gabor