On May 8, 2008, at 10:21 AM, The Anarcat wrote: > On Fri, May 09, 2008 at 01:07:55AM +1000, James Turnbull wrote: >> 2. Restructure the wiki in place on Trac > > Why not? I don't see the reason for switching the wiki engine.
James kind of left out his motivations for thinking about this in the first place, so I'll mention a few shortcomings that Trac currently has. I think James is a bit more cognizant of those shortcomings, though, because he's been spending a *lot* more time maintaining the wiki than I have (it's worth looking through a Timeline on the wiki and being amazed at how much time James has spent on it). Wiki issues: It has no structure on its own. We as a community can attempt to enforce structure, but it's always going to be a fight between the cruft that develops over time and the structure we want. It also doesn't support multiple form factors -- if you want the content of the wiki in a PDF, you're pretty stuck. One thing I'd love to see change is the wiki docs stored in a db instead of in a version control system; using an SCM instead of a db automatically gives you multiple interfaces for accessing the data, and also makes it easy to write tools that validate or munge that data (e.g., extracting it into a PDF). Bug tracker issues: The bug tracker isn't that great, I must say. I'd tend to have tons of milestones, but Trac keeps all milestones around, even if they're closed, so in a year we're going to have 30 milestones, only two of which are valid. Also, there's no way to talk about relationships between tickets. I don't want a Gantt chart or anything, but being able to clearly mark that tickets are related would be pretty useful. Basically, the bug tracker is ok for tracking issues, but it's crap as a means of deciding what to develop. I know the ticket db pretty well, but I'm still often surprised by its actual contents and how tickets are related (my recent reorganization around components has helped that some). I'd love a db that made it obvious where people could have the biggest impact on development -- are there tickets that are keeping us from fixing lots of other tickets? Essentially, I think trac is fine for smaller projects, but Puppet is mid-transition to a larger project, and I think we need our tools to scale with us. A note on markup formats: Steven Jenkins encouraged the use of MediaWiki, but one of my primary requirements of any choice is that we don't pick a format that's not at least pretty close to a standard. MediaWiki's format is pretty ad- hoc, and no one but MediaWiki uses it. There aren't external parsers, I can't easily convert it to a PDF, etc. This is the same problem I have with the Trac markup, which is why I stick to RST. The docs are now in at least their third iteration since the start of the project, and each iteration has been somewhat painful if non- standard formats were involved. If we stick to RST, it's easy. I'd consider something like markdown or textile, but... they're basically crap formats. Really. One of these days I'm going to hack up my own rst2html parser in Ruby, or maybe pay someone to do it. That would solve a lot of my problems, I think. -- The great tragedy of Science - the slaying of a beautiful hypothesis by an ugly fact. --Thomas H. Huxley --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
