The success of Django
Kless
that can be added easily mini-applications in another projects.
This has allowed that exists more than 1000 applications in Google
Code and more than 400 in Git [1]. I know that many will be in both
code hostings, but if you compare to:
TG => 53 in GoogleCode and 7 in Git
Pylons => 55 in GoogleCode and 5 in Git
I believe that the results speak themselves.
*TG has to have an API for that can be added easily mini-applications
and following re-using code.*
It also have been very importan to create a great documentation from
scratch. But TG2 already has a great documentation, a great work!
[1] http://code.google.com/hosting/search?q=django&projectsearch=Search+Projects
http://github.com/search?q=django&x=0&y=0
[2] http://code.google.com/hosting/search?q=turbogears&projectsearch=Search+Projects
http://github.com/search?q=turbogears&x=0&y=0
[3] http://code.google.com/hosting/search?q=pylons&projectsearch=Search+Projects
http://github.com/search?q=pylons&x=0&y=0
Stephen DeGrace
For a long time I resisted Django and was attracted to TG - the basics of TG's design appeal to me more, and Django's former practice of everyone using trunk code instead of the official release made me queasy. They fixed the release thing, though, and are on a regular schedule of official releases. But the biggest thing that really made me abandon TG for Django was apps. That was a huge hole in TG for me. Not just for the comparatively easy plugin functionality, but also for the way it makes it natural to organize your code into chunks by content type.
I've gotten used to their templating system, too... I like the idea of XML templates better, but I'm getting used to their philosophy, and it is dead easy to extend their template language to do really sophisticated things. The templatetag system gives you a good way to violate MVC when it needs to be violated... no need to push data into the view for "side content" not directly related to the main content. Helps keep things cleanly separate. Could probably do something like that in Genshi, though?...
The docs for Django sometimes seem a little thin and I need to go to the source code to get the odd question answered, plus sometimes finding something is a little labyrinthine... but it doesn't match the frustration I've had trying to work with the TG docs, which I hope improve.
I'm doing all my work in Django now, but keeping an eye on TG. I'm still interested in the project.
Stephen
Jorge Vargas
>
please note I don't dislike django even though this post may lead you
to believe so.
> I think that the fundamental factor for the Django success has been
> that can be added easily mini-applications in another projects.
>
mounting apps, in tg2 adding an application coded in any web
framework, or the lack of one is as simple as doing.
from foo import app
from tg import use_wsgi_app
@expose()
def other_app():
return use_wsgi_app(app)
and that isn't cheating hiding you the ugly parts if you look at the
sourcec for use_wsgi_app it about 5 lines.
So this feature in itself is better than what django has to offer.In
fact to this day django is the only mayor framework that doesn't
supports WSGI.
as for the 1.x branch cherrypy has the mount operation, which I'm
certain can be used with 1.5 but I'm not sure if it can be used with
1.1 so lets call it even on the "mounting apps"
> This has allowed that exists more than 1000 applications in Google
> Code and more than 400 in Git [1]. I know that many will be in both
> code hostings, but if you compare to:
>
> TG => 53 in GoogleCode and 7 in Git
> Pylons => 55 in GoogleCode and 5 in Git
>
> I believe that the results speak themselves.
>
#1 turbogears apps don't always call themself turbogears, some
examples that come to my mind tgregistration, turbomail,etc. so you
are missing there some packages
#2 many of the 'django apps' are really components so you have to add
into the mix all toscawidgets/turbogears widgets packages.
#3 a lot of turbogears stuff is hosted in the same repository as
turbogears, as well as the toscawidgets repo and tgtools
#4 you forgot to count http://turbogears.org/cogbin/
now on the django part,
#1 how many of those a "blogs"? seriously I watched a presentation
from djangocon where the expositor asked who has written a blog in
django and everyone in the room raised their hand, now the important
thing he is that when he asked "and actually publish it's source code
on the web" only half the people lowered their hands.So that's about
50 apps less if I recall correctly
#2 how many actually have and active set of commiters? or more than
one commiter or even more than 100 revisions?
in general tg/pylons/etc. due to it's ideals is a bunch of stuff put
together so every little bit of improvement is taken in and
accommodated, so comparing the number of monolithic apps a framework
that isn't monolithic has (leaving out all the pluggable components)
vs everything (because in django everything is an app) a monolithic
framework provide is a really bad comparison.
Another thing what happen to pypi which is considered a well establish
source of python packages?
according to this link http://pypi.python.org/pypi?:action=browse
Turbogears as almost double the packages django has
TG 90
django 57
pylons 10
let me close with an argument that isn't mine, but Mark's
http://compoundthinking.com/blog/index.php/2008/06/24/but-im-not-dead-yet/
another thing which I'll leave you as is to check mailing list
traffic. I'm sure django has more users asking questions.
> *TG has to have an API for that can be added easily mini-applications
> and following re-using code.*
>
> It also have been very importan to create a great documentation from
> scratch. But TG2 already has a great documentation, a great work!
>
for it's documentation, IMO it's a good set of docs but it really
isn't the best feature it can offer.
Diez B. Roggisch
> TG's design appeal to me more, and Django's former practice of everyone
> using trunk code instead of the official release made me queasy. They fixed
> the release thing, though, and are on a regular schedule of official
> releases. But the biggest thing that really made me abandon TG for Django
> was apps. That was a huge hole in TG for me. Not just for the comparatively
> easy plugin functionality, but also for the way it makes it natural to
> organize your code into chunks by content type.
I just recently got saw a presentation of django-users on the Python Users
Berlin group. And while I was seriously impressed by the speed the guys
developed great looking apps with buttloads of functionality, I didn't see
much that really wouldn't be possible with TG - if it's not already there.
Some examples:
- TG and TW widgeting is IMHO a *much* better approach on organizing python,
JS, HTML & JS than django offers. Nothing in e.g. (new)forms is as powerful
as tw.forms (or the old tg-form-widgets), and while you *can* structurize
your templates to make them more re-usable, *nobody* forces you - or even
gives you examples on to how to do that properly. But creating a widget is a
straightforward thing.
- the ORM is very explicit and simple compared to SA (and even SO)
- it's nice to have a way to map arbitrary urls to your controllers - but
it's not so nice that you *have* to do it. And TG2 comes with routes - which
we happily mix with the standard approach of creating urls through
hierachical controllers
- the validation wasn't much more than what the above url-scheme offered.
Then you can of course validate forms, but that's explicit code in your
controllers. Nothing compared to the power & flexibility of FormEncode and
@validate IMHO.
> I've gotten used to their templating system, too... I like the idea of XML
> templates better, but I'm getting used to their philosophy, and it is dead
> easy to extend their template language to do really sophisticated things.
> The templatetag system gives you a good way to violate MVC when it needs to
> be violated... no need to push data into the view for "side content" not
> directly related to the main content. Helps keep things cleanly separate.
> Could probably do something like that in Genshi, though?...
Sure! It is already done, you can pull in anything you like in e.g.
master.html, by using <?python ...?> processing instructions for example. And
there are callback-lists defined (in TG1, the variable_providers) that you
could register a callback to enrich the template variable space.
IMHO, the biggest advantage of TG is one of it's weakest points at the same
time: the component-and-best-of-breed-structure. It's great for many reasons
e.g. Mark has elaborated on - but it's a weakness when it comes to
documentation & maybe sometimes consistency. If I want to know how something
works, I have to dig into *several* docs & codebases. Or we start writing a
full coverage, but then how's that integrating with the original docs, and to
keep in sync?
Tackling this is for me the biggest challenge.
Diz
Kless
> let me close with an argument that isn't mine, but Mark'shttp://compoundthinking.com/blog/index.php/2008/06/24/but-im-not-dead...
>
Agree. Then a problem is the visibility. And it's understood that
cannot be created posts about all that work because the time will be
quite little. So I proposal that been created a twitter account where
can be written and seen fastly the changes. It could be added the
changes of all projects that TG depends on.
Daniel Fetchinson
I agree with Diez that technically tg is not inferior to django in any
respect, apps can be "mounted" easily via the WSGI mechanism. But I'm
also wondering sometimes why is it that django is much more popular.
Being technically good doesn't always guarantee success (I'm sure we
all agree on this) and I'm wondering if maybe it's the marketing of tg
or something else that is somewhat behind django these days.
I personally don't care about popularity, I'm using tg because I like
it, but for the general well being of a project it doesn't hurt to be
popular :)
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Christopher Arndt
> But I'm
> also wondering sometimes why is it that django is much more popular.
> Being technically good doesn't always guarantee success (I'm sure we
> all agree on this) and I'm wondering if maybe it's the marketing of tg
> or something else that is somewhat behind django these days.
I think that a very big factor in the popularity of Django is that Guido
van Rossum mentioned once in a blog post that he likes Django and is
using it for his own foray into web development (an area of software
development he hadn't explored that much apparently until then). AFAIK
he is still using Django for his development at Google.
This came at a time when the race for which would be the most popular
Python web framework was still undecided and many people from the
outside got the impression that Guido blessed Django as the "official"
Python web framework and I still meet people who believe it to be that way.
At the same time, the Django people had a very impressive marketing
output (screen casts etc.) and a good looking web site (regularly
updated & improved). They also managed to keep their marketing effort at
a high level and keep Django "in the news" by regular information about
new developments etc.
This attracted many new users and contributors and therefor created a
positive feedback loop: more contributors --> more things get done and
marketing effort --> more visibility --> more user & contributors etc.
I'm not claiming that Django's popularity is solely based on marketing,
but I think that if TurboGears had managed to put in the same marketing
effort it would be much more popular and widely used today than is the case.
TurboGears suffered from two changes of leadership within one year, a
long time where it wasn't clear which direction it would be taking -
probably because we didn't know it ourselves for some time - and when we
did, we didn't take enough care to make our plans widely known. When the
project was back on track strategy-wise, it had already lost many of
it's earlier contributors and users and progress has been rather slow
since then due to lack of "personnel".
If we are being honest, TurboGears today, while being once a contender
for the most popular Python web framework, now is often not even
mentioned when people talk about Python web frameworks. I think, it will
take a long time to recover from this situation, if it is possible at
all. Of course popularity is not everything, but it is very important to
keep an open source project alive - see below.
> I personally don't care about popularity, I'm using tg because I like
> it, but for the general well being of a project it doesn't hurt to be
> popular :)
As already mentioned above, I think popularity is very important. The
nature of open source projects is very fragile since core developers may
drop out at any time for different reasons so there needs to be a steady
influx of new contributors to give them time to get involved and advance
to a level where they have a good understanding of the overall project
structure, the code and the customs of the community.
It took me about one and a half years, I think, to obtain a knowledge of
the TG 1.x code base where I could say with confidence that I mostly
understand what's going on in the different parts. This may have been
aggravated by the complexity of the TG 1.x code which IMHO grew too fast
and too unstructured, while at the same time being severely
under-documented (and I don't mean user documentation). I have kept away
from much involvement with TG 2 until now, because, to be honest, I'm
shying away from the effort of digging into another code base of similar
complexity.
Putting in such an effort is only reasonable if there is an "outer"
motivation for this. I contribute to TG because sometimes it's fun and
because I use it for my business, but if you want to maintain a project
that's useful for many people, it is not enough to care for your own
needs only, but you also need to attend to the problems of other users
(be they big or small) and keep an eye on the path the project and the
code takes. This is where the popularity comes in. More popularity means
more positive user feedback and hopefully more people willing to help
out because they want to be part of the popular project. And for me,
this is a very big part of the motivation for my work on TG. If I sense
that nobody cares about what I do, I will feel frustrated and loose
interest very quickly.
For TurboGears it has been difficult in the past months (or even years)
to find contributors who are willing and able to contribute something
other than tickets and patches. IMHO the TG core team members (and I
count myself among them) have failed to recognize the importance of the
other areas of project development besides coding and the danger of
neglecting them or, if they did, failed to do something about it. This
is not surprising since most of us are developers by trade and so are
susceptible to a wrong perspective, but it is still lamentable.
This post turned out longer than I intended and I ended up venting some
of my frustrations and thus probably sounding more negative than I
really feel about this, but some of these things had been on my mind for
some time and wanted out... ;)
Chris
Daniel Fetchinson
Excellent summary, Chris. I also remember Guido's remark and at that
time I was about to choose between frameworks and naturally I was
biased towards django as a direct result of his comments. But after
digging into both I decided to go with tg and I didn't regret that
decision.
andy
This post is old but it mentions TG:
http://blog.ianbicking.org/2007/08/21/the-shrinking-python-web-framework-world/
TG1 is listed 3rd on the 'popular list' of Python WEB frameworks:
http://wiki.python.org/moin/WebFrameworks
I appreciate the work you are doing, and I use TG1.0.7 for my WEB site
and am
trying to use TG2 on my current project.
My #1 wishlist item for TG would be for the development to converge on
a
single release train (2.0), and for more ready-to-use WEB site
components,
like drop-down or sidebar menus, site map, shopping cart, search/
display,
dynamic forms, trees, etc.
It really isn't that clear to me why there are 4 release trains at
once,
or why I should pick one release over another. I like Genshi,
but I was happy with Kid. I like SA, but I was happy with SO.
I want to start using ToscaWidgets, but am not excited about changing
anything else in the code to do it.
I picked TG1 over lots of other stuff because it was the most straight-
forward
to get a real WEB site working, and the docs were the best. I did not
care
about Kid or CherryPy or TG widgets vs. TW. I did care that SQLObject
was supported
though. But now the docs seem a bit scattered and inconsistent across
the release trains.
I plan to start using TG2 soon. I played around with 1.1 and 2.0 some,
but ran into weird
issues like the exact same template code and CSS displaying
differently on Kid and Genshi.
thanks,
Andy
Mark Ramm
> for the most popular Python web framework, now is often not even
> mentioned when people talk about Python web frameworks. I think, it will
> take a long time to recover from this situation, if it is possible at
> all. Of course popularity is not everything, but it is very important to
> keep an open source project alive - see below.
Django started earlier than TurboGears and had more mailing list
members than we did for most all of the lifespan of the two projects.
But it's probably worth reminding folks that Zope probably has been
and continues to be more widely deployed than either TG or Django.
Django is currently seeing popularity in the python web framework
space that's unparalleled in the history of Python, with the possible
exception of the early days of zope. And django is a great toolkit
that brings lots of people to python, so I think we should all be
happy about that.
I also think that the number of people using TurboGears continues to
go up, not down. The thing is just that django users are going up at
a much faster rate than TG. I think some of this comes down to the
Django team having better docs, better marketing, and a more solid
record of steady momentum.
But, with all that said I think TurboGears is at the begining of a new
era. We've got a couple of major releases coming out in the next few
weeks, and TG2 has brought together a set of libraries that makes TG2
technically superior to Django in a number of ways, and we have an
oportunity to bring a whole new set of people into the python
web-framework fold.
Someone just told me that they spent two days creating an ext.js+tg2
app with database transactions across four different DB's and some
other fancy features. I also recently got to see a demo of a very
spiffy TG2 app that went live a couple of weeks ago:
And my company Compound Thinking is about to release it's first TG2
app into production in the next couple of weeks. There's a lot to be
excited about, but if we're going to succeed we need to push forward
that last few inches, get a stable release finalized, continue to
improve the docs, and start being much more active about telling
people the cool stuff that we've done.
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Iain Duncan
> go up, not down. The thing is just that django users are going up at
> a much faster rate than TG. I think some of this comes down to the
> Django team having better docs, better marketing, and a more solid
> record of steady momentum.
I agree with the above. IMHO I would also add ( though none of us like
to admin it ) that Django has also had a better record of being pretty
fanatical with regard to new user experience. This includes docs, but
also includes things like not releasing new features until they are
documented and make sure they don't break.
I think the big thing in a nutshell is that the Django team put
*attracting users* at the very top of the list. That is a major major
philosophical difference with pretty far reaching consequences. IMHO TG
lets features trump new user experience instead, which is great for
getting good code, but bad for marketing. ( not that I know the right
balance or anything )
>
> But, with all that said I think TurboGears is at the begining of a new
> era. We've got a couple of major releases coming out in the next few
> weeks, and TG2 has brought together a set of libraries that makes TG2
> technically superior to Django in a number of ways, and we have an
> oportunity to bring a whole new set of people into the python
> web-framework fold.
The key to this taking off will be docs and consistency. Perhaps
something that tests tutorials to make sure that they are never out of
sync with the installable package? Do we already have something like
that? ( I know lots of great google summer of code stuff happened ).
my two cents
Iain
clive....@googlemail.com
fact the original post resulted in an objective, informed discussion
rather than a flame war. Speaks volumes about the quality of the TG
community. I've no experience with the Django community - mayhap
they're just as good and that its something about Pythonistas ... but
like several others here have mentioned, I also originally chose TG on
its technical merits (i.e. personal preference in that regard), but
the community is a big factor of what's kept me here.
Cheers,
C
Florent Aide
Thanks a lot for this remark. This is the kind of feed-back that gives
a warm feeling when we read it.
Florent.
stefaan
for the end user: one can choose one of many templating languages,
one of many ORMs and so on.
In my humble opinion Django is winning
because it reduces the freedom for the end user:
iirc there's a built-in templating language and ORM.
Freedom is great for a technical expert,
but it is devastating for a newbie.
If you haven't seen the talk "The Paradox of Choice, Why more is
less.",
( video.google.com/videoplay?docid=6127548813950043200 )
I'd like to invite you to do that now: it is one of the most
interesting talks I have ever seen, and it has immediate applications
in very diverse areas, including explaining why Django wins over TG
(for a suitable definition of "wins") :)
Best regards,
Stefaan.
stefaan
Christoph Zwerschke
> In my humble opinion Django is winning
> because it reduces the freedom for the end user:
> iirc there's a built-in templating language and ORM.
Yes, that's surely one of the crucial points. Actually, it was also TG's
paradigm to choose the best of breed for you already. The devastating
things was when the choice of SQLObject and Kid and later even CherryPy
was replaced by something different, and things started to fray out.
That's not to say that the new choice wasn't better, but I think this
was and is still the biggest hurdle for newbies because it creates a lot
of incertitude and forces them to make decisions at an early point.
-- Christoph
Mark Ramm
>
> One of TG's design goals is to provide maximal freedom
> for the end user: one can choose one of many templating languages,
> one of many ORMs and so on.
IMHO, that has never been the design goal of TurboGears. We want to
provide a full-stack best-of-breed system. It's just that we got
mixed up a bit on what gets included in that full stack and that left
a few too many choices in front of the new user (kid vs genshi, SA vs
SO)
Pylons wants to be maximally flexible. TG wants to be maximally
useful out of the box, and reasonably flexible. ;)
--Mark
Daniel Fetchinson
Agreed. I consider myself an experienced programmer in general and
experienced in python in particular, nevertheless I'd prefer the
developers make choices for me concerning tg. It doesn't limit me in
any way since the developers are much more experienced in the field of
"web development" so surely they will make a better choice than me.
Most importantly if the choice is already made for me I don't waste
time researching the subject.
That is why sane defaults that are BANG, IN YOUR FACE are very
important so that guys like me don't even see the various
possibilities and so tg looks like django in this respect. Guys who do
want the freedom still can make the choices if they wish, so for them
tg is better than django.
All in all the ONE AND ONLY ONE WAY TO DO IT aspect should be in the
forefront, docs, tutorials, website, etc, experienced guys will find
the endless possibilities and choices anyway since, welll, they are
experienced :)
Stephen DeGrace
CherryPy is pretty poorly documented, IMHO, and obviously the docs don't include the various TG decorators and addons which presumably would be the normal TG idiom for using CherryPy... the CherryPy docs quite naturally use a different idiom. TG need to spend some time documenting CherryPy better. SQLObject has decent docs, even if it was a monster single page the last time I looked... Kid and Genshi have great documentation, IMO.
TG itself before TG2 has frustrating, fragmented documentation. Django in contrast has good, unified documentation which while not perfect is an area they focus on and constantly try to improve. Far from being a gimmick or propaganda, this is a core, crucial foundation of that project's success, IMO, speaking as someone wanting to develop for the web in Python and coming to it unfamiliar with the plethora of projects out there. TG seems designed to be practical only for the experienced initiate of that community - a bit of a Catch 22.
I agree with the posters who have indicated that TG's current lack of solid defaults is a serious barrier of entry. IMO, there should be one clear way to do everything, e.g., use Routes for URLs, CherryPy for dispatch, SQLAlchemy for ORM, Genshi for templates, with the preferred TG idiom for using each component clearly explained and demonstrated. As interesting as it actually all has been, if I want to get something done I don't have time to research two or three obtions for every layer in the stack and ponder the best choice going forward before I even start. If I wanted to do that, why turn to a framework like Rails, Django or TG to begin with? The flexibility is a good thing but I think becomes more useful later on when you've got more background.
I spent upwards of six months in my (admittedly rare) free time playing with Turbogears and in that time I think I spent most of my time researching components and options and the rest of the time gnashing my teeth in frustration trying to figure out how to do things. There was little in the way of "rapid application development" going on. In all that time, while I got a lot of parts in place, I never managed to get to the stage of any kind of functioning prototype website.
In just a few weeks with Django I have far surpassed anything I ever accomplished with TG and have vast sectors of working prototype to play with. Granted I am far from a professional programmer, but I am not inexperienced with Python and I'm not stupid... there's a problem here.
Finally, the app thing bears underlining. Yes, it has been explained that it is possible to organize your project into something like Django apps, as an option, but the default configuration encourages you to slop everything into a few monolithic files (consider what you have to do to get identity running), none of the available addons like identity and registration make use of any such useful mechanism, and a non-TG-expert approaching the problem either needs to consult and expert or perform heroic acts of research to figure out how to do it - and there is not necessarily one obvious way to do it, I think. It's messy messy messy.
Organising your project into apps, to use the Django language for the concept, is an enormous boon to many kinds of project and in working with TG I found my top priority in my project was to figure out a way to reinvent that wheel in TG. Which I would have done except that I was tipped off about Django in this respect, and seeing that they had apparently come a long way since the last time I looked at them, including adopting a non-scary release cycle, I dove right in and haven't really looked back. IMHO, and this is just in terms of what I think TG needs to do in order to meet my own needs, TG needs more than the capability of organising itself into apps, this needs to be front and centre in the documentation with a single, clear way to do it and TG should be extensively organized around that concenpt, e.g., identity and registration should be encapsulated in apps. This is a good idea that IMO TG needs to adopt and even improve upon.
I hope I'm not being too presumptuous in saying that I think that TG is a great project with a lot of potential, but I think it has some serious problems that are considerably inhibiting that potential. I get the sense that there is a clear-eyed awareness of these problems in the TG community and a sense of moving in the right direction to address some of these concerns and realize some of that unfulfilled potential. Although TG is still IMO a bad fit for me at this time compared to Django, I look forward to what TG will do in the future. Certainly Django does not deserve to be the "one default Python web framework" - if the fragmentation of the Python web application development community compared to Ruby has one silver lining is that the competition and diversity should encourage constant growth and improvement.
Thanks for your patience,
Stephen
Jorge Vargas
some historic notes on why some things are like they are, below
On Sun, Dec 14, 2008 at 9:52 AM, Stephen DeGrace <deg...@gmail.com> wrote:
> Thinking over this discussion and my time experimenting with Turbogears, I
> have the say one of the project's biggest problems is the barrier of entry
> to new users. I haven't seen the TG2 docs, but the current docs are
> frustrating and scanty, and turning to the documentation for the components
> is a spotty experience.
>
> CherryPy is pretty poorly documented, IMHO, and obviously the docs don't
> include the various TG decorators and addons which presumably would be the
> normal TG idiom for using CherryPy... the CherryPy docs quite naturally use
> a different idiom. TG need to spend some time documenting CherryPy better.
> SQLObject has decent docs, even if it was a monster single page the last
> time I looked... Kid and Genshi have great documentation, IMO.
>
could try to upgrade the documents of other projects there is always
the need to upgrade our own documents first, and we don't have all the
time in the world. But newer versions of TG have taken into account
documentation as a factor of "best of breed", you can tell that by the
Genshi, SQLAlchemy, etc. documentation.
> TG itself before TG2 has frustrating, fragmented documentation. Django in
> contrast has good, unified documentation which while not perfect is an area
> they focus on and constantly try to improve. Far from being a gimmick or
> propaganda, this is a core, crucial foundation of that project's success,
> IMO, speaking as someone wanting to develop for the web in Python and coming
> to it unfamiliar with the plethora of projects out there. TG seems designed
> to be practical only for the experienced initiate of that community - a bit
> of a Catch 22.
>
they are the only ones using those components therefore they have to
write docs for their own stuff. While in TG for example SQLAlchemy is
used in a lot of other contexts therefore it's documentation is way
more richer.
> I agree with the posters who have indicated that TG's current lack of solid
> defaults is a serious barrier of entry. IMO, there should be one clear way
> to do everything, e.g., use Routes for URLs, CherryPy for dispatch,
> SQLAlchemy for ORM, Genshi for templates, with the preferred TG idiom for
> using each component clearly explained and demonstrated.
about using the best there is for each component, sadly (for project
maintenance) things aren't static, and what is best evolves. Lets put
it in context back when 0.5 was released (3 years ago!) SQLAlchemy
didn't exist, and kid was the best XML-template around, and I'm not
really sure why Cherrypy was chosen. Anyway ever since we defaults
have been chosen because they are better, Genshi is several orders of
magnitude faster than Kid, just to put one example. Sadly we had to
support legacy systems therefore support for both was added and then a
third and sometimes a 4th (at least regarding templates), so we kind
of shifted from "best of " to "choose your own" which was fine because
you still had a "best of" default but it wasn't best and people always
swap it out. So back to today, TG 1.1 is almost out of the door which
is finally making those new defaults. and TG2 is actually a super code
cleanup to get rid of the "more than one way of doing things" with a
little twist because if you know what you are doing, you can replace
components very easily.
> As interesting as
> it actually all has been, if I want to get something done I don't have time
> to research two or three obtions for every layer in the stack and ponder the
> best choice going forward before I even start. If I wanted to do that, why
> turn to a framework like Rails, Django or TG to begin with? The flexibility
> is a good thing but I think becomes more useful later on when you've got
> more background.
>
> I spent upwards of six months in my (admittedly rare) free time playing with
> Turbogears and in that time I think I spent most of my time researching
> components and options and the rest of the time gnashing my teeth in
> frustration trying to figure out how to do things. There was little in the
> way of "rapid application development" going on. In all that time, while I
> got a lot of parts in place, I never managed to get to the stage of any kind
> of functioning prototype website.
>
> In just a few weeks with Django I have far surpassed anything I ever
> accomplished with TG and have vast sectors of working prototype to play
> with. Granted I am far from a professional programmer, but I am not
> inexperienced with Python and I'm not stupid... there's a problem here.
>
on trivial application a lot faster, but what about complex things? if
you want to write a blog or a site where people post things it's super
trivial in django it will take you at most 3 days, now when your pass
that point your back into the "investigating two or three ways" of
doing things because for some reason there is always 2-3 components in
django land that do the same.
> Finally, the app thing bears underlining. Yes, it has been explained that it
> is possible to organize your project into something like Django apps, as an
> option, but the default configuration encourages you to slop everything into
> a few monolithic files (consider what you have to do to get identity
> running), none of the available addons like identity and registration make
> use of any such useful mechanism, and a non-TG-expert approaching the
> problem either needs to consult and expert or perform heroic acts of
> research to figure out how to do it - and there is not necessarily one
> obvious way to do it, I think. It's messy messy messy.
>
good concept but it forces you to
a- composite only django apps
b- use django
c- not play well with non-django apps
TurboGears goal here (because we aren't quite there yet) is to leave
this to WSGI, which is the "proper" python way of doing "inter
operation between applications" I do have to say that the concept is a
lot less scary than it's name but people are scared by it anyway, and
we should provide something in the likes of django's INSTALLED_APPS,
although it should be more like "used apps" to provide automatic db
creation and such.
> Organising your project into apps, to use the Django language for the
> concept, is an enormous boon to many kinds of project and in working with TG
> I found my top priority in my project was to figure out a way to reinvent
> that wheel in TG. Which I would have done except that I was tipped off about
> Django in this respect, and seeing that they had apparently come a long way
> since the last time I looked at them, including adopting a non-scary release
> cycle, I dove right in and haven't really looked back.
method call you can mount any other WSGI app, that's a lot to say! But
we still lack the model integration. But I firmly believe this is only
of the goals for 2.1
> IMHO, and this is
> just in terms of what I think TG needs to do in order to meet my own needs,
> TG needs more than the capability of organising itself into apps, this needs
> to be front and centre in the documentation with a single, clear way to do
> it and TG should be extensively organized around that concenpt, e.g.,
> identity and registration should be encapsulated in apps. This is a good
> idea that IMO TG needs to adopt and even improve upon.
>
but it is way more limited than what WSGI middleware and acting as a
WSGI server is.
> I hope I'm not being too presumptuous in saying that I think that TG is a
> great project with a lot of potential, but I think it has some serious
> problems that are considerably inhibiting that potential. I get the sense
> that there is a clear-eyed awareness of these problems in the TG community
> and a sense of moving in the right direction to address some of these
> concerns and realize some of that unfulfilled potential. Although TG is
> still IMO a bad fit for me at this time compared to Django, I look forward
> to what TG will do in the future. Certainly Django does not deserve to be
> the "one default Python web framework" - if the fragmentation of the Python
> web application development community compared to Ruby has one silver lining
> is that the competition and diversity should encourage constant growth and
> improvement.
>
so ones again thanks for your feedback.
Philippe Lemarre
migrate from TG to Django. : DOCUMENTATION.
I'm not a 'webdev' guru , I don't really know about WSGI or Routes or
whatever and I had to struggle for every single new thing I wanted to do.
When I left a few months ago, TG people were working on the 1.06 rev,
the 1.1, (the 1.5 rev??) end the 2.0!! Stop writng code : write
documentation (this is something I wanted to write for quite a while now)
Django is far from perfect, but compared to TG it is usable and this is
with no doubt why Django is more popular
I still keep an eye on TG but I can't use it at the moment : it's for
the elit.
Cheers
Philippe
Patrick
interested in learning Django at this time. I hope the TG developers
will not despair or lose motivation over Django.
I watched a talk by Jacob Kaplan-Moss
http://www.youtube.com/watch?v=p-WXiqrzAf8&feature=PlayList&p=2AB13E31E17544AA&playnext=1&index=24
He is bright and seems like a nice guy but he freaked me out when he
became evasive when questioned about Django scaling down to a single
developer. I will always be a part time single developer.
Mark Ramm freaked me out more when he presented the Django dependency graph
http://www.youtube.com/watch?v=fipFKyW2FA4
I want TG and Pylons to be successes, I don't want to get stuck with a
huge monolithic framework. I don't think Python will go up in smoke
anytime soon but other communities do or nearly do, I am sure that
Gentoo Linux users can relate to this. I guess I am paranoid but I would
like to understand the code I am using and be able to operate
independently of a community, if need be.
I hate abstraction, I wish I could program right on the WSGI layer but I
don't have the skills(or time) for it.
Well that's my uneducated 2 cents-Patrick
Stephen DeGrace wrote:
> Thinking over this discussion and my time experimenting with
> Turbogears, I have the say one of the project's biggest problems is
> the barrier of entry to new users. I haven't seen the TG2 docs, but
> the current docs are frustrating and scanty, and turning to the
> documentation for the components is a spotty experience.
>
> CherryPy is pretty poorly documented, IMHO, and obviously the docs
> don't include the various TG decorators and addons which presumably
> would be the normal TG idiom for using CherryPy... the CherryPy docs
> documenting CherryPy better.* SQLObject has decent docs, even if it
> have to do to get identity running), none of the available addons like
> identity and registration make use of any such useful mechanism, and a
> non-TG-expert approaching the problem either needs to consult and
> expert or perform heroic acts of research to figure out how to do it -
> and there is not necessarily one obvious way to do it, I think. It's
Mark Ramm
2 documentation than there is code, at this point, and we're writing
documentation far more quickly than we are writing code.
But I agree, the way to make TurboGears more popular is to make it
easier to get started AND easier to scale up to solving hard
problems.
Django better than us at the first part, and for 1.1 and 2.0 at least,
it's not as good as TurboGears at the second.
We need to focus on user experience, and at the moment that means
making quickstart shiny, and making the docs awesome. We're moving
in the right direction on both, but need to continue to improve the
docs.
--Mark Ramm
Iain Duncan
>
> I am very new to web programming but for what it's worth I am not
> interested in learning Django at this time. I hope the TG developers
> will not despair or lose motivation over Django.
>
> I watched a talk by Jacob Kaplan-Moss
> http://www.youtube.com/watch?v=p-WXiqrzAf8&feature=PlayList&p=2AB13E31E17544AA&playnext=1&index=24
> He is bright and seems like a nice guy but he freaked me out when he
> became evasive when questioned about Django scaling down to a single
> developer. I will always be a part time single developer.
That is true IMHO. I used Django for several commercial projects, and
the TG tool choice is a lot better for our 1 to 2 person teams.
That said, the converse *could* also be true. A lot of the strength of
the SQLAlchemy/ToscaWidget/Genshi combination comes from the ease of
integrating and sending data between those layers, and I guess it
wouldn't be nearly as attractive to teams where the coder in question
did not understand each layer. But if you are using each layer yourself,
the combination is fantastic. If you have non coding designers doing
templates, it's possible that Genshi would not be attractive and
ToscaWidgets might be more pain than it's worth.
Iain
Andy Bierman
too harsh. TG1.1, TG1.5, and TG2 are pre-release code.
Perhaps that has been forgotten. The user experience is rough
with lots of pre-release code.
I'm sort of new to Python, but not to C or WEB programming.
I spent a lot of time trying out other toolkits before TG1, but
I liked the way I could actually get the 20 minute Wiki to work,
then easily adapt that code to my needs, and keep doing that
for each aspect that TG supports. I needed lots of custom SQL,
good templates, and I liked widgets, so TG1 worked out great.
One of my developer friends who does not care much about
flexibility or ORM support is using CherryPy3 + Genshi + simplejson
on his embedded projects.
One think I learned in 19 years of embedded C programming is that
nobody will ever give you credit for swapping out the plumbing for
something way better. On the contrary, they will just keep
asking when the water is going to be turned back on.
And when it is, the user doesn't see any improvement at all,
and just has to trust it was worth it. They rarely believe it was.
Well, I think that the 2.0 choices are good ones and I hope that after
TG2
the developers will stop messing with the plumbing, and work on new
stuff.
thanks,
Andy
> Cheers
>
> Philippe
Jorge Vargas
>
> I 've read this thread with interest and I'd like to say why I did
> migrate from TG to Django. : DOCUMENTATION.
>
> I'm not a 'webdev' guru , I don't really know about WSGI or Routes or
> whatever and I had to struggle for every single new thing I wanted to do.
>
stuff. Also keep in mind that due to TG nature our docs are smaller
because we rely on the components docs when they are good. Learning
Routes is a lot simpler than django's URL dispatcher, you are
potentially scared because it's a whole new package, but Routes in
itself is simply about 2-3 functions.
> When I left a few months ago, TG people were working on the 1.06 rev,
> the 1.1, (the 1.5 rev??) end the 2.0!! Stop writng code : write
> documentation (this is something I wanted to write for quite a while now)
>
>
> Django is far from perfect, but compared to TG it is usable and this is
> with no doubt why Django is more popular
>
referring to a "for dummies" way then yea your right. But ones you get
into complex systems Django works against you more and more.
> I still keep an eye on TG but I can't use it at the moment : it's for
> the elit.
>
> Cheers
>
> Philippe
>
>
>
>
> >
>
Iain Murchland
>> I'm not a 'webdev' guru , I don't really know about WSGI or Routes or
>> whatever and I had to struggle for every single new thing I wanted to do.
>>
> And with TG2 you don't have to, unless you are doing semi-advanced
> stuff. Also keep in mind that due to TG nature our docs are smaller
> because we rely on the components docs when they are good. Learning
> Routes is a lot simpler than django's URL dispatcher, you are
> potentially scared because it's a whole new package, but Routes in
> itself is simply about 2-3 functions.
>
>
can relate to both sides of this argument. A couple of comments that
might or might not be useful:
I realise its less than trivial, but where you rely on components docs,
perhaps you could try to syndicate their docs content on turbogears.org
- it makes people less scared of the "jump" across to a new package, but
it still allows the docs to be updated by those who know & develop the
components.
There is inevitably the question of HOW the components are integrated
into TG. I mean, you're not just handing us a bundle of components and
saying "here, these might be useful". They are (thankfully) structured
into a framework, but often I'm not quite sure whether my problem is
with TG or a component. If I want to change a behaviour, can I go
straight to the component, or do I have to ask TG to change it for me?
Again, I realise this is not an easy thing to document, but its where I
have the most trouble.
But I am still with TG! For me, the use of SQLAlchemy was enough to make
up my mind, and over time I'm sure there'll be other instances where I'm
glad I'm using a package devoted to a purpose, rather than somebody's
"good enough" imitation.
My 2 cents.
Jorge Vargas
<iain.mu...@gmail.com> wrote:
>
>
>>> I'm not a 'webdev' guru , I don't really know about WSGI or Routes or
>>> whatever and I had to struggle for every single new thing I wanted to do.
>>>
>> And with TG2 you don't have to, unless you are doing semi-advanced
>> stuff. Also keep in mind that due to TG nature our docs are smaller
>> because we rely on the components docs when they are good. Learning
>> Routes is a lot simpler than django's URL dispatcher, you are
>> potentially scared because it's a whole new package, but Routes in
>> itself is simply about 2-3 functions.
>>
>>
> As a newbie to TG1 & TG2 who also fits into the "non-webdev guru" slot I
> can relate to both sides of this argument. A couple of comments that
> might or might not be useful:
>
> I realise its less than trivial, but where you rely on components docs,
> perhaps you could try to syndicate their docs content on turbogears.org
> - it makes people less scared of the "jump" across to a new package, but
> it still allows the docs to be updated by those who know & develop the
> components.
>
have to say the state is this is a lot simpler now, thanks to Sphinx
(for those who don't know it. it's python's new documentation toolkit,
develop for 2.6/3.0) it not only allows interdocs jumps but it's so
great that everyone is adopting it, so right now all the major
components are using it, you can see that in action here
http://turbogears.org/2.0/docs/modindex.html and since the new
SQLAlchemy docs (0.5) are sphinx too we can integrate those. So the
Jumping situation is practically fixed.
> There is inevitably the question of HOW the components are integrated
> into TG. I mean, you're not just handing us a bundle of components and
> saying "here, these might be useful". They are (thankfully) structured
> into a framework, but often I'm not quite sure whether my problem is
> with TG or a component. If I want to change a behaviour, can I go
> straight to the component, or do I have to ask TG to change it for me?
> Again, I realise this is not an easy thing to document, but its where I
> have the most trouble.
>
integration better for example you can see for yourself how SA is
configured in model.__init__.py other things are more obscure but we
are making it so that reading that parts is very simple, for example
take a look at tg/render.py and you will see how trivial is the
integration with the templating engines. all the buffet crazyness was
drop and now it's death simple.
As for the problem itself, well there isn't really a way of solving
that. After all you will need a programmer to debug the bug, But this
is a consequense of the flexibility and the integration of modules,
rather than the monolithic package. After all the only difference is
really which module you look into.
Diez B. Roggisch
the thread has reached a certain age, and many issues have been discussed and
adressed.
But just the last couple of days I encountered one that IMHO isn't addressed
so far - and even if I don't know if there is any cure for it, I'd like to
share my frustrations.
I'm a itch-scratching-developer. I don't take problems as given, I dive into
code, and figure out what works how, why & why not.
Eventually, this sometimes makes me a commiter - TG1.x is an example for that,
and even a few bits of code inside TG2 are from me. Also for SQLObject.
However, especially with TG2, I now have to face a situation that is simply
unnerving, even if one likes to take action - I have to follow, report to and
deal with half a dozen software packages and their respective mailinglists,
issue trackers, potentially coding conventions or other community-environment
influenced aspects. And these might fail me, or at least I can't interact
with each of them the same way.
Take the trac of paster, just for an example. It's only partially working, but
you can get a ticket list >200 entries, with sereval of these several years
old. The offered version list maximum for reporting is something around 1.4.2
or so - we are at 1.7.2.
Maybe the trac isn't used. Maybe I need to go to IRC - which is a bummer, as
I'm not allowed by my sysad to use IRC. The ML has roughly a mailing per day.
I can't just put a ticket into TG2 trac, and hope it will percolate to the
proper places. Or can I? Because evetually, it *is* TG2 who get's the blame -
for e.g. paster not coping with (admittedly & sadly) malformed HTTP-headers.
This IMHO a barrier to attract new developers, either core or only the
occasional bug-fixer. Unless I *fully* dive in & become a active member of
*all* these projects, I doubt there is a good chance to get things through.
I don't know if and how django deals with this - they are monolitic from the
outside, but surely the must have responsibilities shared amongst several
persons, and most probably not everybody is allowed or encouraged to change
code wherever he likes. But I presume it's easier for them.
As I said, I'm not sure how to cope with this - but I think it's worth
pondering about.
Diez
Christoph Zwerschke
> But just the last couple of days I encountered one that IMHO isn't addressed
> so far - and even if I don't know if there is any cure for it, I'd like to
> share my frustrations.
> This IMHO a barrier to attract new developers, either core or only the
> occasional bug-fixer. Unless I *fully* dive in & become a active member of
> *all* these projects, I doubt there is a good chance to get things through.
As a solution I suggest having at least *one* TG developer volunteer who
will watch closely and participate in the development of every project
that TG depends on, and make this role as a "go-between" somewhat
official and known to the other developers.
For instance, many TG users complained about MochiKit not getting a new
release out, but in fact nobody seemed to contact the MochiKit team and
at least request a release. Only after I did that and helped out with
some issues that were considered as blockers, the new release got a move
on. And there are other projects we depend on that need some input,
stimulation and help from us TG developers.
-- Christoph
Mark Ramm
and that includes helping get them moved upstream to the projects we
depend upon where that's necessary. The obvious comparison is linux
distributions like Fedora or Ubuntu which rely heavily on stuff other
people have written. Ubuntu has created a whole web-based system to
help them track all this (launchpad).
At this point I'm not too interested in trying to create a big system
to manage the problem, but I do think we need to do something ;)
And what we have is Trac. Trac is not super-great about helping with
that kind of thing, but I think with a bit of tweeking of the process
we can handle it. If we make components for each of the projects we
depend upon, we can let people enter whatever issues they find, and we
can triage them, and push them upstream as necessary. When we file a
ticket upstreem we can copy a link to the upstream ticket into Trac.
What do you all think, is this a reasonable approach.
And does anybody want to volunteer to help keep the upstream bugs list
up to date?
Lukasz Szybalski
try emailing the author. He was quite responsive when I asked for some
help. (btw. the mailing list didn't work for a while aka it wasn't
sending emails to everybody so the paster switched to googlegroups.
Try resending).
Thanks,
Lucas
>
> This IMHO a barrier to attract new developers, either core or only the
> occasional bug-fixer. Unless I *fully* dive in & become a active member of
> *all* these projects, I doubt there is a good chance to get things through.
>
> I don't know if and how django deals with this - they are monolitic from the
> outside, but surely the must have responsibilities shared amongst several
> persons, and most probably not everybody is allowed or encouraged to change
> code wherever he likes. But I presume it's easier for them.
>
> As I said, I'm not sure how to cope with this - but I think it's worth
> pondering about.
>
> Diez
>
> >
>
How to create python package?
http://lucasmanual.com/mywiki/PythonPaste
Bazaar and Launchpad
http://lucasmanual.com/mywiki/Bazaar
Christopher Arndt
> And what we have is Trac. Trac is not super-great about helping with
> that kind of thing, but I think with a bit of tweeking of the process
> we can handle it. If we make components for each of the projects we
> depend upon, we can let people enter whatever issues they find, and we
> can triage them, and push them upstream as necessary. When we file a
> ticket upstreem we can copy a link to the upstream ticket into Trac.
>
> What do you all think, is this a reasonable approach.
>
> And does anybody want to volunteer to help keep the upstream bugs list
> up to date?
Hmm, I don't know if this will work out. The latest tg2 install from SVN
has more than 45 direct and indirect dependencies! Do we really want to
create components for all of them? If not, on what do we base the
decision to include one dependency in the list of components or not?
Also, we had components in track for Kid, SQLObject, CherryPy and other
in trac in the past, but for TG1 I moved all open tickets away from
these components, because nobody ever looked after them.
So IMHO, this would only work, if we have a maintainer for *every*
third-party component who actively looks after tickets in these
components and makes sure they are reported to & synced with upstream.
This seems like a lot of work to me and I wonder if there maybe is a
better way?
Chris
Gustavo Narea
> So IMHO, this would only work, if we have a maintainer for every
> third-party component who actively looks after tickets in these
> components and makes sure they are reported to & synced with upstream.
> This seems like a lot of work to me and I wonder if there maybe is a
> better way?
The Linux distro-style (where each package has maintainer(s)) using
Launchpad.net (which is good to synchronize with upstream projects plus a
million more things).
TurboGears is analogue to Linux distros in that they're simply a collection of
packages that play well with each other and their development model has proven
to be successful over many years -- so why try to invent another model for the
same situation?
But of course, we would have to take this model seriously, learning from
mature distros (e.g., having an official contact/maintainer(s) for a package,
change a maintainer if he becomes inactive for much time). We'll also need
more contributors, as I think we're not enough for this.
I've been practicing this within TG2 and I think it can work. I only maintain
auth-related stuff (documentation, questions on IRC and mailing lists, code in
the quickstart template and TG2 itself) and, in spite of my little spare time,
issues are usually resolved quickly... That's because I'm focused on
repoze.who and repoze.what *only*.
But again, this could only work if we have *more* contributors who commit
themselves to be the maintainers of certain packages within TG.
Cheers.
--
Gustavo Narea.
General Secretary.
GNU/Linux Matters <http://gnulinuxmatters.org/>.
Gustavo Narea
add that, to sum up, I fully agree with Christopher Arndt.
Sorry about the noise.
Cheers.
Mark Ramm
> On Wednesday December 17, 2008 14:42:30 Christopher Arndt wrote:
>> So IMHO, this would only work, if we have a maintainer for every
>> third-party component who actively looks after tickets in these
>> components and makes sure they are reported to & synced with upstream.
>> This seems like a lot of work to me and I wonder if there maybe is a
>> better way?
way, and one of the reasons that ubuntu was so successful is that they
routed around the "Big Maintainer Lock" where a package maintainer
disappeared.
What Ubuntu does is have a team, that's responsible for things. There
may be people within that team that have a specific focus, but nobody
owns a package and if somebody disapears things just route around that
problem easily, unlike if there's strong ownership.
And also it's probably important to note that Debian/Ubuntu has
several orders of magnatude more package dependencies than we do, with
significantly more complex dependency chains than we ever will.
So, while I agree that the problem is large, and important, and we
should learn from the distros, what I would propose is that we accept
responsibility as a team for making this happen.
Perhaps we ask people to enter "upstream component" as a ticket, and
the name of the component in the tags filed. Perhaps we use some
ticket tracker other than trac for tracking upstream issues (We could
create a launchpad project, and make use of some of the features they
have build for this purpose, or we could make our own little TG app to
handle these tickets)
The problem is not gathering the tickets, it's deciding wether we as a
community are interested in making the end-user experience of
TurboGears work for our users.
The good news about this model is that we have something shy of 1000
statements (not tests, just code) in the tg package, so maintaining
our code should be reasonably simple.
The disadvantage is that the maintenance work is integration and
testing and tracking down which upstream package issues belong to.
The advantage of that is that we don't actually have to fix the bugs.
Another advantage is that the upstream maintainers each have smaller
code-bases and can be more responsive, and new members of those
projects have much smaller sets of code to wrap their heads around
when they want to fix their own bug or scratch their own itch.
If it comes down to it, I'm more than willing to have all upstream
issues assigned to me. And they can all be lumped into one component
(upstream-dependency) or whatever. I think the work is worth it in
terms of improved user experience.
But I would like to have some additional help with it, and would love
it if we could get kinda organized around each providing a little bit
of help triaging bugs. I really don't think this task will become
unmanageable even for one person, but I don't like the idea of adding
yet another place where I'm the single point of failure. ;)
--Mark Ramm
> The Linux distro-style (where each package has maintainer(s)) using
> Launchpad.net (which is good to synchronize with upstream projects plus a
> million more things).
>
> TurboGears is analogue to Linux distros in that they're simply a collection of
> packages that play well with each other and their development model has proven
> to be successful over many years -- so why try to invent another model for the
> same situation?
>
> But of course, we would have to take this model seriously, learning from
> mature distros (e.g., having an official contact/maintainer(s) for a package,
> change a maintainer if he becomes inactive for much time). We'll also need
> more contributors, as I think we're not enough for this.
>
> I've been practicing this within TG2 and I think it can work. I only maintain
> auth-related stuff (documentation, questions on IRC and mailing lists, code in
> the quickstart template and TG2 itself) and, in spite of my little spare time,
> issues are usually resolved quickly... That's because I'm focused on
> repoze.who and repoze.what *only*.
>
> But again, this could only work if we have *more* contributors who commit
> themselves to be the maintainers of certain packages within TG.
>
> Cheers.
> --
> Gustavo Narea.
> General Secretary.
> GNU/Linux Matters <http://gnulinuxmatters.org/>.
>
> >
>
Felix Schwarz
> I don't know if you need a maintainer per-package, that's the Debian
> way, and one of the reasons that ubuntu was so successful is that they
> routed around the "Big Maintainer Lock" where a package maintainer
> disappeared.
>
> What Ubuntu does is have a team, that's responsible for things. There
> may be people within that team that have a specific focus, but nobody
> owns a package and if somebody disapears things just route around that
> problem easily, unlike if there's strong ownership.
I don't know Debian too much but I can tell you how Fedora does it:
There are maintainers for each package (at least one). It is strongly
encouraged that there are at least 2 co-maintainers for each package.
Furthermore 'maintaining' a package does not mean that only this person
may touch it. Most packages can be changed by the 'provenpackager' group
(all maintainers which (co-)maintain > 10 packages are part of the group).
Of course there should be a good reason to touch a package which is
owned by someone else but it is not that unusual. And I think having
people responsible for some selected packages could be a tool to
increase upstream collaboration/communication. This could be a good
'job' to get people into the developer community.
We should take care not to overload some persons.
fs
Mark Ramm
> owned by someone else but it is not that unusual. And I think having
> people responsible for some selected packages could be a tool to
> increase upstream collaboration/communication. This could be a good
> 'job' to get people into the developer community.
Yea perhaps Ubuntu went overboardin the other direction, but I totally
agree that having some focus helps. And I'd love to recruit some
people who can help focus our upstream development efforts.
But I think this whole subject deserves a new thread at some point so
that people who aren't interested in Django can hear about it and
volunteer to help out. :)
Mark Ramm
> But I think this whole subject deserves a new thread at some point so
> that people who aren't interested in Django can hear about it and
> volunteer to help out. :)
Sorry for the noise.
Iain Duncan
No you're right it's not a new thread, it just has a new subject line.
It still disappears into django land on evolution. ;-)
Iain
Jorge Vargas
I really think this is a per-package thing, the original complain was
with Paste, mainly because it's trac was unresponsive. I remember
having this experience in the past with SQLObject, and I can tell you
it isn't pretty to keep sync of bugs. Specially when the maintainers
default response is I don't use TG please provide me a SQLObject only
test so I can take a look at it. Anyway I'm not bashing on SO, just a
history note.
My take on this is really different I totally disagree we shall become
a bug back for ALL external projects, that will be insane. A bug
report regarding an external component should fall into one of three
fields
1- a bug in TG itself that is causing the component to misbehave
2- a bug in the interaction between the component
3- a bug in the package itself.
Bugs of type 3 shouldn't be handle by the TG trac, we must take them
to the component, and if possible generate a patch and bug the
upstream maintainer to patch it, close it and release it. I do think
the ticket should stay open until the bug upstream is fixed, and we
shall make a comment with the upstream ticket, but fixes and process
should happen there not here.
Now keep in mind you do not know which type the bug is up front (or at
least the reporter doesn't) so I like the idea of tagging them
"upstream", I'm just not sure if it's a good idea to have a component
or a keyword for it.
As for the package/responsibility. I have to say that realistically we
do not have enough commiters for the one maintaner per package, but we
should have some people volunteer for the "biggest packages" and use
the proper component to assign the ticket to them. And even though you
are the primary responsible for said ticket anyone can take care of
fixing it.