RFC - Simplify multiple installations with shared environments
Ilias Lazaridis
combination with shared-environments.
thus I like to simplify this.
Any comments to this?
-
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
__default_conf_dir__ = 'D:\\trac\\conf'
__default_templates_dir__ = 'D:\\trac\\templates'
__default_htdocs_dir__ = 'D:\\trac\\htdocs'
__default_wiki_dir__ = 'D:\\trac\\wiki-default'
__default_macros_dir__ = 'D:\\trac\\wiki-macros'
__default_plugins_dir__ = 'D:\\trac\\plugins'
It would be simpler to declare just one entry:
__shared_dir__ = 'D:\\trac'
and to derive the other entries from this.
specific entries can still exist, in order to point to a different
location:
__default_plugins_dir__ = 'E:\\trac\\somewhere\\plugins'
The shared_dir should be by default set to '..\', which would be the
first step to make an svn co to work immediately without further steps.
.
Noah Kantrowitz
handling site files with setuptools. Hopefully we can actually take
it one step further and do arbitrary chains of these (very helpful to
create multiple classes of environments). On the other hand, for what
you are talking about I don't think it much matters. If someone is
trying to run two versions of a webapp, they should be ready to get
their hands dirty. Currently it just means doing the installs with
different prefixes, which isn't that hard.
--Noah
Ilias Lazaridis
> cmlenz has discussed this before, and it is similar to the plan for
> handling site files with setuptools.
Can you possibly point me to this resource?
> Hopefully we can actually take
> it one step further and do arbitrary chains of these (very helpful to
> create multiple classes of environments).
If I've understood you right, that's the goal what I have, but
independently of setuptools.
This needs just a few tiny changes to the existent code-base (this one
discussed in this topic beeing the first one).
> On the other hand, for what
> you are talking about I don't think it much matters. If someone is
> trying to run two versions of a webapp, they should be ready to get
> their hands dirty.
> Currently it just means doing the installs with different prefixes, which isn't that hard.
I make 'my hands dirty' in order to prevent users from making their
hands dirty.
nothing special.
-
http://dev.lazaridis.com/base/ticket/43
.
Noah Kantrowitz
On Oct 8, 2006, at 3:38 PM, Ilias Lazaridis wrote:
>
> Noah Kantrowitz wrote:
>> cmlenz has discussed this before, and it is similar to the plan for
>> handling site files with setuptools.
>
> Can you possibly point me to this resource?
Find a log of #peak from about 4 months ago.
>
>> Hopefully we can actually take
>> it one step further and do arbitrary chains of these (very helpful to
>> create multiple classes of environments).
>
> If I've understood you right, that's the goal what I have, but
> independently of setuptools.
>
> This needs just a few tiny changes to the existent code-base (this one
> discussed in this topic beeing the first one).
Tiny changes are all nice and good, but its not an excuse to not do
things right.
>
>> On the other hand, for what
>> you are talking about I don't think it much matters. If someone is
>> trying to run two versions of a webapp, they should be ready to get
>> their hands dirty.
>> Currently it just means doing the installs with different
>> prefixes, which isn't that hard.
>
> I make 'my hands dirty' in order to prevent users from making their
> hands dirty.
>
> nothing special.
I think `python setup.py --prefix=/usr/local/my-trac` is pretty
simple, and requires _zero_ changes to anything.
Ilias Lazaridis
> On Oct 8, 2006, at 3:38 PM, Ilias Lazaridis wrote:
>
> >
> > Noah Kantrowitz wrote:
> >> cmlenz has discussed this before, and it is similar to the plan for
> >> handling site files with setuptools.
> >
> > Can you possibly point me to this resource?
>
> Find a log of #peak from about 4 months ago.
how could I achieve this?
This shounds not that it's an official development plan.
> >> Hopefully we can actually take
> >> it one step further and do arbitrary chains of these (very helpful to
> >> create multiple classes of environments).
> >
> > If I've understood you right, that's the goal what I have, but
> > independently of setuptools.
> >
> > This needs just a few tiny changes to the existent code-base (this one
> > discussed in this topic beeing the first one).
>
> Tiny changes are all nice and good, but its not an excuse to not do
> things right.
Tiny changes (after lot's of thought).
> >> On the other hand, for what
> >> you are talking about I don't think it much matters. If someone is
> >> trying to run two versions of a webapp, they should be ready to get
> >> their hands dirty.
> >> Currently it just means doing the installs with different
> >> prefixes, which isn't that hard.
> >
> > I make 'my hands dirty' in order to prevent users from making their
> > hands dirty.
> >
> > nothing special.
>
> I think `python setup.py --prefix=/usr/local/my-trac` is pretty
> simple, and requires _zero_ changes to anything.
this does not meet my requirement (operatable after svn checkout).
.
Jeroen Ruigrok/asmodai
>how could I achieve this?
Try the novel idea of a Google search.
>this does not meet my requirement (operatable after svn checkout).
The Trac project does not solely exist to meet your requirements only.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
Seize from every moment its unique novelty and do not prepare your joys...
Noah Kantrowitz
On Oct 8, 2006, at 4:55 PM, Ilias Lazaridis wrote:
>
> Noah Kantrowitz wrote:
>> On Oct 8, 2006, at 3:38 PM, Ilias Lazaridis wrote:
>>
>>>
>>> Noah Kantrowitz wrote:
>>>> cmlenz has discussed this before, and it is similar to the plan for
>>>> handling site files with setuptools.
>>>
>>> Can you possibly point me to this resource?
>>
>> Find a log of #peak from about 4 months ago.
>
> how could I achieve this?
>
> This shounds not that it's an official development plan.
Nope, welcome to the world of small, volunteer-based development
teams. 90% (a number I just made up BTW) of the Trac development plan
lives inside the heads of the handful of developers. PEAK does keep a
logbot in the channel, but I do not know how to access it.
>
>>>> Hopefully we can actually take
>>>> it one step further and do arbitrary chains of these (very
>>>> helpful to
>>>> create multiple classes of environments).
>>>
>>> If I've understood you right, that's the goal what I have, but
>>> independently of setuptools.
>>>
>>> This needs just a few tiny changes to the existent code-base
>>> (this one
>>> discussed in this topic beeing the first one).
>>
>> Tiny changes are all nice and good, but its not an excuse to not do
>> things right.
>
> Tiny changes (after lot's of thought).
>
>>>> On the other hand, for what
>>>> you are talking about I don't think it much matters. If someone is
>>>> trying to run two versions of a webapp, they should be ready to get
>>>> their hands dirty.
>>>> Currently it just means doing the installs with different
>>>> prefixes, which isn't that hard.
>>>
>>> I make 'my hands dirty' in order to prevent users from making their
>>> hands dirty.
>>>
>>> nothing special.
>>
>> I think `python setup.py --prefix=/usr/local/my-trac` is pretty
>> simple, and requires _zero_ changes to anything.
>
> this does not meet my requirement (operatable after svn checkout).
Works pretty well for me after a checkout. Maybe you should try
changing your requirements?
--Noah
Ilias Lazaridis
> On Oct 8, 2006, at 4:55 PM, Ilias Lazaridis wrote:
> > Noah Kantrowitz wrote:
> >> On Oct 8, 2006, at 3:38 PM, Ilias Lazaridis wrote:
> >>> Noah Kantrowitz wrote:
> >>>> cmlenz has discussed this before, and it is similar to the plan for
> >>>> handling site files with setuptools.
> >>>
> >>> Can you possibly point me to this resource?
> >>
> >> Find a log of #peak from about 4 months ago.
> >
> > how could I achieve this?
> >
> > This shounds not that it's an official development plan.
>
> Nope, welcome to the world of small, volunteer-based development
> teams. 90% (a number I just made up BTW) of the Trac development plan
> lives inside the heads of the handful of developers. PEAK does keep a
> logbot in the channel, but I do not know how to access it.
I don't know this, too.
Anyway, I'll await the comments of the developer.
No.
I'll await the comments of the responsible developer, in order to try
to synchronize my efforts with the project.
.
Ilias Lazaridis
I just realized that this behaviour is already implemented:
http://trac.edgewall.org/browser/trunk/trac/config.py?rev=3744#L427
thus my problem is already solved.
What remains is to remove the existent redundancy:
http://dev.lazaridis.com/base/ticket/43#comment:2
.
Ilias Lazaridis
> -On [20061008 22:56], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >how could I achieve this?
>
> Try the novel idea of a Google search.
nc
> >this does not meet my requirement (operatable after svn checkout).
>
> The Trac project does not solely exist to meet your requirements only.
"Look, there's no shortage of ideas, patches, proposals, experimental
branches or even forks. The problem isn't getting access to code that
adds feature XYZ. The real problem is integrating such changes into
Trac in a way that is consistent with the rest of the application,
meets certain quality standards and conventions, provides a migration/
upgrade path for existing deployments, and generally doesn't disrupt
the main development stream too much."
[...]
"I believe that a more liberal license can help to involve a more
diverse set of contributors."
http://lists.edgewall.com/archive/trac/2005-July/003880.html
I suggest you to read this message.
I will give you some insights into the reasons that i've choosen trac.
.
Noah Kantrowitz
On Oct 8, 2006, at 5:44 PM, Ilias Lazaridis wrote:
>>>
>>> This shounds not that it's an official development plan.
>>
>> Nope, welcome to the world of small, volunteer-based development
>> teams. 90% (a number I just made up BTW) of the Trac development plan
>> lives inside the heads of the handful of developers. PEAK does keep a
>> logbot in the channel, but I do not know how to access it.
>
> I don't know this, too.
>
> Anyway, I'll await the comments of the developer.
I'm not quite sure where you got this idea that the response of a
developer is somehow better than mine, and honestly its pretty
offensive. In the year and change I have been using and working with
Trac, I am proud to say that I think I have done good things for the
Trac community as a whole. I think its not unreasonable of me to say
that the Trac development team respects my opinion, and even if I may
disagree with a particular design choice I find ways to move forward
(which rarely involve broadcasting my dissatisfaction to this whole
mailing list). I find it incredibly asinine of you to say something
like this, and it serves no purpose than to be inflammatory and
annoying.
>>
>> Works pretty well for me after a checkout. Maybe you should try
>> changing your requirements?
>
> No.
>
> I'll await the comments of the responsible developer, in order to try
> to synchronize my efforts with the project.
In addition to my discourse from above, you now saw fit add the word
"responsible". Just in case I had any doubts that you were going out
of your way to be irritating, now its clear. If you don't like my
answer to your questions, thats fine, but this is simply childish.
--Noah
Ilias Lazaridis
I have very limited time, and I tend to synchronize my efforts with the
subsystem owner (= responsible developer).
I don't have to justify this in any way.
.
Chris Forsythe
>I have very limited time, and I tend to synchronize my efforts with the
>subsystem owner (= responsible developer).
>
>
>
The most time efficient way to synchronize your efforts with any team is
to use their ticket tracking system. It minimizes the time footprint on
your end. Your usage of the mailing list negates your claim that you
have very limited time.
Chris
Ilias Lazaridis
I think you are right.
Thank you for the hint.
.
Noah Kantrowitz
Yes, you do. You are working with a public project. Pissing off one
person because you feel I am not as important in meeting your
development needs is simply not an acceptable way to do business. I
had thought I was pretty nice in my last response, but clearly I
wasn't in your mind. For that I apologize, but maybe this will be
more clear: Play nice or get the heck outta' here. I am throughly
overstepping my non-existent authority in saying that, but I promise
you it is still true. You have a documented history of "trolling".
While I was one of the people who defended you initially, saying that
we (Trac) need to stay open to everyone, and that you hadn't shown
any signs of being inflammatory, I can see now that my claims no
longer apply. If you would like to continue to be a positive
contributer to the Trac community, I welcome it, but please leave
your holier-than-thou asshattery at home.
--Noah
Ilias Lazaridis
> On Oct 8, 2006, at 11:29 PM, Ilias Lazaridis wrote:
> >
> > Would you please have the gentleness to avoid such a tenor?
> >
> > I have very limited time, and I tend to synchronize my efforts with
> > the subsystem owner (= responsible developer).
> >
> > I don't have to justify this in any way.
>
> Yes, you do. You are working with a public project. Pissing off one
> person because you feel I am not as important in meeting your
> development needs is simply not an acceptable way to do business.
Sorry, but this is your very personal problem.
-
btw: you seem all to have much fun on the IRC:
[12:50:52] <coderanger> Ahh the subtle joy of mocking Ilias
https://pacopablo.com/irclogs/2006/10/08#T12:50:52
[14:09:52] <The_Tick> coderanger: bets on ilias biting on that
email from Jeroen?
https://pacopablo.com/irclogs/2006/10/08#T12:50:52
I am in a quite difficult private situation at this moment, thus I have
really no time for such games.
I hope that the project-lead will speak a clear word in this context.
-
For me it's time to sleep,
A good night (day) to all.
.
Noah Kantrowitz
On Oct 9, 2006, at 12:32 AM, Ilias Lazaridis wrote:
>
> Noah Kantrowitz wrote:
>> On Oct 8, 2006, at 11:29 PM, Ilias Lazaridis wrote:
>>>
>>> Would you please have the gentleness to avoid such a tenor?
>>>
>>> I have very limited time, and I tend to synchronize my efforts with
>>> the subsystem owner (= responsible developer).
>>>
>>> I don't have to justify this in any way.
>>
>> Yes, you do. You are working with a public project. Pissing off one
>> person because you feel I am not as important in meeting your
>> development needs is simply not an acceptable way to do business.
> ...
>
> Sorry, but this is your very personal problem.
>
> -
>
> btw: you seem all to have much fun on the IRC:
Yep, like I said I was wrong about you. Notice the datestamp is from
_today_.
Erik Huelsmann
discussion? You're not only spending your time on it but mine too.
This discussion currently has no bearing anymore on the development of
Trac nor on any of its components. Please move your discussion
elsewhere.
Thanks in advance.
bye,
Erik.
Ilias Lazaridis
...
> What remains is to remove the existent redundancy:
>
> http://dev.lazaridis.com/base/ticket/43#comment:2
http://trac.edgewall.org/ticket/3897
.
Ilias Lazaridis
> On Oct 9, 2006, at 12:32 AM, Ilias Lazaridis wrote:
> > Noah Kantrowitz wrote:
> >> On Oct 8, 2006, at 11:29 PM, Ilias Lazaridis wrote:
> >>>
> >>> Would you please have the gentleness to avoid such a tenor?
> >>>
> >>> I have very limited time, and I tend to synchronize my efforts with
> >>> the subsystem owner (= responsible developer).
> >>>
> >>> I don't have to justify this in any way.
> >>
> >> Yes, you do. You are working with a public project. Pissing off one
> >> person because you feel I am not as important in meeting your
> >> development needs is simply not an acceptable way to do business.
> > ...
> >
> > Sorry, but this is your very personal problem.
> >
>
> Yep, like I said I was wrong about you. Notice the datestamp is from
> _today_.
I've noticed the datestamps, as I've noticed those ones:
(sidenote: the trac-serach on pacopablo.com is broken)
[00:03:15] <coderanger> matt_good: The Ilias guy starting to
somewhat irritate me
https://pacopablo.com/irclogs/2006/09/17#T00:03:15
[22:14:28] <coderanger> Ilias is very much getting on my nerves
https://pacopablo.com/irclogs/2006/09/18#T22:14:28
[18:14:46] <coderanger> Can we ban Ilias yet?
https://pacopablo.com/irclogs/2006/10/04#T18:14:46
Please get over your allergic reaction against my person - or simply
ignore my topics / tickets if you cannot do so.
You are an very important Domain Expert, but my requirements are a
given - and for sure they are different from your requirements.
Possibly things become more clear after reading this document:
http://dev.lazaridis.com/base/wiki/AbstractionProcess
Ilias Lazaridis
> discussion? You're not only spending your time on it but mine too.
Sorry, but a little bit off-topic is usual within mailing-lists, even
developer lists.
> This discussion currently has no bearing anymore on the development of
> Trac nor on any of its components. Please move your discussion
> elsewhere.
My topics are valid trac-development topics.
I reply to off-topic messages (noise), even if this increases sometimes
the 'noise'.
If you like to reduce the noise, please have the gentleness to target
the _initiators_ of this noise, and not the person which _reacts_ on
this noise.
Thank you.
Christian Boos
>> Switching between several trac versions should be simplified, even if
>> those are pulled from the SVN.
>>
> I just realized that this behaviour is already implemented:
>
> http://trac.edgewall.org/browser/trunk/trac/config.py?rev=3744#L427
>
> thus my problem is already solved.
>
Well spotted, I was not even aware of that!
My problem was that I often started with a `python setup.py install`,
right after a checkout. This creates a trac/siteconfig.py (and
trac/siteconfig.pyc), and after that, switching from one checkout to
another was not as simple as it could have been. After removing those
files, I can indeed run Trac straight from the repo, a quite useful
feature indeed.
There are some additional subtleties with the templates directory:
- the [trac] templates_dir configuration option can mask the default
location for templates, as:
templates_dir = Option('trac', 'templates_dir',
default_dir('templates'), ...
Since this option is usually set to the default value given at
'initenv' time, you'll have to comment it out from the trac.ini
for the default_dir('templates') to take effect.
- the local $TRAC_ENV/templates takes precedence over the above one.
There's a ticket stating the opposite [1], but it worksforme, though.
One problem I've noticed is that if you put one template there (say
error.html), then the included templates also needs to be located
there (in this case, layout.html), otherwise you'll get an error.
Conversely, if you only put the included template there (e.g. a
modified layout.html), it won't take precedence over the one located
in the same folder as the requested one (say the installed
wiki_view.html which hasn't been copied in $TRAC_ENV/templates).
And for those who haven't noticed yet, there's also the very useful
`[trac] auto_reload` configuration option that you can change to 'true'.
This makes the development of templates more comfortable: as you can
guess from the option name, this activates the auto-reload feature of
the Genshi TemplateLoader, which means templates are parsed again if a
modification was detected.
This, combined with the '-r' (auto-reload) option of tracd, makes Trac
development a very reactive process.
-- Christian
Erik Huelsmann
From: Ilias Lazaridis <il...@lazaridis.com>
Date: Oct 10, 2006 10:35 PM
Subject: Re: [Trac-dev] Re: RFC - Simplify multiple installations with
shared environments
To: Erik Huelsmann <ehu...@gmail.com>
Erik Huelsmann wrote:
> On 10/10/06, Ilias Lazaridis <il...@lazaridis.com> wrote:
...
Sorry, I don't discuss public threads within private email.
Fine. Then just end up being rediculed the way you obviously like.
Erik.
Ilias Lazaridis
> Ilias Lazaridis wrote:
> >> Switching between several trac versions should be simplified, even if
> >> those are pulled from the SVN.
> > ...
> > I just realized that this behaviour is already implemented:
> >
> > http://trac.edgewall.org/browser/trunk/trac/config.py?rev=3744#L427
> >
> > thus my problem is already solved.
>
> Well spotted, I was not even aware of that!
>
> My problem was that I often started with a `python setup.py install`,
> right after a checkout. This creates a trac/siteconfig.py (and
> trac/siteconfig.pyc), and after that, switching from one checkout to
> another was not as simple as it could have been. After removing those
> files, I can indeed run Trac straight from the repo, a quite useful
> feature indeed.
>
> There are some additional subtleties with the templates directory:
>
> - the [trac] templates_dir configuration option can mask the default
> location for templates, as:
>
> templates_dir = Option('trac', 'templates_dir',
> default_dir('templates'), ...
>
> Since this option is usually set to the default value given at
> 'initenv' time, you'll have to comment it out from the trac.ini
> for the default_dir('templates') to take effect.
ok, I see.
This one would be the next problem to solve in order to get
"inheritable environments".
trac.ini "templates_dir" entry should not be creates (as it is
redundant)
http://trac.edgewall.org/ticket/3904
and the final enhancement would be this:
Introduce "shared_dir" option within trac.ini
http://trac.edgewall.org/ticket/3905
If everything within trac uses "default_dir" to get the directories,
the implementation should be quite simple.
The default_dir function would just look first an "shared_dir" option
(will possiblyy take a look at this tonight).
(btw: a followup issue would be the trac.ini modification/store logic).
> - the local $TRAC_ENV/templates takes precedence over the above one.
> There's a ticket stating the opposite [1], but it worksforme, though.
> One problem I've noticed is that if you put one template there (say
> error.html), then the included templates also needs to be located
> there (in this case, layout.html), otherwise you'll get an error.
> Conversely, if you only put the included template there (e.g. a
> modified layout.html), it won't take precedence over the one located
> in the same folder as the requested one (say the installed
> wiki_view.html which hasn't been copied in $TRAC_ENV/templates).
Is there a ticket available for this (as it looks like a defect)?
> And for those who haven't noticed yet, there's also the very useful
> `[trac] auto_reload` configuration option that you can change to 'true'.
> This makes the development of templates more comfortable: as you can
> guess from the option name, this activates the auto-reload feature of
> the Genshi TemplateLoader, which means templates are parsed again if a
> modification was detected.
>
> This, combined with the '-r' (auto-reload) option of tracd, makes Trac
> development a very reactive process.
yes, this -r thing is very convenient!!!
Christopher Lenz
> 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.
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.
* Things like the shared plugins directory or a shared templates
directory must be explicitly setup in trac.ini, but are of course
completely optional.
* 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.
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.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net
Ilias Lazaridis
> 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.
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.
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).
I am sure you will like the result.
(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.)
.
Jeroen Ruigrok/asmodai
>I've created a draft working plan which describes the concept of
>'environment inheritance':
[snip]
>I estimate that I need a few days, spreaded on a few weeks.
>
>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.
[snip]
>Would just depend that the tiny changes go into the code-base.
Just file tickets and they will get picked up by the developers.
>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.
You can base your efforts on the main code-base. The SVN trunk is open to
anyone. Or are you saying you want a commit bit?
>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).
File a ticket and it solves the above.
>I am sure you will like the result.
Sceptical approach: I'll see it when I'll see it. Put code where your mouth
is.
>(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.)
If the part above about a commit bit turns out to be true, this makes it
laughable in the end.
Jim Nanney
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??)
Brad Anderson
> (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.)
Ugh, we have to wait that long?
BA
Ilias Lazaridis
background information.
.
Ilias Lazaridis
...
> You can base your efforts on the main code-base. The SVN trunk is open to
> anyone. Or are you saying you want a commit bit?
If I would need commit access, I would simply ask for this.
> >(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.)
>
> If the part above about a commit bit turns out to be true, this makes it
> laughable in the end.
With 3 months, I meant "full-time commitment" to trac.
After this period, I still be active on trac (but not full-time).
.
Ilias Lazaridis
> > 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.
I'm more clear about this task now.
It seems it will take even less.
...
> 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.
If you are honest, then you'll have to admit that "worrying about the
management" has led to a Genshi centric 0.11 milestone.
> (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?
I don't select the sequence always myself.
It depends on if a task finds an commercial sponsor.
http://dev.lazaridis.com/base/wiki/WorkingPlans
> Sorry to ruin the thread, I just prefer constructive comments. So far
> Ilias, you have lived up to your reputation. (I really hate to admit that
> because I thought you may truly put more thought into this than your
> previous evaluations.
It is obvious (from my own site) that I don't evaluate trac.
I use it.
> 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??)
If I understand you right:
My Risk-Management-Skills (which depent or forward-looking) came from
several personal failures within software projects and from analyzing
around 4 years weaknesses and failures of Open Source Projects and
Products.
-
So, let's go to work again.
I've a trac-related commercial task (results released under BSD2
license) - more details soon!
.