> Yep, that's interesting. We more or less have a revamp of the css in > mind for some later release, see #5997 and #633.
What is general feeling in the community on relying on a third party CSS library (like Blueprint, Lesscss, 960 Grid)? I've found them very useful in theme development and they have the added benefit of making laying out wiki pages super simple, which is very powerful for organizing dashboards and index pages. > <snip> We have therefore lots of opened tickets there: > http://trac.edgewall.org/query?status=!closed&component=notification > > Getting started on some of those will also help to get a better picture > of the requirements for a rework of this subsystem. I'd be happy to start submitting maintenance patches as I'm able! > Such a rework will certainly benefit from both improvements to the > currently not-so-existent user subsystem (see #2456 and possibly what > has been done so far in the /sandbox/accountmanager branch) and from > basing the notifications on the change listeners (#6543), which goes in > the direction of your second point (less explicit connection). In my recent experiments, I've been using a ticket change listener combined with a notification dispatcher, which seems to work decently. > Branching based off trunk or multirepos is a good idea. Though there's > no official git or Mercurial mirrors of Trac, using such tools make it > quite easy to maintain your own branch. I've been using a dual repository setup -- an SVN checkout of the multirepos branch, with local modifications handled with Mercurial patch queues. I've been using the same setup for my Drupal projects for the past few months. <snip> > There had been several discussions about this on this mailing list. For > example: > - http://groups.google.com/group/trac-dev/msg/6d117b310e2a21dd > - http://groups.google.com/group/trac-dev/msg/32117737c9aa0498 > - http://groups.google.com/group/trac-dev/msg/724c55ca7ad413db You are an encyclopedia of Trac knowledge. > Well, I'd *love* to see someone with good writing skills take more care > of the Trac wiki itself. Be it contributing to the recently started > CookBook or just sanitizing the existing docs, deprecating the various > out-dated guides where they need to be, or starting the rewrite of some > of the pages (e.g. the debian install guide). I think this could have a > wider benefit to the Trac community, but that being said, it's not > exclusive to your writing a blog ;-) Actually, if I contribute anything, it might be in that area. I'm a passable developer, but I have quite good writing and editing skills, and have deployed Trac on Debian and several derivatives, Arch, Gentoo, Cent, and RHEL. So I would *love* to help with that. David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" 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/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
