REQUEST - Branch for Query Module
Ilias Lazaridis
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.
.
Luis Matos
as you work in branch.
Noah Kantrowitz
left until after the workflow code makes it into trunk. Its a pretty
major rewrite of the ticket system, and I think that fields will then
be modular (meaning this patch could be a plugin instead).
--Noah
Ilias Lazaridis
> Alec can correct me if I am off base, but this would probably best be
> left until after the workflow code makes it into trunk. Its a pretty
> major rewrite of the ticket system, and I think that fields will then
> be modular (meaning this patch could be a plugin instead).
...
> > 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.
.
Ilias Lazaridis
I have another option, which is setting up an own repository which I
keep in sync with trunk,see
http://dev.lazaridis.com/base/wiki/PlanDecentralBranching
but this has a bit more initial effort (thus I have planned it for a
later point, e.g. after fulfilling the active task)]
Christopher Lenz
> [I would need a response to this, in order to plan my further efforts.
> I have another option, which is setting up an own repository which I
> keep in sync with trunk,see
> http://dev.lazaridis.com/base/wiki/PlanDecentralBranching
> but this has a bit more initial effort (thus I have planned it for a
> later point, e.g. after fulfilling the active task)]
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/
Ilias Lazaridis
Christopher Lenz wrote:
> Am 28.10.2006 um 15:58 schrieb Ilias Lazaridis:
> > [I would need a response to this, in order to plan my further efforts.
> > I have another option, which is setting up an own repository which I
> > keep in sync with trunk,see
> > http://dev.lazaridis.com/base/wiki/PlanDecentralBranching
> > but this has a bit more initial effort (thus I have planned it for a
> > later point, e.g. after fulfilling the active task)]
>
> 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.
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
.