Christopher Lenz kirjoitti: > 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… > >> * Enhanced underlying data model (GenericTrac) > > -1. There isn't even consensus on whether that's a viable direction. > (Personally, I'm not a fan.)
I feel same. Trac is quite highly specialized to do certain things, and it does it pretty well. I don't see point to push "generic". Rather I would see usage of some ORM (Alchemy) but as said somwhere there has >> * 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. I think it's ticket #130 in t.e.o and last time I checked it was still on list for 1.0 not for 2.0. I might be wrong though. This is two sided thing. It has very high demand and thus people are finding a ways to overcome this - even plugins. There lies danger that someone succeeds to make widely accepted solution by community. >> * Vastly improved versioncontrol subsystem (see VcRefactoring) > > -0. I'd prefer to see this limited in scope, the proposal is very > broad as is. Very broad and seems to be concentrating to fix problems with Mercurial... Also wonder how upcoming 1.5 merge changes tracking would affect Trac SCM backend(s)... >> * Better user/session system >> o Optional form-based login >> o Pluggable user-directory provider (#2456) >> o Nicer CC-list / "ticket monitoring" (#1459) >> * 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. Well few points: I'm using AD to authenticate my users, I have e-mails etc. in AD (ldap that is) There is no way to push that existing information to Trac. I had to do rather ugly SQL scripts to import e-mail data to make "assign-to" field as dropdown. And since there is no generic user data repository, I had to repeat that action for all my 50+ projects. Now when new developer steps in someone need to reproduce steps by hand. CC-list is well.. A list. It works but it causes enormous change noise, it's error prone (it's easy to delete someone other email from that too) and hard to edit if list grows as has happened to some tickets in t.e.o. I would see this being user property (Ticket/Wiki I want to follow) rather than ticket property. >> * 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 And multiple groups and such. Specially if SA implementation takes place this might come more feasible/important thing..? >> * 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. +1, of course Depends on timeframe... :) >> * 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, this is something that bothers me too. Specially when you upgrade Trac all upgraded help information is not visible if you don't explicitly upgrade your wiki, which is IMO very bad option. >> 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 This is something I have some personal interest and maybe some extra spare-time to work on. It should also enable me to use my favourite DB backend - Oracle :) >> 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. I think that way too. Well it could so that there is intention to release new versions about every 6 months, so feature set won't grow too large. I rather would see that each release would contain few key features not any gigantic blob. Being for example only i18n for 0.13. I don't see point to restrict releases to any certain time frame. At least upto version 1.0 which in theory is considered to be "stable" release cycles can be very short if needed. -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
