Christopher Lenz wrote:
> Am 08.10.2006 um 19:52 schrieb Ilias Lazaridis:
> > Switching between several trac versions should be simplified, even if
> > those are pulled from the SVN.
> >
> > After installing trac, the shared directories are entered within
> >
> > /trac/siteconfig.py
>
> siteconfig.py is going to have to die. It makes the installation
> process more complicated, isn't going to work well with setuptools/
> eggs, is another source of confusing errors, and, well, just plain
> sucks.
siteconfig.py can of course die.
There are other mechanisms for "base-pointers".
> The alternative as I see it (and to some extent played with in the
> "setuptools" sandbox):
> * Data such as the static files, the default templates, and the
> default set of wiki pages are stored as package data, and located at
> runtime using pkg_resources. This data is considered immutable.
ok
There are use cases where default wiki pages are not static.
But in those (and similar cases), a user can configure an
"base-pointer" to overide pkg_resources.
> * Things like the shared plugins directory or a shared templates
> directory must be explicitly setup in trac.ini, but are of course
> completely optional.
ok
> * trac-admin loses most positional arguments, but in turn gains a
> couple of options for the "initenv" command so that you can specify
> the shared plugins/templates/wiki-pages directories. This should make
> it is easy to automate the creation of new projects in an environment
> where multiple projects share a common set of templates etc.
ok
(this could become generic, in the way that trac-admin can get any
value available within the *.ini file.)
> The one remaining challenge here is the global config file. A simple
> approach would be to have a "inherit" option that would specify the
> path to the global config. The parsing may need to jump through some
> hoops to load that global config first and then overlay it with the
> environment-specific config.
ok, this would be a follow-up problem.
-
I've created a draft working plan which describes the concept of
'environment inheritance':
http://dev.lazaridis.com/base/wiki/PlanEnvInheritance
I estimate that I need a few days, spreaded on a few weeks.
I estimate you need more than that.
As I'm currently still able to view TRAC abstractly (not yet gained
many of the domain knowledge), I suggest that I take this task.
Take a task, submit a patch, welcome to open source...
My goal is to have this for the 0.11 release (I have 2006-12-31 in
mind).
Would just depend that the tiny changes go into the code-base.
I _could_ implement it based on plugins and dyna-patches (=
monkey-patches), but I would prefere to make my efforts immediately
based on the main code-base.
This way the rest of the team can focus on their main tasks, without
worriing much about this topic (except when I have a step ready, which
needs verification).
Contributions seem to be welcome by the team, however they seem to be lacking from you in regards to patches. Feel free to post a patch so others can implement them. I like a good project manager, but one who is self appointed rarely works out. Monkey-patch away! If it is suited to the project, it WILL be adopted.
I am sure you will like the result.
Yes! In Particular, if you can stop worrying about the management of trac and start producing more than subjective content about trac in my inbox, I'd be extremely happy.
(btw: I will most possibly work not much more than around 3 months on
trac and trac related issues before moving to the next subsystem.)
.
You'll only help the project for the next 3 months? Ok, well if you must limit your time, let's take advantage of it. What is the focus of the subsystem you intend to work on first?
One day I hope to submit more than MySQL patches myself, but like everything I've seen before, you must start at the bottom and work up. Eventually, with hard work and people skills, you get to project management status. So far, I have seen neither from you. (Although, you have the best speculation on project direction I have ever seen. Does it come from working with a large team??)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/trac-dev
-~----------~----~----~----~------~----~------~--~---
