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.)

> * 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.

> * Vastly improved versioncontrol subsystem (see VcRefactoring)

-0. I'd prefer to see this limited in scope, the proposal is very  
broad as is.

> * 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.

> * 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.

> * 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.

> * 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.

> * 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.

> * 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.

> 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.

> 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.

Cheers,
Chris
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to