Sharing people and code (was: Build Failure)

[Sam Ruby <ru...@us.ibm.com>]

Peter Donald wrote:
>
> A thought - someone (was it you???) was talking about having
> a flat permissions to access CVS across jakarta. ie if you
> have permission for project foo then you also have permission
> for project bar. This was meant to encourage the breakdown of
> inter-project boundaries etc. You would still have to go
> through the same process to apply any major patches but for
> minor brain dead fixes (like what the last two things on Avalon
> ;-]) you could just jump in and make changes yourself.

I do believe that if "bar" is meant to be a repository for common code,
then people working on project "foo" will be reluctant to refactor common
code into "bar" unless they continue to have commit rights to that code.

If I had commit access to avalon, I would have simply made those two minor
fixes (actually would have likely done it as one commit ;-]), and you would
have had an opportunity to see, comment on, and perhaps even reverse the
change based on the cvs commit message to avalon-dev.

> I was thinking that you (and any other alexandria/gump developers)
> could prove to be a useful test case. ie If you were to get full
> across the board access it may be useful because you could reduce
> the communication overhead etc. I think Alexandria/gump is a
> perfect test case as it cuts across all projects etc.

I think it is a great idea, but I am not going to unilaterally impose my
will on any subproject.  If the committers to any subproject vote to expand
their pool of commiters, I would be glad make it so.

> If that was a success then we could move to allow the various tribes
> commit access on their code bases. ie turbine/jetspeed/jyve would
> form one tribe as would avalon/james/cocoon etc (I know they aren't
> all at jakarta so this may not work for these cases).

I'm pleased to see that jakarta-avalon* is already a "tribe".

Re: Sharing people and code (was: Build Failure)

[Federico Barbieri <sc...@betaversion.org>]

Sam Ruby wrote:
> 
> Peter Donald wrote:
> >
> > A thought - someone (was it you???) was talking about having
> > a flat permissions to access CVS across jakarta. ie if you
> > have permission for project foo then you also have permission
> > for project bar. This was meant to encourage the breakdown of
> > inter-project boundaries etc. You would still have to go
> > through the same process to apply any major patches but for
> > minor brain dead fixes (like what the last two things on Avalon
> > ;-]) you could just jump in and make changes yourself.
> 
> I do believe that if "bar" is meant to be a repository for common code,
> then people working on project "foo" will be reluctant to refactor common
> code into "bar" unless they continue to have commit rights to that code.
> 
> If I had commit access to avalon, I would have simply made those two minor
> fixes (actually would have likely done it as one commit ;-]), and you would
> have had an opportunity to see, comment on, and perhaps even reverse the
> change based on the cvs commit message to avalon-dev.
> 
> > I was thinking that you (and any other alexandria/gump developers)
> > could prove to be a useful test case. ie If you were to get full
> > across the board access it may be useful because you could reduce
> > the communication overhead etc. I think Alexandria/gump is a
> > perfect test case as it cuts across all projects etc.
> 
> I think it is a great idea, but I am not going to unilaterally impose my
> will on any subproject.  If the committers to any subproject vote to expand
> their pool of commiters, I would be glad make it so.

While I totally agree on the goal I really don't think it's a matter of
cvs permssions... it's a culture we have to grow inside the jakarta
community. 

The library project can be a seed, avalon is been the center of the
avalon, cocoon and james community for a long time and prove this can be
done. 
The way it worked was people from cocoon and james were cross developers
and keeped the communities in touch. This happend because there is a lot
of common code. 

My fear is that if you open the commiters group of a project, those in
that project's tribe who feel "ownership" on the code will mainly be
pissed of by "strangers that want to mess with my code" and will
probally develop a very uncostructive attitude. To allow cross
development trust is the key factor. You have cvs write access becouse
we trust you. And we trust you becouse we know you since you've been
around enough to prove your skills. 

So IMHO it's very important to encourage people to partecipate to all
projects that are somehow related. One way to do this is to create code
relationships and that's, I think, should be the main goal of the
library project.

Once you have places like avalon and library where people talk and know
each other I belive we'll have a stronger feel of group in the whole
jakarta community.


Fede

Re: Sharing people and code (was: Build Failure)

[cm...@yahoo.com]

> Peter Donald wrote:
> >
> > A thought - someone (was it you???) was talking about having
> > a flat permissions to access CVS across jakarta. ie if you

I was talking about something like that - but not across jakarta, but for
shared code. 

I would be -1 for universal flat permissions at this moment - we need to
try it first ( let's say for few experimental repositories ). 

What I think it would be very important is making a distinction between
non-commiters who join a project and commiters from other jakarta
projects.

The current rules require a "significant contribution" or proof to be
proposed as commiter. 

I think any jakarta commiter has alredy made a significant contribution
and the bar should be lower - for example he can send a proposal with the
intended changes ( for example fixes or better integration with the
project he's working on ) and become a commiter if the proposal is
aproved.

That means someone can become commiter on tomcat if he is a commiter on a
different project and propose to maintain the integration ( i.e make sure
tomcat works fine with fooBar ) ( one example - some projects have special
needs for reloading, or logging ).

For example someone from log4j can become member if he wants to implement
a logging module that will plug log4j ( of course, all changes are still
subject to -1 votes and review by existing members ).

> I do believe that if "bar" is meant to be a repository for common code,
> then people working on project "foo" will be reluctant to refactor common
> code into "bar" unless they continue to have commit rights to that code.

Common code is a different issue - and making everyone feel involved with
the common code is just one step ( in making more people write, maintain
and use common code ).


> I think it is a great idea, but I am not going to unilaterally impose my
> will on any subproject.  If the committers to any subproject vote to expand
> their pool of commiters, I would be glad make it so.

And reverse - alexandria/gump should be open to all subprojects - since it
is shared by all projects :-)

 
> > At each test stage we could expand the notion of tribe (ie I assume
> > that velocity and turbine developers would intermix at next stage).
> > Until there is only one tribe - Jakarta. Thoughts ?
> 
> I do like the idea of incremental progress towards this goal.

+1 

Costin