Jcr-Server: Request for Advice

[Angela Schreiber <an...@day.com>]

hi all

i felt quite uneasy with some of the changes commited
by brian yesterday and tried to express myself replying
to the commit-mails (sorry for spaming those that are
not involved).

but i was not sure how those conflicts should be resolved.
since i feel responsible for the jcr-server, i changed
a few things back, i considered to be not correct... but
i don't know, whether this is even allowed....

anyway, i'd like to raise the question, how such
conflicts should be handled... so far, there were
no such issues within the jackrabbit list, since every
commiter has some sort of area of responsibility. i just
remember one single incident.

thanks for advice
angela

Re: Jcr-Server: Request for Advice

[Stefano Mazzocchi <st...@apache.org>]

Brian Moseley wrote:
> Angela Schreiber wrote:
> 
>> i felt quite uneasy with some of the changes commited
>> by brian yesterday and tried to express myself replying
>> to the commit-mails (sorry for spaming those that are
>> not involved).
>>
>> but i was not sure how those conflicts should be resolved.
>> since i feel responsible for the jcr-server, i changed
>> a few things back, i considered to be not correct... but
>> i don't know, whether this is even allowed....
>>
>> anyway, i'd like to raise the question, how such
>> conflicts should be handled... so far, there were
>> no such issues within the jackrabbit list, since every
>> commiter has some sort of area of responsibility. i just
>> remember one single incident.
> 
> i've been watching apache projects for many years, and i don't recall 
> ever having seen "owners" of particular pieces of code. my expectation 
> when i was given commit access to jackrabbit was that i would be an 
> equal contributor.
> 
> i'm also used to apache projects working on a commit-then-review basis. 
> but maybe i haven't been paying close enough attention.
> 
> as i mentioned in another message, i fully expect to have a lot of back 
> and forth initially as i come to understand angela's design more fully. 
> that's natural and no problem to me. i also expect to have to back out 
> some changes when the concensus is that they are wrong.
> 
> in the case of jcr-server, i'm not sure how to build concensus and 
> resolve differences when there are only two of us who are actively 
> committing to that subproject.
> 
> of course, if the intention is for angela to be the authoritative owner 
> of jcr-server, then concensus isn't really an issue, and i'll have to 
> learn how to be more persuasive when i want changes made ;)

Correct: the ASF owns the code, nobody else.

That said, if Angela believes that it's a trivial change that might not 
upset Brian, she should just go ahead: use commit-then-review as much as 
you can.

And even when you think Brian might not understand what's going on and 
why you changed something, please state so in the logs or, even better, 
in the comments.

As far as subjective details as code formatting or variable names, it is 
up to Brian to follow the existing conventions and failing to do so 
would entitle Angela to clean it up for consistency, at least in the 
same file.

Would Brian commit a bunch of code and Angela a few patches, the thing 
would be reversed.

no, there is no default for subjective details and there shouldn't be 
one, don't even go there, just do what you feel appropriate and please 
try to avoid putting your ego on when you do so.

At the end of the day, be strict in what you send and be tolerant in 
what you receive.

-- 
Stefano.

Re: Jcr-Server: Request for Advice

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> i felt quite uneasy with some of the changes commited
> by brian yesterday and tried to express myself replying
> to the commit-mails (sorry for spaming those that are
> not involved).
> 
> but i was not sure how those conflicts should be resolved.
> since i feel responsible for the jcr-server, i changed
> a few things back, i considered to be not correct... but
> i don't know, whether this is even allowed....
> 
> anyway, i'd like to raise the question, how such
> conflicts should be handled... so far, there were
> no such issues within the jackrabbit list, since every
> commiter has some sort of area of responsibility. i just
> remember one single incident.

i've been watching apache projects for many years, and i 
don't recall ever having seen "owners" of particular pieces 
of code. my expectation when i was given commit access to 
jackrabbit was that i would be an equal contributor.

i'm also used to apache projects working on a 
commit-then-review basis. but maybe i haven't been paying 
close enough attention.

as i mentioned in another message, i fully expect to have a 
lot of back and forth initially as i come to understand 
angela's design more fully. that's natural and no problem to 
me. i also expect to have to back out some changes when the 
concensus is that they are wrong.

in the case of jcr-server, i'm not sure how to build 
concensus and resolve differences when there are only two of 
us who are actively committing to that subproject.

of course, if the intention is for angela to be the 
authoritative owner of jcr-server, then concensus isn't 
really an issue, and i'll have to learn how to be more 
persuasive when i want changes made ;)

Re: Jcr-Server: Request for Advice

[Stefano Mazzocchi <st...@apache.org>]

Roy T. Fielding wrote:

> Please don't worry about sending too much email to the list.
> If anything, the major reason we haven't graduated from incubator
> yet is because we haven't been doing enough discussion on the list
> regarding code changes.  So, the more you discuss these things, the
> healthier we are as a project.

very very very true!

-- 
Stefano.

Re: Jcr-Server: Request for Advice

["Roy T. Fielding" <fi...@gbiv.com>]

Actually, I think you are both doing very well so far.  We don't
have assigned responsibilities at Apache (well, other than my
responsibility to Incubator, which in turn reports to the board,
but that is only for non-technical stuff).

Disagreement over design choices is normal and even encouraged.
We would rather have a well-considered and justifiable design,
preferably with resulting documentation, than release something
that doesn't meet the needs of our own projects.  One of the
best ways to resolve a disagreement is to try to document both
alternatives in detail -- the problems with one or the other
approach can then be evaluated with more care.

Officially, when there is a concern about a commit (or even
just a plan for a commit), people generally talk about it at
first and, if necessary, vote on the alternatives.  If there
doesn't seem to be a consensus after short discussion, then
usually the new change is vetoed by one of the developers and
we move on to other things until that developer is convinced
or a better patch is proposed.

Please don't worry about sending too much email to the list.
If anything, the major reason we haven't graduated from incubator
yet is because we haven't been doing enough discussion on the list
regarding code changes.  So, the more you discuss these things, the
healthier we are as a project.

Bug fixes and previously discussed issues are generally commit
then review -- i.e., we assume it is a good change until someone
objects, and the change is reverted if it is vetoed.  Larger
design issues, like changing the public interfaces, should be
discussed here first to be sure that the changes won't wreck
someone else's dependencies on jackrabbit.

We need to learn most of this stuff as we go along.  The process
will be easier once we get more experience with releasing our code
and learn each other's expectations.

Cheers,

....Roy