Who is allowed to create branch (any contributor or just manifold team)?

If any contributor, then what is the recommendation for creating branches:
whole trunk copy or just single connector directory if changes are only in
this single connector?

2012/10/17 Karl Wright <[email protected]>

> Hi Maciej,
>
> First advice is to post questions of this kind to
> [email protected].  This functions in part as a repository of
> general knowledge, and it is searchable, so in the future others can
> maybe refer to answers there.
>
> Please see below for detailed answers.
>
> On Wed, Oct 17, 2012 at 4:38 AM, Maciej Liżewski
> <[email protected]> wrote:
> > Hi,
> >
> > thanks for information. Could you point me some instructions on how to
> > work with your SVN repo:
> > 1. do all changes require Jira issue reference?
> > 2. I understand there are no commits to trunk - what is the policy of
> > creating new branches?
> >
>
> Any but the most minor non-functional changes should have a JIRA
> ticket.  Small changes can, however, be committed to trunk.  For
> anything larger, especially if you might want others to review the
> change or others to contribute to the work, should have a branch
> created.
>
> The branch is usually named for the ticket, e.g.
> branches/CONNECTORS-xxx.  This keeps things simple.
>
> > For example - I have some improvements to LDAP connector (better group
> > searching, support for DN and attribute filtering, etc.) - how should
> > I process those changes? I would say it should something similar to:
> > 1. create issue with change description
> > 2. create branch referring to this issue
> > 3. commit changes to branch
> > 4. let you know there are changes to merge to trunk :)
> >
> > is above process correct? if whole process is described somewhere just
> > point me to the right resources. If there are some unwritten policies
> > also please send such info to me. TIA
> >
>
> The procedure is largely correct.  You can, of course, commit to the
> branch multiple times, and ask for others in the community to review
> your changes too, before it is merged to trunk.  Usually someone will
> check things over and remark about what still needs to be done before
> a branch is merged.  For instance, modifying the tests (or adding a
> test where there is none), where feasible, is a good idea if you are
> significantly modifying a connector.  But once it is agreed that the
> change looks good, you can go ahead and merge it yourself.
>
> While I've taken the time to write up the release process (it's on the
> wiki), unfortunately the development process has no real
> documentation.  I have no objection if you would like to create a Wiki
> page for this.
>
> Thanks,
> Karl
>

Reply via email to