Some dev-related questions

[Karl Wright <da...@gmail.com>]

Hi Maciej,

First advice is to post questions of this kind to
dev@manifoldcf.apache.org.  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
<ma...@gmail.com> 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

Re: Some dev-related questions

[Karl Wright <da...@gmail.com>]

On Wed, Oct 17, 2012 at 8:32 AM, Maciej Liżewski
<ma...@gmail.com> wrote:
> Who is allowed to create branch (any contributor or just manifold team)?
>

Just committers.

> 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?
>

You always need to create a whole copy of trunk.  svn is very
efficient about copies so this is not a problem.

Karl

> 2012/10/17 Karl Wright <da...@gmail.com>
>
>> Hi Maciej,
>>
>> First advice is to post questions of this kind to
>> dev@manifoldcf.apache.org.  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
>> <ma...@gmail.com> 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
>>

Re: Some dev-related questions

[Maciej Liżewski <ma...@gmail.com>]

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 <da...@gmail.com>

> Hi Maciej,
>
> First advice is to post questions of this kind to
> dev@manifoldcf.apache.org.  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
> <ma...@gmail.com> 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
>