On Sat, 31 Dec 2011, Ian Wild wrote:
If Ohloh[2] is to be believed, in the last 12 months the number of
committers contributing more than single digit number of changes to Trac has
been three, with the vast majority of the commits being
entered by Christian or Remy. That may hide other contributions, but the fact
remains that Trac as a project needs a head of steam if it is to get to a
position where it could become recognized as a
leading issue tracker again. Perhaps that goal isn't shared by everyone here,
which is fine, but that's certainly what Apache Bloodhound is aiming to do.
My main project JOSM has about 5 active SVN contributors at the moment and
2 of them beeing administrators. These numbers are not much higher, but
JOSM is a fast evolving software tool with an equal structure like Trac: A
core and lots of plugins. Like for Trac the plugins are a major factor in
the acceptance of the tool and allow independent development.
We restrict SVN access to people which have proven their qualification by
sending bug reports and patches to the bug tracker (Trac of course). They
get SVN access as soon as I think they match the project standards. From
what I know Trac uses the same approach. I had no trouble to get the
permissions needed for my work at the spamfilter.
So to push Trac forward you simply would need to fix bugs and attach
high quality patches to Trac tickets. You would get SVN access soon. For
JOSM there have been people who got SVN after 1-2 weeks as they flooded
the bug tracker with fixes (actually this is also the way I got
maintainer of this software).
And/or you write plugins to extend functionality.
Google ATM finds "19.000" pages which are very likely Trac installations,
I don't see that Trac has a problem beeing "a leading issue tracker".
See "Search Google" at "http://trac.edgewall.org/wiki/TracUsers";.
Unfortunately, no one from the initial group we contacted was able to commit to
working on Trac full time (or even part time afaik). Since then we have been
able to employ a number of experienced Python
developers who are familiar with the Trac architecture and who will be
dedicated to the project. I can assure people that the view so far is very much
in favour of maintaining compatibility with Trac and
even the idea of forking or not is certainly still open to discussion within
the Apache Bloodhound community.
I compare this request now with my situation. Someone like your company is
asking to
* change the server infrastructure and control mechanisms
* change the license
* ask if core contributors will work for you full-time/part-time
for JOSM.
Actually my answer would be no for all of these requests. It took a long
time to establish running services, the code license is fine and I like
the job I have.
I don't see why Trac people should behave different.
I truly hope none of this has to degenerate into a slanging match. I believe
our goals are broadly aligned and I'll state again that we aren't here to
undermine the Trac community of today and I simply
don't believe we will.
Actually this is what I doubt. I'm in the OpenSource business for about 20
years and I have seen a lot of this. Forks sometimes are necessary and
healthy for a software. And I also see problems with Trac development
caused by little contribution, but actually I don't see that what you do
will make the situation better.
As said: If you could point to a long list of ignored patches,
improvements, hard discussions or other larger problems - the situation
would be much different.
But in the end I don't care. You have the right to do what you want to do,
so do it. If you can create a better product than Trac which is compatible
and does work with the dozens of extensions I made for my existing
installation, then I will happily switch. Otherwise I will stick to Trac
and continue to extend and improve it when necessary.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
