> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED] On
> Behalf Of Mikhail
> Sent: Friday, May 30, 2008 1:02 PM
> To: [email protected]
> Subject: [Trac-dev] Re: Feature set [was: Re: [Trac-dev] Re: Report for
> dynamic variables]
>
>
> Noah Kantrowitz <noah <at> coderanger.net> writes:
> >
> > ... we really fix the problem with a 1-click plugin installer. I have
> been
> .
> .
> .
> > idea, they are just annoying to get working. Put this installer in
> Trac
> > core, and you get the experience I think everyone wants.
> >
>
> And it is called DLL, pardon, plugin hell ;-(
Not sure who DLLs are related to this. DLL Hell is a loading paths issue ...
> To avoid this hell the most popular plugins should be maintained
> together with
> the core Trac. And then - why make them plugins? Just make them part of
> the core
> and provide an option to turn them off if someone is picky about unused
> functionality.
The current dev team is taxed enough as is maintain the current codebase and
adding new features we all seem to agree on. As code size increases, effort
goes up in a very non-linear fashion. Two small codebases are much easier to
maintain and work with than one bigger one.
IMHO a system that requires too much tuneup will not
> survive these
> days because most people are too busy with their regular work/fun to
> search for
> and manage all these useful plugins. Someday someone will create an
> alternative
> application that has all the needed functionality by default and users
> will vote
> by their feet. Imagine Python distribution without standard library or
> Linux
> without X or gcc.
Now imagine a Python where the core python team maintained all the standard
libraries and everything was built together in one big interpreter. Most of
the new libraries being added to the std lib are external packages that they
just snapshot when making releases (ctypes, pysqlite, etc). They are still
developed independently.
I don't think things like ticket dependencies are such crucial features that
putting them behind a single checkbox is a bad idea. I would rather that
checkbox pull in a plugin than just enable built-in functionality, since it
will be transparent either way.
--Noah
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
