Am 25.01.2011 09:23, schrieb Alice McGregor:
> As mentioned by others, wanting "best of breed" and stable are
> somewhat mutually exclusive.
>
> OTOH, my own web framework has been stable for nearly a year and a
> half at the application level, and AFIK so has TurboGears 2.0, and TG
> 1.1 for even longer. (I still have applications in production running
> various flavours of 1.x.)
Fully agree. Things could have been organized much better. But the
problem is (again), according to my experience, the stable and
well-maintained projects have somebody behind them who feels responsible
and commited as the project "owner" and/or some kind of company backing.
This is the case for Django and Rails and also Pyramid, but
unfortunately not for TG. This is also the case for your web frameworks
since your words "my own web framework" show you feel responsible for
that. If we had somebody considering TG as his own framework, things
would a lot run better.
> I'm ignoring, for the most part, the dichotomy here. Stability (via
> consistent API, documentation, backwards compatibility, etc.) is a
> noble goal, and a fundamentally modular and well-thought-out
> underlying design should accommodate that in -addition- to allowing
> experimentation with more bleeding-edge features.
Fully acknowledge. I did not want to claim that this has been handled
very well by TG in the past. In fact I have expressed my displeasure in
the sometimes chaotic and erratic development and release management
several times. But I understand the reasons why things are like that and
that things will not change by complaining, but only by somebody
stepping up as a committed project manager again.
> This is something I've been looking for for quite some time. ;) (And
> is ever more important as I continue to refine PEP 444.)
Btw, thanks for working on that, I guess many people appretiate that.
> My personal opinion is that a bigger (mega) project needs more rules
> compared to a smaller sized project.
>
> IMHO, everything, great and small, requires a clear structure,
> organization, and workflow ("rules") in order to be useful,
> maintainable, and enjoyable. This ranges from style guidelines (i.e.
> PEP 8) through to consistent naming of API calls, even all the way up
> to following standard programming idioms.
Exactly. It also includes a good project development infrastructure
which also needs some work before TG can gather way again. For TG2 we're
still using the old TG1 server with an outdated cluttered Trac that's
only integrated with SVN, we don't have a test or CI server etc.
> There was debate of absorbing Pylons into TurboGears in order to
> provide ongoing support for 2.x users. I'm unsure if any "final
> decision" was made on that, though.
Again, I don't see a point in discussing whether we want to maintain the
Pylons code if we can't even cope with maintaining the TG code. In any
case I think that's only an option for TG2, not for a future TG3.
Btw, this discussion should be actually held in tg-trunk, not here.
-- Christoph
--
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en.
