[Trac] Pluggable Modules

[Brad Anderson]

On Tuesday 11 January 2005 5:50 am, Christopher Lenz wrote:
> Am 11.01.2005 um 01:32 schrieb Christopher Lenz:
> > Am 11.01.2005 um 00:07 schrieb Brad Anderson:
> >> I took a look at Christopher Lenz's patch here:
> >>
> >> http://projects.edgewall.com/trac/wiki/TracPluggableModules
> >>
> >> and it looks promising.  My question is, what is the timeframe for a
> >> change
> >> like this?  Is this post-1.0 or pre-1.0.  I'm working on a couple of
> >> modules
> >> and would like to fit into this framework if it will be ready soon.
> >>
> >> The code looked like prototyping only, and I'll dive deeper into it
> >> this week.
> >> But how big of a breadbox is it to retrofit current modules to this
> >> new
> >> framework?  I would definitely be able to help, although I see time
> >> getting
> >> little bit scarce in the coming weeks.
> >>
> >> Just curious as to the perceived timeframe on this.
> >
> > The timeframe pretty much depends on:
> >
> > a) feedback from the edgewall folks <ping/> and anyone else interested
> > b) whether we can drop support for python 2.1 (the new architecture
> > requires >= 2.2)
> >
> > If those two points get checked, I would say that the refactoring
> > could happen even before 1.0. Yes, there's a lot of code that would
> > need retrofitting, but it's doable. And probably in an almost
> > evolutionary fashion (i.e. having working code in trunk throughout the
> > process).
>
> To put my response into some context, the original plan is to continue
> building on the current code-base until 1.0. At that point we want to
> branch out and do some much-needed refactorings, not only to support
> pluggable modules, but also for:
>   - Multi-project support
>   - Better integrated user management (whatever that means)
>   - Database independence
>   - Support for other version control systems
>   - SOAP/XML-RPC interface
>
> I think it's a good idea to defer any big changes until we've put a
> stable 1.0 release out with a solid feature-set. But it's starting to
> look like we might get database independence and an abstraction layer
> for different version control systems into Trac without any really
> major changes (thanks to your and Justus' work), so the magic 1.0 line
> has already started to blur...

Well, if it has started to blur, maybe this is a time for my thoughts on 
releasing 1.0.  I see Jonas and Daniel putting bugs into the 2.0 "catch-all" 
version release for refactorings, but Trac is not a large code base.  I would 
opt for getting 1.0 to be the way we all want it, and put our best foot 
forward.  Then, 1.1, 1.2 (the 1.x branch) could be some minor refactorings, 
and 2.0 has features that nobody has even thought of yet.  2.0 features come 
up when 1.0 has been out for a while.

This being said, I understand that this is a game of where do you draw the 
line and say that nothing else is getting in.  I found Trac late relative to 
most, so there may be some pressure to get 1.0 out.  My thinking, however, is 
that after 0.9 is 0.10 and then 0.11 until you're ready.  If you really have 
a list like the 5 things listed above, then let's knock them out and leave 
the smaller requests for fixing in a release candidate or post 1.0 version, 
but not 2.0.  If we immediately go to pluggable modules and SOAP/XML-RPC and 
better user mgmt, all right after 1.0 is released, then support for 1.0 is 
going to suck.  We'll all be working on the 2.x branch and our users will be 
pissed that we don't want to support what we realize is not ideal code. (I 
think you say this below)

>
> > There's also the issue of momentum. I'm currently the only committer
> > actively and regularly working on Trac (i.e. checking stuff in,
> > applying patches, etc), so trunk might starve when my interest in the
> > current code-base fades. If we want to keep up the plan of refactoring
> > after 1.0, we need more folks with write-access to the repository


> > <ping target="edgewall"/>.

Error:  No response from host.

I'd be happy to join you as a committer.  I'd like to start on the 
PluggableModules branch as well as get MySQL into the DB branch alongside 
PostgreSQL.  I also have the WebAdmin module, although I have to go back and 
look at it.  It's been a while.  It's a pain keeping in sync with the trunk 
and not being a committer, but it's manageable.

BA

>
> Cheers,
> Chris
> --
> Christopher Lenz
> /=/ cmlenz at gmx.de
>
> _______________________________________________
> Trac mailing list
> Trac at lists.edgewall.com
> http://lists.edgewall.com/mailman/listinfo/trac