2005/12/20, Ross Gardler <[EMAIL PROTECTED]>: > > I always have imagined a web-based wiki application which stores its > data in > > a certain directory in SVN repository. Perhaps, we could create this > kind > > of backend extension for our existing CMS. > > The problem is that we are unlikely to be able to create a solution that > suits everyone. As I understand it infra don't care how the > documentation is created as long as they can easily maintain the > publishing framework, the ASF requirements for traceability are met and > they are not expected support a wide range of CMS systems. > > Sadly, everyone wants to use their own system (even within projects > there is not always agreement). With the creation of zones for TLP's it > is now possible for projects to "go it alone" using whatever CMS they > want with whatever back-end they want (this has already happened in at > least one project). > > This could cause huge problems for infra - we have to come up with a > solution *before* it becomes an unmaintainable problem. But how?
If the ASF requirements for traceability is a must, I think we have to sacrifice individual preferences at least a little bit for the infra team. Tools such as Trac (http://www.edgewall.com/trac/) is very impressive from the viewpoint of traceability, but it's not mature yet. We need to find the gem we can really use for full traceability and integration between various sources (i.e. wiki, issue tracker, source code repository, mailing list, ...). > Similarily, storing bugs and > > issues information could be stored in SVN repository, all in human > readable > > text format. Yes, this takes a lot of time. Am I talking too ideally? > :) > > That's an interesting point. Issue tracking is another artifact that is > not stored in SVN. Would it be useful to explore the justification for > this? Storing issues in SVN repository actually sounds similar with storing mailing list archives in SVN repository. It is too ideal. What we need is perhaps a CMS which combines: * site management (support for both production/draft(wiki?)) * issue tracker * source code repository viewer * mailing list + forum (like www.nabble.com does) And if we store all documentation in the CMS, we'll need a tool that fetches the whole site and includes it into binary distributions. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ PGP Key ID: 0x854B996C
