Although I try to keep changes small (and thus easily
discussable/verifiable), I have some difficulties to get patches into
trunk.
An example is this tiny patch, which adds 2 missing fields (essentially
a defect) into the ticket/api.py:
http://trac.edgewall.org/attachment/ticket/3990/TicketQueryMacroAddTimestampFields.diff
and which was finally moved to an dedicated ticket for simplification
reasons:
http://trac.edgewall.org/attachment/ticket/4019
Of course I understand that changes (patches) have to be verified prior
to going into trunk, and that commiters have other subsystems and tasks
in their mind, making it difficult to verify the patches with full
attention.
So, It seems that synchronizing a development effort based on patches
is not that easy (technically, organizational - this is _not_ a
criticism to the trac team).
-
*possibility*
Possibly a more effective way would be to create a branch, which could
be used for further tasks (like Query Module Refactoring), too.
Following the naming-scheme of the project, the location would be here:
http://trac.edgewall.org/browser/sandbox/query
*request*
So, my question to the team is:
Can I have a "query" branch, on which I continue the current task, thus
changes can be verified more easily and merged to trunk in one chunk?
Within this branch, I would initially continue this task:
http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
and later some more work on the query system.
This way, patches that I provide could get applied by committers (no
need for immediate verification, as it's a sandbox).
Commit access for me (to this sandbox location) could simplify things
even more.
.
--Noah
...
> > Within this branch, I would initially continue this task:
> >
> > http://dev.lazaridis.com/base/wiki/PlanTicketQueryMacro
> >
> > and later some more work on the query system.
> >
> > This way, patches that I provide could get applied by committers (no
> > need for immediate verification, as it's a sandbox).
> >
> > Commit access for me (to this sandbox location) could simplify things
> > even more.
To summarize:
this was an offer to the trac team to do some fulltime work on trac and
an request for a resource and an optional commit access.
.
We do not usually "open up" the SVN repository on demand. The usual
process is that contributors are recommended/nominated for commit
access by someone who is already a committer, or at least a well-
known, long-time member of the community, and the other devs then get
a chance to agree or object. That's not an official policy, but it's
pretty much how we've been handling this aspect in the past.
Anyway, for your work on the query branch, I don't believe the scope
is so large that it couldn't be handled with patches (as you've been
doing). Whether you're using a tool such as svk to manage local
branches is up to you. I know some on the team use such tools even
though they do have commit access.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
ok
> Anyway, for your work on the query branch, I don't believe the scope
> is so large that it couldn't be handled with patches (as you've been
> doing).
Those patches were just the intro.
As said, I wanted to do some fulltime work on query, wiki etc.
> Whether you're using a tool such as svk to manage local
> branches is up to you. I know some on the team use such tools even
> though they do have commit access.
I've decided to use a decentral branch (although not sure how to setup
this).
Any hint is appreciated:
[OT] - Methods for Decentral Branching
http://groups.google.com/group/trac-dev/browse_frm/thread/89bbae56ca8e2e21
.