On 5/4/2010 10:56 AM, mrelbe wrote:
Hello Christian and thank you for your apprehensive reply.
...
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...).
Yes, this is a good idea. We simply need to expand on HowToContribute.
About the VCS usage, I think it's indeed getting more and more common to
mirror locally a centralized source tree using DVCS tools, for keeping
track of local changes and patches while staying in sync with upstream.
We're going to make that even easier by setting up official git and hg
mirrors (#9235).
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.
I can understand this. Combined with the remark of Itamar that we're
actually using a "shifted" scheme, and the fact that in practice between
us it's common to talk about "version eleven", "version twelve" and more
seldom about "version zero dot eleven", I wonder if we couldn't simply
"unshift", drop the 0. prefix and directly go with the next version as
being version 12? That would at the same quiet down the concerns about
maturity that corporate users could have, yet change nothing in essence
to our actual sequence of major releases (0.10, 0.11, 12.0, 13.0, etc.).
As Noah said, changing that sequence to come suddenly with a "1.0" adds
some connotation of stability of the interface. We simply don't want to
be encumbered with that notion of freeze and the long term maintenance
this could imply. Trac will continue to evolve, and will do so
incrementally. I think that if we would have had a 1.0 version, this
should have been what we called 0.10 and we would now be talking about
releasing 1.2.
But in the end, it's not *that* important. If we can make Trac
advocates' life easier by picking a release numbering scheme reflecting
more adequately the level of confidence we have in our product (like in,
using major version numbers for our major versions...), I'd personally
be OK to do it. If for some reasons there are resistances to change, I
wouldn't spend much time on this, continuing with 0.13, 0.14, etc. until
the day we feel it would make sense to call it 1.0 also works for me ;-)
-- Christian
--
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.
