Hi, On Thu, May 8, 2008 at 6:39 PM, Luke Kanies <[EMAIL PROTECTED]> wrote: > > 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).
What about Atlassian Confluence: http://www.atlassian.com/software/confluence/ Here's a feature tour: http://www.atlassian.com/software/confluence/features/ It's free for OpenSource projects: http://www.atlassian.com/software/confluence/pricing.jsp#nonprofit It provides the possibility to create PDF, organize the pages in spaces and sub-pages, ... > 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. Atlassian provides also an enterprise issue and project management system which integrates perfectly with Confluence: http://www.atlassian.com/software/jira/ Here's a feature tour: http://www.atlassian.com/software/jira/features/ Again it is free for OpenSource projects: http://www.atlassian.com/software/jira/pricing.jsp#nonprofit It provides roadmaps, changelogs, reports, saveable search filters, ... and is extremely flexible. We use it in our company and I always wonder how I ever could work without it ;-). Both Confluence and Jira are used by many OpenSource projects, e.g. the Apache Foundation: https://issues.apache.org/jira/ http://cwiki.apache.org/confluence/ > Luke Kanies | http://reductivelabs.com | http://madstop.com -- Andreas --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
