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

[Simon L. Nielsen]

On 2008.08.17 20:47:50 +0900, Hiroki Sato wrote:

> 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.

I have no general problem with merging www and doc closer (might be
done while considering moving to svn?) and fully requiring having both
for build of either, but having e.g. www/en as a deep subdir of doc/
seems like a rather bad idea to me.

The web site and and doc/ are rather differnet beast wrt. how you
write content so I see no problem having it in seperate top level
directories.

>  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.

Generally, I think it would be neat (and I looked a bit of doing it a
few years ago), but I must say I'm not sure if doing it is really
worth the trouble compared to just making sure we don't have
duplication of the information.  That said, if somebody does it I'm
certainly not generally against it (considering my below point).

For some parts of our current site I think some of the XSLT magic is a
bit to magic and hard to understand, so I'm a but conserned going too
much further in that direction...

-- 
Simon L. Nielsen