On Nov 21, 4:42 pm, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED] nomine.org> wrote: > Given how Christian is coordinating 0.11's release now can we already discuss > the focus for 0.12 a bit? > > * Enhanced underlying data model (GenericTrac) > * Improved notification architecture (TracDev/Proposals/Journaling, #1890)
0.12 should continue to refine the concept of resource descriptors in classes and supporting code - I don't see it getting more generic than that. Reworking notifications would be a prime candidate for the required supporting infrastructure, and I hope to be involved in that. +1 on notification w/ supporting infrastructure. > * Better user/session system > o Optional form-based login > o Pluggable user-directory provider (#2456) > o Nicer CC-list / "ticket monitoring" (#1459) +1. More flexible notification services should be accompanied by a better model for users and user data other than preferences. Taking care not to entangle 'users' and 'notification' too tightly, but useful to deal with in same release as they will demand much of each other. Demanding use-cases makes for better solutions. > * Basic support for multiple projects (TracMultipleProjects/SingleEnvironment) -1. I see the need, but just don't think we're able to solve these issues just yet. AFAIK there is not even a consensus on what model(s) of multiproject to support. That said, even though not building this for the coming version, actually reaching a consensus on how to one day do multiproject support should be on the to-do list. It would provide much needed direction on this and other issues. > * Better help/documentation system (#2656) +1. This one has always bothered me a lot - the 'cluttering'... Here is my idea for a sandbox branch on this once 0.12 gets underway: - move help pages to a /docs inside the egg, and install them as part of the egg and keep them there on disk (docs follow active version), structured to support versions for various languages. - make all links for help into [help:] and req.href.help() links - a default help implementation that knows how to a) ask implementors for structured page lists for building a permanent help menu, and b) hand off wiki content fetching, rendering and searching to modules supporting the interface - default implementation that ships with trac fetches from wiki if page exists there, or else reads the source off disk instead. basic idea: If you want a custom help page, then make it into a wiki page. Could even be a switch, that unless enabled it reads from disk only. Default install should only create WikiStart and a few supporting pages for TitleIndex and so on. - it would also allow each module to provide its own help pages to the common help menu, and many larger plugins on trac-hacks could well need a few help pages in the common Help menu. - by doing help through an interface, others can make alternative implementations based on InterTrac/Wiki, master-project-help-page- fetching, or even ping coderanger on #trac and return the result :-) As there are so many other possible tasks for 0.12, I've left everything else out this time in order to focus on some larger issues that are close to me. More to follow in coming discussions, no doubt. :::simon https://www.coderesort.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
