Hi Christopher, all, I apologize for the somewhat longish mail, even if I tried my best to stay concise, that didn't work out so well, as I had plenty of things to say :-)
Christopher Lenz wrote: > Am 21.11.2007 um 16:42 schrieb Jeroen Ruigrok van der Werven: > >> Given how Christian is coordinating 0.11's release now can we >> already discuss the focus for 0.12 a bit? >> >> What I see on the roadmap seems a bit excessive in terms of planning >> a new >> release (notes inline are mine, comments from others very much >> welcomed to get >> an idea of the scope): >> > > "Excessive" indeed. This kind of milestone planning should really be > going on on this list rather than on the milestone pages. I hadn't > realized what the current milestone items were until you started this > thread… > I propose to move all those topics to 1.0, then selectively move them back either to 0.12, 0.13 or forward to 1.1, 2.0, as some consensus or progress emerges. But that feature list is only partial, here are some additional topics I'd like to introduce: * improve the rendering layer: currently, the infrastructure for rendering is split between the trac.mimeview package and the trac.web package. There really need to be some clean-up on both sides, targeting the removal of all rendering related functionality located on the Request object itself on one side, reviving the #3332 patch on the other side. I think this is a natural follow-up to 0.11 and seems better done sooner than later, so I think it should be done for 0.12. * go on with the fine-grained permissions work: - the browser svn_authz should be transformed into a permission policy (maybe even a 0.11.x thing, as this will be transparent to the user) - the permission checks could be performed also in the data model layer - fix the implementation of group providers, as outlined in the "[RFC] get_user_groups" thread * improve the search feature: I'm not talking about that grand redesign that keep being postponed, just about some incremental improvements that have a very good benefit/effort ratio: - sorting by relevance in addition to sorting by date, - "send ticket matches to custom query" feature. The code is mostly there, it just needs to be adapted to the same style as the one of the latest timeline-refactoring. Then, there's the very important topic of all the known tickets already scheduled for 0.10.x and 0.11.x maintenance lines. That is a really /huge/ amount of work there: - there are still *80* open tickets for 0.10, some of them quite critical. We should g through that list and retarget some of those to 0.11.x and 0.12, as I don't think they'll ever get fixed on the 0.10.x line at this point. - there are already *192* tickets for 0.11.1 tickets. Last week, I made a copy of that list and annotated it with a more realistic estimate, planning to move most of them to 0.12 and beyond. - among the 130 un-triaged tickets, a good deal of them are probably worth addressing as well. Some of those bugs are just little things, some are indicative of deeper issues that would probably benefit from a more radical approach for fixing them. Take for example all the issues related to database backends. Would a move to SQLAlchemy be a radical progress for fixing all the issues we're seeing? If so, the time invested in that area seems to be worth it. But of course it might as well introduce other unexpected issues. Only an actual experiment could really tell (as I was writing those lines, I saw that asmodai just restarted a sandbox for that - very good). Another example is the wiki engine refactoring - lots of benefits in one go, if done well. >> * Enhanced underlying data model (GenericTrac) >> > > -1. There isn't even consensus on whether that's a viable direction. > (Personally, I'm not a fan.) > The "generic" Trac proposal is partly there to address known problems and simplify the current code, partly for enabling (lots) of new features. I certainly did a poor job so far at explaining what I have in mind there and maybe the "generic" term was badly chosen, as I don't want to "uniformize" the Trac interface, only rationalize what we currently have and make that infrastructure more reusable. A better image of what I'm aiming at is a "versioncontrol API" for the resources. I'll try to explain it better next time, with some supportive code. I don't want necessarily to make this a 0.12 thing, though, as there are plenty of other things to do... >> * Basic support for multiple projects (TracMultipleProjects/ >> SingleEnvironment) >> > > -1. Multiple project support has been on the list for Trac2 since day > one. We should try to get the 1.0 line in solid shape sooner rather > than later, and use that as a basis for moving towards multiple > projects. Not move multi-project to 0.x because we can't even get 1.x > shipped. Well, I have another point of view on this. For one, I think I see how to implement this on top of the data model refactoring. Plus it's a very highly anticipated feature, and most people will certainly be disappointed if we ship a 1.0 release without support for multiple projects. Also, when I said "Basic support for multiple project", I was thinking about the minimal infrastructure needed to have project specific data in the same db, accessing the different Trac projects in the same way as we currently access different Trac environments. The only connections between them would be InterTrac links. On top of that, as a /second/ step, it would be possible to add more features like a project summary module, a project directory, a common timeline and search, etc. Again, I'll favor doing some incremental steps that we can do relatively soon rather than a grand big design that'll never happen (remember we've been talking about that for 4 years... I don't want this to that takes another 4 years). >> * Vastly improved versioncontrol subsystem (see VcRefactoring) >> > > -0. I'd prefer to see this limited in scope, the proposal is very > broad as is. > Yes, broad and quite vague at this point, I admit. There is a lot of design work left to be done there. This is something that slipped from 0.11 to 0.12 and is probably going to have to wait a bit longer. But this is also something that I consider to be parallel development, as it doesn't require anything to be done in Trac core (well, besides that little generic trac thing that would allow me to implement a repository resource more easily) and it doesn't block anything to happen in Trac core. >> * Wiki Engine refactoring (WikiEngine) >> > > +1. This refactoring is needed for getting the wiki content into the > genshi output system in a clean way. We currently employ rather ugly > hacks to make it work (for example when it comes to white-space/line- > break preserving blocks). If that hasn't changed since I last looked, > that is. > +1 of course. This is something I definitely would like to put my principal efforts for 0.12. >> * Improved notification architecture (TracDev/Proposals/Journaling, >> #1890) >> > > -1. This proposal rubs me the wrong way, rather similar to > GenericTrac. I also don't see a clear/strong benefit in this change. > No worries here, this is also something I'm not satisfied with. For the journaling part, there's probably something simpler to do so that we can invalidate the various caches when needed (a bit similar to the env reloading after an .ini change, we just have to find the appropriate trigger). For fixing #1890, this is more related to the generic trac proposal and having changesets for resources. >> * Improved ticket query system (so that it can be used instead of >> SQL reports >> system in 99% of the use cases) >> > > +1. I'd really like to make the query system the default for "View > Tickets" for 0.12, and it'd be nice if the query system was more > powerful, supporting things like date-based queries. > +1 as well, those are minor improvements. Besides, I'd also very much welcome coderanger to go on with his ninja branch, as this could also well be /the/ killer feature for 0.12 ... > >> * Improved API for request handlers (see sandbox/controller and the >> newer >> VcRefactoring/Controller) >> > > -0. This could easily be postponed, and I'm not convinced of either my > own old proposal or Christian's. > +0, that can be post-poned, but there are some parts of it that can be done during the rendering refactoring, like building up the chrome data independently of the Request object. >> * Internationalization >> >> Most of the internationalization framework is already in place in >> the i18n >> sandbox and kept up to date with trunk. I'm working on setting up >> something >> like Pootle locally to get an idea of the current translation >> coverage. >> > > +1. I18n will need more work on both Genshi and Babel, but in general > it's rather far along, and would be possible to release in the 0.12 > timeframe even if not 100% complete. > +0. If this can be done for 0.12, all the better, but that shouldn't block a 0.12 release. >> * Better help/documentation system (#2656) >> > > +1. Personally, I think this one is desperately needed. Let's stop > polluting the wiki of every Trac-using project with documentation, and > implement a proper, scalable solution, which also allows plugins to > add help-style documentation. > +1, I'm interested to see that happen as well. Not a blocker feature either. >> Eventually: >> >> * Migrate to SQLAlchemy for database interfacing and connection >> pooling (see >> sandbox/sqlalchemy) >> >> Wouldn't this be a better target for 0.13? Given how SQLAlchemy is >> currently >> revamping a lot of its internals and the SQLAlchemy branch has been >> dormant >> for a long while it seems a bit difficult to correctly shove this >> inside >> Trac at this point in time. >> > > -0. It'd be awesome if we could get rid of the Trac connection pooling > code by using SA, but otherwise unless someone picks up this branch > pretty darn soon, it should not be on the table for 0.12. > +1. As I said above, if this can improve things, I'm all for it. >> What date did we have in mind for 0.12? I sincerely doubt we want to >> have as >> long a wait as we had for 0.11. >> > > Depends on when 0.11 is released, and on this thread and related > discussions in the future. I don't think anyone actually thinks that > this kind of release cycle is a good idea. We just need to agree on > limiting the scope, and find a consensus on the subset to limit it to. > So here's a summary of the future steps as I see them. Main features for Trac 0.12: - rendering refactoring (cboos, cmlenz?) - wiki engine refactoring (cboos) - SQLAlchemy, if it proves to be successful (jruigrok, cboos) - i18n, even partially (cmlenz, jruigrok) Secondary features for Trac 0.12: - minor improvements for the search (cboos) - enhancements to the query (cboos) - fine-grained permissions improvements (cboos) - better help/documentation system (cmlenz?) I have no problem in splitting the above feature list in two (0.12/0.13) if it becomes clear that it can't be achieved in, say, a 6 months time frame. The developer lists above are open, it's just indicative of the people that I know will (eventually?) contribute to the feature. Feel free to enlist yourself or remove the question mark ;-) Later steps (beyond or started parallel to 0.12): - data model refactoring (cboos) - multi-project support (cboos) - multi-repository support and support for DAG-based vc backends (cboos) - advanced search (aat?) - alien technology (jonas?) There would also be lots of other things to discuss relative to the way we could improve the development process of Trac: what ticket workflow should we use on t.e.o, do we need to restructure the components and keep/discard component owners, do we split sub-systems like versioncontrol refactoring into a plugin, bundle "blessed" plugins like trac-ini, account mgr, svn and mercurial plugin, etc. But that mail is already too long, so let's keep those topics for later ;-) -- Christian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
