On Sat, Dec 31, 2011 at 12:13 AM, osimons <oddsim...@gmail.com> wrote:
> Your summary is extremely accurate and well-documented. There is one > minor "OR" that need not be in there: As to my knowledge none of the > private communication included demands for Trac commit privileges. > Taking Trac to Apache was a hard requirement from the start, and at* no > point did WANdisco express any interest in working with the Trac > community in its current form. Either move us, or replace/duplicate > us.* > That is inaccurate. Our first discussions involved the active Trac committers along with many others previously involved in the project. Our goal was to sponsor as many full time developers as possible to work on the existing Trac project and build something significantly more substantial in terms of appeal and functionality. It was not until later that we were made aware of the current status of Edgewall as a shell company with no employees and no revenue. It was then we highlighted that for the level of investment we are making we would need proper governance and infrastructure in place to support the project. Suggesting the use of an opensource Software foundation wasn't immediate and was not the only option, although it does have many merits[1] that made it appealing. 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. 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 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. The existing approach and ethos has value and there is no reason anything has to change here if you guys don't want it to. I'm really happy to be involved in this discussion and I think we can address all of the points made if they haven't been already (It seems questions like licensing have been, even if some people missed those answers). Given the public Apache Bloodhound mailing list is to be launched very shortly, I think most of my input into the discussion of the plans will be best made there and of course anyone is welcome to participate in that too. Best Wishes, Ian [1] http://dirkriehle.com/publications/2010-2/the-economic-case-for-open-source-foundations/ [2] http://www.ohloh.net/p/trac/analyses/latest -- Ian Wild Director of Engineering WANdisco, Inc. http://www.wandisco.com uberSVN: Apache Subversion Made Easy http://www.uberSVN.com <http://www.ubersvn.com/> Everything you need to deploy Subversion in the Enterprise http://www.wandisco.com/subversion<http://www.wandisco.com/subversion/multisite> Subversion community http://www.svnforum.org -- 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.
