Hello Christian and thank you for your apprehensive reply. You pretty much answered all my questions, and you also answered questions I didn't realize I had :)
Your thoughts and strategies makes a lot of sense, and would be very useful if written down somehow among the Trac pages, which I am sure will be done. As a newcomer to the Trac project on t.e.o, this was very enlightening to read. I have followed the Trac development activities for some years now, and I am aware of the long time periods between major releases. The new approach, to decrease time between major releases, should increase the interest in taking part of the development among users like myself. I am definitely all for it. Trac is a huge project, and it's not easy to get acquainted with the code since it's large, and the nature of Python using dynamic bindings makes it an even harder effort. No, don't read this as I think its bad, I am saying this because my own background in software development is based on heavily typed languages as Ada, for military applications. I find Python and Trac very thrilling since I am deeply involved in pushing it out to development teams in industrial organisations, and I know what good it can do there. My interest in taking part of the development here on t.e.o is to gain a better understanding of the internals of Trac, to understand the culture of open-source development, to understand "the supplier" of Trac, and to understand how to expand the functionality. I therefore appreciated reading your thoughts about getting involved. There are a few hints here and there on Trac for newcomers like me, but a one-pager on Trac could perhaps be a good idea explaining things like when it's ok to take ownership of a ticket though not being part of the core team, when it's ok to set a milestone on a ticket, how to actually produce patches (this is based on my observation that you guys seem to check out the code from SVN, and then use Mercurial locally, perhaps making several clones locally to manage your own development and to produce accurate patches -- this may be natural to many, but not for industry people using commercial VCS...). I also noticed that milestones 1.0 and 2.0 were removed, and some have already commented about the fact that Trac does not denote versions as the mainstream does. I would like to make a comment about this. When it comes to introducing tools like Trac to the industry, my experience is that the main obstacle is not the product itself; it's about confidence in it (maintenance, quality, ... you know). The biggest problem I face when I talk to managers in development organisations is the fact that the version is 0.x and not 1.x. Now, this may seem silly, but since most people are not aware of Trac, even less aware of the maturity of Trac, it's quite hard to explain the version numbers. I think that this could be overcome by the help of a formal statement made on a Trac wiki page, containing pretty much what has been stated in this discussion thread. The industry have to get used to that each open-source project is driven by its own culture and personal interests, which must be handled with care of course. But we (which includes myself) should make some effort in explaining this, to provide arguments and facts to be used by Trac advocates, like myself, when facing presumptive, professional, users. Once again, thanks for your reply (and yes, I read it all, and will do again many more times) Sincerely yours Mikael Relbe -- 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.
