You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Jim Hurley <Ji...@Sun.COM> on 2007/08/28 07:10:26 UTC
development process
(Note: we made good progress on the first question... but
just leaving room for anyone else to add in before I summarized).
Meanwhile... on to the next)
As we continue discussing the "AR1" release questions/tasks...
here's the next:
> * What kind of development process do we need? JIRA issues for
> all changes? code reviews?
There's also a testing issue here (for example, do you need to
supply tests? if so, which framework or just unit tests). This
is somewhat tied into:
> * What kind of testing do we need?
It would probably be easier to tackle these (dev process and
testing process) separately.... but if they spill into one another,
than so be it.
So, regarding development process -- what do you think?
In looking around, I didn't see a norm for things (for example,
not sure if projects use JIRA for everything). We've used code
reviews inside our group at Sun for the starter kit, and it's proved
immensely valuable. I'd vote to continue it - both as a quality
measure as well as a way to get more people involved and
knowledgeable about the different pieces of code.
Please share your thoughts.
thanks -Jim
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I have no problem with somebody explicitly voting -1 or asking
> to postpone the commit for the simple reason that he feels he has to
> review it but can't find the time right now.
>
> From where I am I can't tell whether certain persons are on holidays or
> are loaded by other things and as far as I know there is no policy
> people should notify the project about these circumstances.
Which is why the above is problematic for short duration deadlines:
someone goes on a week's vacation, a 3-day review is posted, and they're
not around to vote or request postponement.
> What you try to do here is to define a new process which will (likely)
> be unique in the ASF, and you should ask yourself what makes the Jini
> codebase so different that the established processes won't work. Is it
> merely an optimization, or do you fear great mishap if we don't adopt
> your model?
Putting aside that I can't figure out what the established processes are,
a single +1 vote seems easier to get than three of them. The premise
of RTC is to prevent mishap, so with fewer minds reviewing, the more
important the expertise.
> As said before "any process can work, depending on the group of people".
> I find it hard to say which process is the right one for the current
> group to work well and probably more important which will attract new
> committers.
Yep.
> Maybe it is a good idea if people with objections speak out right now
I didn't really expect it to get any air time at all, so I'm also
fine with dropping it and moving on.
- Bob
Re: What do we want our "main trunk" to be? (was development process)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mark,
On Sep 5, 2007, at 2:11 AM, Mark Brouwer wrote:
> Craig L Russell wrote:
>> Hi John,
>> I'll give you a small perspective based on the projects I'm very
>> familiar with.
>> The trunk is where tested but not guaranteed stable code is
>> checked in. The expectation is that self-consistent but not
>> necessarily complete features can be checked in. Others can test
>> and validate and comment on the code and the functionality and
>> completeness thereof. After some iterations the code is stable
>> enough for release. (see other discussion on release practices).
>
> Hi Craig, are you referring to a discussion we had in the past here
> or to a document on the ASF website that explains the common
> procedures. In both cases could you provide a link.
Neither. I'm referring to the practices of individual projects that
I'm involved with. As you've noticed, documentation of practices of
projects isn't uniform. Once the project is formed, community
discussion results in agreement of practices, and the documentation
in the projects themselves tends to be of the "here's how to build,
test, release" and "here's what the release process is" instead of
"here's why we have a trunk and branch and tags". For and example,
you can look at http://openjpa.apache.org/releasing-openjpa.html
>
>> Breaking the trunk build means the project deliverable cannot be
>> produced, and it's a rare but unfortunately not impossible result.
>> Whoever breaks the build is expected to fix it before doing
>> anything else (including the errant committer's day job). Most
>> often the build is broken due to the committer and the builder
>> being on different platforms where there is an incompatibility not
>> visible in the committer's environment.
>> If features under development would unduly affect trunk, then a
>> special dev branch is created. There are no expectations for
>> stable dev branches. Once the dev branch is stable, it can be
>> merged into trunk.
>
> I agree there must be room for experimental branches and branches
> people
> can use to coordinate their activities when they are working
> together on
> some features. I expect that in most cases the trunk is not the right
> place for this. But as working on the *same* resources in multiple
> branches is painful (especially when doing multiple revisions) and
> AFAIK
> SVN doesn't have a decent merge history (it doesn't record what was
> merged) I hope we can keep this to a minimum through some
> coordination.
When you have a feature that is very disruptive, you would work on
that feature in isolation in its own branch, and generally not try to
merge the trunk on a regular basis. So when you do merge the
completed feature back to trunk, the number of changes to be merged
is minimal.
Craig
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: What do we want our "main trunk" to be? (was development process)
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
> Hi John,
>
> I'll give you a small perspective based on the projects I'm very
> familiar with.
>
> The trunk is where tested but not guaranteed stable code is checked in.
> The expectation is that self-consistent but not necessarily complete
> features can be checked in. Others can test and validate and comment on
> the code and the functionality and completeness thereof. After some
> iterations the code is stable enough for release. (see other discussion
> on release practices).
Hi Craig, are you referring to a discussion we had in the past here or
to a document on the ASF website that explains the common procedures. In
both cases could you provide a link.
> Breaking the trunk build means the project deliverable cannot be
> produced, and it's a rare but unfortunately not impossible result.
> Whoever breaks the build is expected to fix it before doing anything
> else (including the errant committer's day job). Most often the build is
> broken due to the committer and the builder being on different platforms
> where there is an incompatibility not visible in the committer's
> environment.
>
> If features under development would unduly affect trunk, then a special
> dev branch is created. There are no expectations for stable dev
> branches. Once the dev branch is stable, it can be merged into trunk.
I agree there must be room for experimental branches and branches people
can use to coordinate their activities when they are working together on
some features. I expect that in most cases the trunk is not the right
place for this. But as working on the *same* resources in multiple
branches is painful (especially when doing multiple revisions) and AFAIK
SVN doesn't have a decent merge history (it doesn't record what was
merged) I hope we can keep this to a minimum through some coordination.
--
Mark
Re: What do we want our "main trunk" to be? (was development process)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi John,
I'll give you a small perspective based on the projects I'm very
familiar with.
The trunk is where tested but not guaranteed stable code is checked
in. The expectation is that self-consistent but not necessarily
complete features can be checked in. Others can test and validate and
comment on the code and the functionality and completeness thereof.
After some iterations the code is stable enough for release. (see
other discussion on release practices).
Breaking the trunk build means the project deliverable cannot be
produced, and it's a rare but unfortunately not impossible result.
Whoever breaks the build is expected to fix it before doing anything
else (including the errant committer's day job). Most often the build
is broken due to the committer and the builder being on different
platforms where there is an incompatibility not visible in the
committer's environment.
If features under development would unduly affect trunk, then a
special dev branch is created. There are no expectations for stable
dev branches. Once the dev branch is stable, it can be merged into
trunk.
Craig
On Sep 4, 2007, at 1:56 PM, John McClain - Sun Microsystems, Inc. wrote:
> What is the general role/expectation of the main trunk on Apache
> projects?
>
> Classically in Jini development there was a reasonably high bar on
> checking things into "/main/LATEST" (clearcase's equivalent of the
> main trunk). Code reviews, tests, high conference in your code,
> etc. "Breaking the build" was bad and earned the ridicule of your
> peers for weeks if not months.
>
> This isn't to say "/main/LATEST" was always "release ready". At the
> beginning of the cycle less stable changes would go in and the
> quality level would be progressively raised until you got to code
> freeze where only changes that got in where fixes for bad bugs that
> you had very high conference in.
>
> At some level I had been taking for granted that River would work
> this way too, but this might be a flawed notion on my part....
>
> Another model for the main trunk would be more of a "wild west"
> model, where the barriers for check-in would be significantly
> lower. From a project's perspective the main advantages would be
> that the main trunk could be used more as a space collaborative
> development and something that gives the user community access to
> the very newest features.
>
> Obviously the goal isn't to check in bad code, but letting a few
> bits of a bad code in temporarily would be viewed as the price for
> getting a main trunk that supports more collaboration. Put another
> way, if there aren't a few bad check-ins then people are sharing
> (often?) enough.
>
> Is this a useful lenses to look at some of these process issues
> through? How do Apache projects treat their main trunks?
>
> --
> John McClain john.mcclain@sun.com
> Sun Microsystems, Inc.
> Burlington, MA
>
> And it is that way today. We are tricked by hope into starting
> companies, beginning books, immigrating to this country and investing
> in telecom networks. The challenges turn out to be tougher than we
> imagined. Our excessive optimism is exposed. New skills are demanded.
> But nothing important was ever begun in a prudential frame of mind.
>
> - David Brooks
>
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: What do we want our "main trunk" to be? (was development process)
Posted by Gianugo Rabellino <gi...@apache.org>.
On 9/4/07, John McClain - Sun Microsystems, Inc. <Jo...@sun.com> wrote:
> How do Apache projects treat their main trunks?
Of course, not in a uniform way. :-) Speaking from experience:
- generally speaking, trunk should always be in working state. Shaky
is fine, while broken isn't.
- breaking the build is not a capital sin but fixing it is considered
a top priority
- trunk is open to innovation, which might include some sort of
experiments, usually requiring a headsup to the community
- some communities have set up a "whiteboard" svn space for brave and
potentially dangerous stuff
- Apache's "Rules for revolutionaries"[1] apply
HTH,
[1] http://incubator.apache.org/learn/rules-for-revolutionaries.html
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
What do we want our "main trunk" to be? (was development process)
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
What is the general role/expectation of the main trunk on Apache projects?
Classically in Jini development there was a reasonably high bar on
checking things into "/main/LATEST" (clearcase's equivalent of the main
trunk). Code reviews, tests, high conference in your code, etc.
"Breaking the build" was bad and earned the ridicule of your peers for
weeks if not months.
This isn't to say "/main/LATEST" was always "release ready". At the
beginning of the cycle less stable changes would go in and the quality
level would be progressively raised until you got to code freeze where
only changes that got in where fixes for bad bugs that you had very high
conference in.
At some level I had been taking for granted that River would work this
way too, but this might be a flawed notion on my part....
Another model for the main trunk would be more of a "wild west" model,
where the barriers for check-in would be significantly lower. From a
project's perspective the main advantages would be that the main trunk
could be used more as a space collaborative development and something
that gives the user community access to the very newest features.
Obviously the goal isn't to check in bad code, but letting a few bits of
a bad code in temporarily would be viewed as the price for getting a
main trunk that supports more collaboration. Put another way, if there
aren't a few bad check-ins then people are sharing (often?) enough.
Is this a useful lenses to look at some of these process issues through?
How do Apache projects treat their main trunks?
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Ron,
Ronald J Mann wrote:
>
> Mark Brouwer wrote On 08/30/07 11:18,:
>
>> Ronald J Mann wrote:
>>
>>
>>
>>> I don't think this means that the entire collective need vote on any and
>>> all changes prior to committing, which I agree seems idiotic. I think
>>> what it does mean is that any putback requires a second committers
>>> public assent.
>>>
>>>
>> Hi Ron, does this mean that you also see value in Bob's process idea or
>> do you consider RTC as described at the ASF website as sufficient?
>>
>>
> <snip>...</snip>
> To be clear, my comments here are around changes to the underlying
> implementation which are presumed to have no/insignificant impact on the
> specs.
Thanks for writing this down. I agree with what you wrote and I like the
'story behind it'. Although I can't predict the outcome of this
discussion (anxiously awaiting Jim's proposal), whatever it is I believe
it would be good to capture the motivation behind it as part of the
documented process for others to understand the rationale.
> I'm a tad confused on the who owns the spec issue, but assuming
> this group has the authority, full blown spec changes I believe demand
> that the full group vote and would certainly demand RTC as well.
Me to, I hope once we brought this one to an end we can tackle that one.
--
Mark
Re: development process
Posted by Ronald J Mann <Ro...@Sun.COM>.
Mark Brouwer wrote On 08/30/07 11:18,:
>Ronald J Mann wrote:
>
>
>
>>I don't think this means that the entire collective need vote on any and
>>all changes prior to committing, which I agree seems idiotic. I think
>>what it does mean is that any putback requires a second committers
>>public assent.
>>
>>
>
>Hi Ron, does this mean that you also see value in Bob's process idea or
>do you consider RTC as described at the ASF website as sufficient?
>
>
Sorry for the delayed response...(it had nothing to do with you putting
me on the spot with Bob ;-) was away on personal issues for the past
few days). This is a difficult question for me. I'll start by saying
that I'm not a big fan of process, I prefer common sense, unfortunately
once there are a dozen or so people involved sense is rarely all that
common. As a team here we have and to some extent continue to struggle
with the notion of RTC vs CTR as there are times when one wishes to
innovate rapidly and therefore is willing to risk more of a stability
hit, whereas there are others when correctness is the primary goal.
As I read the ASF rules, I think we should rule out the notion of group
voting on individual code changes as far too heavy handed. Others have
mentioned the quality of the the minds involved on this project, most of
whom I know well and I'm perfectly happy to trust any given pair of us
to do the right thing. As such, I'm content to have the notion of RTC
mean that to commit a change requireds that the comment contains a
reviewed by reference. In the case where a change is so trivial,
dotting an i or crossing a t, I'm aware that its a pain to have to find
someone to do so, but frankly a quick post to the list and it can be
handled by anyone quickly. If the changes are deep and heady, its almost
unimaginable to me that anyone would want to commit without at least one
good pair of eyes perusing the changes first anyway.
I alluded to the Sun team's own internal philosophical struggles with
RTC vs CTR. I believe in the end after many years of angst and debate,
we've simply come to the conclusion that the fastest most reliable path
to nirvana is to RTC. I will admit, when I first joined the team I
misinterpreted the use of RTC as a bit of a personal slight on my
abilities. I'd urge committers not to view it as such. I think we've
found that RTC can contribute positively to team building, whereas CTR,
which generally occurs after problems are found, can have the opposite
effect. Yes, there are times when RTC is a perfunctory operation and
largely unnecessary, however in these moments, the cost of oversight is
very small and goes largely unnoticed. Ongoing stability is dead
critical for making any progress with this body of code and IMO, a
review by a second committer prior to putback is a necessary evil.
To be clear, my comments here are around changes to the underlying
implementation which are presumed to have no/insignificant impact on the
specs. I'm a tad confused on the who owns the spec issue, but assuming
this group has the authority, full blown spec changes I believe demand
that the full group vote and would certainly demand RTC as well.
=Ron=
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Ronald J Mann wrote:
> I don't think this means that the entire collective need vote on any and
> all changes prior to committing, which I agree seems idiotic. I think
> what it does mean is that any putback requires a second committers
> public assent.
Hi Ron, does this mean that you also see value in Bob's process idea or
do you consider RTC as described at the ASF website as sufficient?
--
Mark
Re: development process
Posted by Ronald J Mann <Ro...@Sun.COM>.
In the case of this particular package of code, despite the procedural
issues, I am strongly in favor of RTC (and I hate code reviews). Perhaps
there are two issues somewhat at odds here. RTC for River is largely
around maintaining the correctness of the source base; it is not an
attempt to prevent the introduction of new functionality (the specs are
there for that ;), I think this is perhaps why Bob raised the spec issue
again). Leaving the abstract pro and con arguments around RTC/CTR for
a moment, the hard reality of a distributed system like River is that
adjudicating that there has been no new introduction of a deadlock or
race conditions simply can't be automated and is very difficult to test.
History, therefore, has shown us that an extra dollup of engineering
effort up front pays tremendous dividends in terms of everyone's time
savings on the backend.
All this comes down to a 'rapidity of change' vs. 'correctness'
argument. Being a distributed framework, the demands for initial
correctness and the consequences for introducing subtle mistakes are far
higher than on more monolithic code. Debugging after the fact can be
extraordinarily frustrating and quite complex for any number of
reasons. Though prehaps this is somewhat out of the norm for Apache
projects, IMO, in this instance, it better serves the community that we
expend the extra effort to do the best we can to ensure that any change,
when introduced, as far as the experts can say, is sound.
I don't think this means that the entire collective need vote on any and
all changes prior to committing, which I agree seems idiotic. I think
what it does mean is that any putback requires a second committers
public assent.
=Ron=
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I'm inclined to a Review-Then-Commit policy although a 3 days period
>> before being able to check-in feels like a very long time in some cases,
>> although completely understandable from the perspective to give people
>> time to look into it. Another risk is that 'commit starvation' occurs
>> when there are no 3 committers finding the time to look into it and as a
>> result there won't be any 3 +1's required to be allowed to check-in the
>> code.
>
> I'm no doubt being socially incorrect, but...
>
> I dislike code review deadlines; code isn't correct just because a deadline
> passes.
I get what you mean and it is hard to disagree with that, but the lack
of time for others to review can be painful for those who want to
progress. I have no problem with somebody explicitly voting -1 or asking
to postpone the commit for the simple reason that he feels he has to
review it but can't find the time right now.
From where I am I can't tell whether certain persons are on holidays or
are loaded by other things and as far as I know there is no policy
people should notify the project about these circumstances. Therefore a
deadline seems reasonable, if it were only to 'force' people to give an
indication about their ability to perform reviews.
> I also don't ever expect committers to be expert in the entire
> codebase, so I'm wary of accepting +1's from only those who don't really
> understand the code being changed. So for implementation changes I'm
> tempted
> towards having a set of gatekeepers for each component (achieved by merit),
> and review must have a +1 from a gatekeeper, and no vetoes within
> max(N days, vote by gatekeeper).
In my reasoning I tried to stay within what seems to be the process
models supported by the ASF, although as you pointed out many times the
website might not always reflect the actual practices.
What you try to do here is to define a new process which will (likely)
be unique in the ASF, and you should ask yourself what makes the Jini
codebase so different that the established processes won't work. Is it
merely an optimization, or do you fear great mishap if we don't adopt
your model?
Thinking outside the ASF-process-box I like your process in theory, as
it compensates for the lack of distinct projects in the current
codebase, assuming there are enough gatekeepers for each component and
they don't act as little islands. I have seen enough organizations where
small groups of people with some authority could have tremendous impact
for others to get something done, but maybe this is where the PMC comes
into play.
As said before "any process can work, depending on the group of people".
I find it hard to say which process is the right one for the current
group to work well and probably more important which will attract new
committers.
Maybe it is a good idea if people with objections speak out right now
and if there is a chance your idea survives you can fill in the missing
pieces such as how to deal with spec changes, how will people become
gatekeeper (elected by PMC), who resolves conflicts, do you believe
committers should become PMC member by default, etc. ...
I'm currently on +0.5 which means "I like this idea, but I can't find
any rational justification for my feelings". Didn't make that one up
myself, it is from the website :-)
--
Mark
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Bob,
On Aug 30, 2007, at 3:28 PM, Bob Scheifler wrote:
> I'm trying to understand the Apache way, without a lot of success
> it seems.
> My perception so far is this:
>
> If you're looking for answers, don't trust the web site, as you'll
> likely find someone who will tell you that that part of it is
> wrong or a bad idea. And if you ask N people the question instead,
> you'll likely get back >N answers.
This is true. Apache communities have some things in common and many
differences. The truth is not documented, and "truth" has many
variations.
> Good luck storming the castle.
Actually, as you have probably guessed, there is no castle. ;-)
>
> I find this a major disincentive to participate.
This is probably something worth bringing up on a wider forum, like
the general@incubator.apache.org group. Disincentives to participate
are a problem that we (speaking for Apache) would like to address.
The more specific, the better. It turns out that a specific web site
contradiction is fairly easily corrected, if brought to the attention
of the right people.
On the other hand, if the Apache way is just too different from the
way the community wants to govern itself, then Apache might not be a
good fit.
> Probably just me.
No, I know it's not just you. The incubator project really does want
to address this kind of issue.
> Now let's steer the discussion back on course.
Ok. I do sense your frustration, and the mentors are really trying to
help.
Craig
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Craig L Russell wrote:
> So are you serious when you say " there's no downside to always granting
> karma to all codebases, because you clearly trust them not to abuse the
> privilege"?
I said I'd cease, so I'll try not to say much.
It seemed a logical outcome of what I understood to be Gianugo's
view about trust. It's not a view I share.
> I'd really like it if you can try to understand Gianugo's comments,
> because they reflect my view of Apache as well.
I have been, apparently without complete success, since I wouldn't
have said your statements really match his.
> It's difficult for me to tell whether your comments are "I understand
> the Apache way and disagree with it" or "I don't understand the Apache
> way and am trying to understand".
I'm trying to understand the Apache way, without a lot of success it seems.
My perception so far is this:
If you're looking for answers, don't trust the web site, as you'll
likely find someone who will tell you that that part of it is
wrong or a bad idea. And if you ask N people the question instead,
you'll likely get back >N answers. Good luck storming the castle.
I find this a major disincentive to participate. Probably just me.
Now let's steer the discussion back on course.
- Bob
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Bob,
On Aug 30, 2007, at 1:54 PM, Bob Scheifler wrote:
> Gianugo Rabellino wrote:
>> maybe it's my non-native English skill, but I kinda feel like my
>> messages could have been taken as confrontational
>
> Not at all. It's much more likely that I'm seen as confrontational.
I'd have to agree. One of the big difficulties in Apache is that it's
a big umbrella that contains a number of projects that are quite
autonomous, thank you very much. And once a community is comfortable
with itself, it doesn't always feel that it is the community's
responsibility to go and fix all the dead wood and incomplete
branches of the foundation's documentation. So you have lots of stuff
incompletely documented and in some places, conflicting documentation.
But rather than poking at the holes in the structure (we already know
it's not perfect), people trying to learn the Apache way should try
to grok by reading as much as possible and then asking questions. And
then take the questions and see if that bit helps to clarify.
>
>> On the other hand, there are no further gates once you
>> get to be a committer, and this is I think a major point in getting
>> people involved.
>
> You write that as an absolute, yet follow up that there are many
> exceptions
> (when you want RTC to kick in). It confuses me.
Maybe this will help: Each community has their own rules. CTR and RTC
are suggestions for starting points that communities can use to make
their own policies. The incubator exists to help communities
understand enough about what others are doing to be able to establish
their own policies.
>
>> What I'm saying is
>> that the default is CTR, with (admittedly quite a few) exceptions.
>> Note, however, how the exceptions are geared towards ensuring that
>> important stuff happens with a strong community oversight and a
>> way to
>> track progress. This is where RTC clearly shines.
>
> For me, always-RTC is a simpler process to remember and execute,
> imposes little additional overhead, and yields better code stability.
> Just my $.02.
The main point here is that in Apache, the code isn't the main thing.
There's lots of high quality open source code that exists outside
Apache and will never become an Apache project.
In Apache, the community is the most important aspect of a project.
Committers are community members first and coders, documenters, and
evangelizers second.
The more barriers you put in front of the code the harder it is to
build and sustain a community.
>
>> Here is what you don't seem to get, so I'll try to explain it again:
>> the technical factor is just one of the criteria for committership,
>> there is much more to it. In Cocoon we have quite a few committers
>> who
>> just write docs yet have access to the whole tree. We also have a
>> committer (Matthew Langham now emeritus) who never provided a single
>> line of code, but was extremely instrumental in Cocoon success and
>> advocacy, and probably one of the most "committed" persons of the
>> project. All those guys have in theory enough karma to nuke the
>> repository away, but we trust they won't and, in case they just go
>> mad, we know we can always revert.
>
> I do get it. All I'm saying is, since you're so trusting, there's no
> downside to always granting karma to all codebases, because you
> clearly
> trust them not to abuse the privilege.
This sounds like a reduction ad absurdum argument.
Part of the Apache way is to grant privileges to community members
that are necessary to their level of participation and
responsibilities. While I personally have commit rights to several
parts of the code base and web site, I don't have rights to the
entire code base and site. There are parts of the code and site that
I have commit rights to and never commit to because they're outside
my domain of expertise and/or interest. Segregation of privilege is a
central tenet of a secure infrastructure.
So are you serious when you say " there's no downside to always
granting karma to all codebases, because you clearly trust them not
to abuse the privilege"?
>
>> Trust is the key here: a committer is a *trusted* member of a
>> *community*, and the demarcation line isn't quite the codebase, but
>> rather the community behind it.
I'm having a hard time parsing this particular bit.
>
> In that line of thinking, there seems no reason not to treat all
> of ASF as a single community.
>
> Enough of my raving, I cease this line of discussion now.
I'd really like it if you can try to understand Gianugo's comments,
because they reflect my view of Apache as well.
It's difficult for me to tell whether your comments are "I understand
the Apache way and disagree with it" or "I don't understand the
Apache way and am trying to understand".
Craig
>
> - Bob
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Gianugo Rabellino wrote:
> maybe it's my non-native English skill, but I kinda feel like my
> messages could have been taken as confrontational
Not at all. It's much more likely that I'm seen as confrontational.
> On the other hand, there are no further gates once you
> get to be a committer, and this is I think a major point in getting
> people involved.
You write that as an absolute, yet follow up that there are many exceptions
(when you want RTC to kick in). It confuses me.
> What I'm saying is
> that the default is CTR, with (admittedly quite a few) exceptions.
> Note, however, how the exceptions are geared towards ensuring that
> important stuff happens with a strong community oversight and a way to
> track progress. This is where RTC clearly shines.
For me, always-RTC is a simpler process to remember and execute,
imposes little additional overhead, and yields better code stability.
Just my $.02.
> Here is what you don't seem to get, so I'll try to explain it again:
> the technical factor is just one of the criteria for committership,
> there is much more to it. In Cocoon we have quite a few committers who
> just write docs yet have access to the whole tree. We also have a
> committer (Matthew Langham now emeritus) who never provided a single
> line of code, but was extremely instrumental in Cocoon success and
> advocacy, and probably one of the most "committed" persons of the
> project. All those guys have in theory enough karma to nuke the
> repository away, but we trust they won't and, in case they just go
> mad, we know we can always revert.
I do get it. All I'm saying is, since you're so trusting, there's no
downside to always granting karma to all codebases, because you clearly
trust them not to abuse the privilege.
> Trust is the key here: a committer is a *trusted* member of a
> *community*, and the demarcation line isn't quite the codebase, but
> rather the community behind it.
In that line of thinking, there seems no reason not to treat all
of ASF as a single community.
Enough of my raving, I cease this line of discussion now.
- Bob
Re: development process
Posted by Jim Waldo <Ji...@sun.com>.
Mark--
What I was trying to state was far simpler, and far less rule driven.
I'll try again.
We have a set of committers. They are all senior engineers, and I
trust them to be adults. If they are committing something that came
from members of the community that aren't themselves committers, then
I trust that the code will have been throughly reviewed by the
committer. If they are committing something that they wrote
themselves, then I trust that they have their own mechanisms for
insuring code quality (since the ability to produce good code is the
reason that they are a committer). It might be that they have a set
of others that they use as reviewers for their own code. It may be
that they are particularly through in their testing. It may be that
they shoot from the hip, and do it very well.
Different people have different ways of reaching the same outcome. I
worry when we try to get everyone to use the same procedure; it is a
way of limiting the diversity of the community. I am also worried
about the implicit notion that we can't trust the other committers
and need to have some process so that we can check on each other
before the fact (rather than after).
This does mean that someone could behave badly. We have various forms
of recourse, from backing out a particular commit to revoking
committer status. Trust, but verify.
So when I say that I would have my code reviewed, the statement is
confessional and tells you how I do things. It is not meant to be
prescriptive and tell others how they should do things. How someone
produces good code (or good designs) is up to them...
Jim
On Aug 31, 2007, at 4:38 AM, Mark Brouwer wrote:
> Hi Jim,
>
> Jim Waldo wrote:
>
>> So let me suggest that we start with a notion of trust, and adopt
>> a CTR development process. More to the point, let's try to do
>> something with the project, rather than continually debating how
>> we are going to do anything...
>
> From your posting I sense that you think reviewing before
> committing is
> essential as you say "I doubt seriously that I would ever commit
> anything to the project without having it reviewed, either by one
> of the
> other committers or by someone who I thought could understand the code
> (no matter how complex). I trust the other committers on the
> project to
> do the same.". In the end you even use the 'moral pointy finger' [1] I
> recognize from my parents ;-)
>
> You say start using CTR but with the expectation it has been reviewed
> before it appears for commit, so in fact you suggest RT-CTR. So that
> means a contributor must look for a reviewer, in my case this would
> likely resort into an open cry into the mailing list as I'm not in the
> luxury position I have qualified people around me that have time for
> that. So I would like to know the field experts (I know a few after
> all
> those years, but still have no oversight for the complete system) and
> therefore it would help me to have a list of people qualified to
> review
> per component. I therefore fail to see why not formalize this
> behavior,
> it is a clear signal to others the way we work (confusion is often a
> reason for frustration or as Bob pointed out disincentive to
> participate). For potential users (those who only download) who have
> read our policies it might even give a hunch about how much we care
> about code quality. With JIRA we can probably modify the process
> flow to assist in the RTC policy.
>
> As an aside, reviewing before committing is not that common for
> many of
> us. The way the Jini team worked probably scored very high in the
> Capability Maturity Model, but many potential committers (including
> me)
> have worked in environments where shooting from the hip is often the
> norm. And some can shoot very well from the hip, so if you are used to
> that and have been reasonable successful it can and will be
> confusing to
> be 'morally pointy fingered' by you while the official policy is CTR.
>
> As has been expressed by the mentors social skills are very important
> and I think it is harder to develop the right social skills for the
> River community if the expectations are different from the written
> policies. In my experience just lurking on a mailing list is not a
> very
> effective way to find out how one should behave as often you see many
> deviating behaviors and various tones and that is because between
> people
> that know each other fairly well adapted ways of communicating
> start to
> arise which might blur reality for others. It takes quite a while
> to be
> able to apply all the right filters. A good example of this is Gianugo
> who felt he was being confrontational against Bob, while in fact he
> was
> facing this http://www.gizmology.net/images/tank11.jpg, a lot of steel
> armor but inside a nice guy :-)
>
> Also I think there is plenty of time left to debate these things while
> AR1 is getting out the gate. I find it more frustrating that we can't
> properly finish these kind of discussion without resorting to
> "let's try
> to do something with the project, rather than continually debating how
> we are going to do anything...". If somebody finds something a
> non-discussion, just don't participate. In this case I think most
> initial vocal committers so far lean towards RTC, so I think we should
> explore a way that would make it workable without going against ASF
> policies.
>
> [1] probably there is a proper English saying for that, if so let me
> know that way I can use if more often and correctly :-)
> --
> Mark
>
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Jim,
Jim Waldo wrote:
> So let me suggest that we start with a notion of trust, and adopt a CTR
> development process. More to the point, let's try to do something with
> the project, rather than continually debating how we are going to do
> anything...
From your posting I sense that you think reviewing before committing is
essential as you say "I doubt seriously that I would ever commit
anything to the project without having it reviewed, either by one of the
other committers or by someone who I thought could understand the code
(no matter how complex). I trust the other committers on the project to
do the same.". In the end you even use the 'moral pointy finger' [1] I
recognize from my parents ;-)
You say start using CTR but with the expectation it has been reviewed
before it appears for commit, so in fact you suggest RT-CTR. So that
means a contributor must look for a reviewer, in my case this would
likely resort into an open cry into the mailing list as I'm not in the
luxury position I have qualified people around me that have time for
that. So I would like to know the field experts (I know a few after all
those years, but still have no oversight for the complete system) and
therefore it would help me to have a list of people qualified to review
per component. I therefore fail to see why not formalize this behavior,
it is a clear signal to others the way we work (confusion is often a
reason for frustration or as Bob pointed out disincentive to
participate). For potential users (those who only download) who have
read our policies it might even give a hunch about how much we care
about code quality. With JIRA we can probably modify the process
flow to assist in the RTC policy.
As an aside, reviewing before committing is not that common for many of
us. The way the Jini team worked probably scored very high in the
Capability Maturity Model, but many potential committers (including me)
have worked in environments where shooting from the hip is often the
norm. And some can shoot very well from the hip, so if you are used to
that and have been reasonable successful it can and will be confusing to
be 'morally pointy fingered' by you while the official policy is CTR.
As has been expressed by the mentors social skills are very important
and I think it is harder to develop the right social skills for the
River community if the expectations are different from the written
policies. In my experience just lurking on a mailing list is not a very
effective way to find out how one should behave as often you see many
deviating behaviors and various tones and that is because between people
that know each other fairly well adapted ways of communicating start to
arise which might blur reality for others. It takes quite a while to be
able to apply all the right filters. A good example of this is Gianugo
who felt he was being confrontational against Bob, while in fact he was
facing this http://www.gizmology.net/images/tank11.jpg, a lot of steel
armor but inside a nice guy :-)
Also I think there is plenty of time left to debate these things while
AR1 is getting out the gate. I find it more frustrating that we can't
properly finish these kind of discussion without resorting to "let's try
to do something with the project, rather than continually debating how
we are going to do anything...". If somebody finds something a
non-discussion, just don't participate. In this case I think most
initial vocal committers so far lean towards RTC, so I think we should
explore a way that would make it workable without going against ASF
policies.
[1] probably there is a proper English saying for that, if so let me
know that way I can use if more often and correctly :-)
--
Mark
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Jim Waldo wrote:
> I think the real question at hand in RTC vs. CTR is whether or not we as
> a community trust those who are committers to the project.
Sorry, I disagree. Our team has generally practiced review-before-commit
internally for a long time, and it's not because we don't trust each other.
- Bob
Re: development process
Posted by Jim Waldo <Ji...@sun.com>.
I've been watching this debate, and I think we may have lost the
central issue.
I think the real question at hand in RTC vs. CTR is whether or not we
as a community trust those who are committers to the project. If we
in fact trust those committers, then I see no problem with CTR. The
committers have been chosen because they understand the overall
system, are capable of dealing with the complexities of the code, and
because they will know enough to know when they are out of their
depth in some parts of the system and therefore need to seek help
from others. Speaking for myself, I doubt seriously that I would ever
commit anything to the project without having it reviewed, either by
one of the other committers or by someone who I thought could
understand the code (no matter how complex). I trust the other
committers on the project to do the same. Even the best of us will
occasionally make a mistake, but I'm willing to trust us (and the
rest of the community) to find such mistakes in reviews that happen
after the commit, which can then lead to the problem being backed out.
The only reason I can think of for having some requirement for RTC is
because we don't trust some of the committers to show reasonable
judgement. That would be a good reason to have some designated
gatekeepers over various sections of the code; that means that we
only trust those gatekeepers for that part of the code. But if we do
that, I think we are showing a far deeper problem than can be solved
by RTC rather than CTR. If we really don't trust some (or all) of our
committers to know when they should have code reviewed so much that
we are unwilling to let them commit without everyone looking in, then
we have the wrong set of committers.
I don't think we have the wrong set of committers. There are some on
the committers list who have different ideas about how code should be
written than I have. There are some on the committers list whose
designs are not the same as my designs. But that, I think, is part of
the advantage of the community. I don't see that as a bad thing; I
see it as a strength.
So let me suggest that we start with a notion of trust, and adopt a
CTR development process. More to the point, let's try to do something
with the project, rather than continually debating how we are going
to do anything...
Jim Waldo
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
Bob,
maybe it's my non-native English skill, but I kinda feel like my
messages could have been taken as confrontational: I just want to
ensure you and all others that this is not the case. All I'm trying to
do is sharing my experience within the ASF as well as my concerns
about River which, IMHO, has still a lot to do to meet the ASF
community participation guidelines for graduation. While I'm not
seeing a particular blocker in RTC vs. CTR, I do see a few problems
here and there when it comes to the reasons behind this decision, and
this is why I'm chiming in. But, by no means, I mean to be
confrontational so I apologize in advance if I sound too harsh.
This said:
On 8/30/07, Bob Scheifler <Bo...@sun.com> wrote:
> Gianugo Rabellino wrote:
> >> What has been discussed that results in an increased number of, or
> >> complexity of, gates for non-committers?
> >
> > Er, well, the whole idea that being a committer is not enough
>
> Doesn't seem to really change the non-committer's gate.
I'm not sure I can parse this, sorry. Yes, there is definitely a gate
for non-committers, but this is part of the rules and the way the ASF
is designed. On the other hand, there are no further gates once you
get to be a committer, and this is I think a major point in getting
people involved.
> > that getting code in requires explicit code review and a vote from
> > peers
>
> Yet your "ideal" workflow cited later includes strong RTC for many
> things. The inconsistency doesn't make much sense to me.
In all honesty, I can't see why it's inconsistent. What I'm saying is
that the default is CTR, with (admittedly quite a few) exceptions.
Note, however, how the exceptions are geared towards ensuring that
important stuff happens with a strong community oversight and a way to
track progress. This is where RTC clearly shines.
> > 2. Apache has a somewhat strong definition of roles. Once you're a
> > committer (well, actually a PMC member), your vote counts as anyone
> > else's. Even the PMC chair has one vote which is equal to any other.
> > While there is some wiggle room, I'm pretty much positive that a
> > policy considering votes for some PMC members as more important than
> > others will clash with ASF procedures.
>
> I'm pretty sure we've also been told in the past that the PMC is
> pretty much free to define whatever processes it wants, as long
> as the bylaws aren't violated.
True. However, bylaws (as formally defined at
http://www.apache.org/foundation/bylaws) are just the ultimate bottom
line as they don't deal at all with the development process. This
said, there are a number of places withing http://www.apache.org/dev
where having a notion of a supercommitter (that is someone more
empowered than others) seriously clashes with the core values of the
foundation. A vote is a vote is a vote, over here.
> If a project can have multiple codebases, with independent committer
> sets, yet there's a single PMC (it is a PMC, not a CMC, I assume), then
> your concern about vote asymmetry doesn't seem to quite mesh.
>
> > It does indeed, that's the very notion of trust: if you're getting
> > commit access, this is because you're deemed to be *both* technically
> > savvy
>
> Projects and codebases have no consistent size, shape, or complexity,
> so savvy-ness for a large project is likely either naiive or
> imposing an unacceptable barrier to entry.
Here is what you don't seem to get, so I'll try to explain it again:
the technical factor is just one of the criteria for committership,
there is much more to it. In Cocoon we have quite a few committers who
just write docs yet have access to the whole tree. We also have a
committer (Matthew Langham now emeritus) who never provided a single
line of code, but was extremely instrumental in Cocoon success and
advocacy, and probably one of the most "committed" persons of the
project. All those guys have in theory enough karma to nuke the
repository away, but we trust they won't and, in case they just go
mad, we know we can always revert.
> > If you take the social bit out
> > of the equation, clearly you need demarcation lines between spaces
> > you're allowed to mess with. But doing so also impairs the whole trust
> > notion.
>
> So with the social bit in, committer privilege should apply to all codebases,
> it seems.
Nope. Trust is the key here: a committer is a *trusted* member of a
*community*, and the demarcation line isn't quite the codebase, but
rather the community behind it.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Gianugo Rabellino wrote:
>> What has been discussed that results in an increased number of, or
>> complexity of, gates for non-committers?
>
> Er, well, the whole idea that being a committer is not enough
Doesn't seem to really change the non-committer's gate.
> that getting code in requires explicit code review and a vote from
> peers
Yet your "ideal" workflow cited later includes strong RTC for many
things. The inconsistency doesn't make much sense to me.
> 2. Apache has a somewhat strong definition of roles. Once you're a
> committer (well, actually a PMC member), your vote counts as anyone
> else's. Even the PMC chair has one vote which is equal to any other.
> While there is some wiggle room, I'm pretty much positive that a
> policy considering votes for some PMC members as more important than
> others will clash with ASF procedures.
I'm pretty sure we've also been told in the past that the PMC is
pretty much free to define whatever processes it wants, as long
as the bylaws aren't violated.
If a project can have multiple codebases, with independent committer
sets, yet there's a single PMC (it is a PMC, not a CMC, I assume), then
your concern about vote asymmetry doesn't seem to quite mesh.
> It does indeed, that's the very notion of trust: if you're getting
> commit access, this is because you're deemed to be *both* technically
> savvy
Projects and codebases have no consistent size, shape, or complexity,
so savvy-ness for a large project is likely either naiive or
imposing an unacceptable barrier to entry.
> and socially capable of interacting with a community and
> understanding where you should be committing code and where you'd be
> better ask for peer review in advance.
Which isn't a per-codebase attribute.
> If you take the social bit out
> of the equation, clearly you need demarcation lines between spaces
> you're allowed to mess with. But doing so also impairs the whole trust
> notion.
So with the social bit in, committer privilege should apply to all codebases,
it seems.
- Bob
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/30/07, Bob Scheifler <Bo...@sun.com> wrote:
> Gianugo Rabellino wrote:
> > I still contend that the
> > main objective of this timeframe should be getting others involved.
> > And it would be damn hard achieving that if there are too many gates
> > to cross.
>
> What has been discussed that results in an increased number of, or
> complexity of, gates for non-committers?
Er, well, the whole idea that being a committer is not enough, and
that getting code in requires explicit code review and a vote from
peers (not to mention the idea of having people whose +1 is more
important than other's - the "gatekeepers" you've been mentioning)...
all that speaks of barriers to me. Am I the only one?
> > For one, I see the notion of "supercommitter" (or gatekeeper, in Bob
> > words) as extremely harmful. In ASF-land there is no such thing (and
> > this is a problem in itself).
> (I don't understand the second parenthetical; it parses like a contradiction.)
What I meant is:
1. I consider having different kinds of committers dangerous in itself;
2. Apache has a somewhat strong definition of roles. Once you're a
committer (well, actually a PMC member), your vote counts as anyone
else's. Even the PMC chair has one vote which is equal to any other.
While there is some wiggle room, I'm pretty much positive that a
policy considering votes for some PMC members as more important than
others will clash with ASF procedures.
> ASF already has something stricter than gatekeeper: committers are
> committers only for a specific codebase, not all of ASF-land.
Yes, and that's pretty much the only line in the sand. Once you're a
committer, you're granted access to a specific codebase, and all of
it.
> To cite from
> http://apache.org/foundation/glossary.html#Codebase
> "Some projects involve only a single codebase, while others have several."
> My notion of gatekeeper is akin to dividing up the River project into
> multiple codebases with independent committers, but less rigid than that,
> as it only imposes a quorum on reviewers.
>
> (No doubt someone will tell me that this part of the ASF web site
> also does not reflect reality. ;-) )
Heh, specs are buggy as everything else. :) Anyway, this is feasible
but requires an explicit split, something I wouldn't say we're quite
ready for. And, again, it might be detrimental in terms of drawing
community boundaries.
> > And this is why I
> > see a lot of slippery slopes in introducing control-based processes
> > that don't take reciprocal trust into account.
>
> Committer privilege being only for a specific ASF project/codebase,
> rather than all of ASF-land, does take reciprocal trust into account?
It does indeed, that's the very notion of trust: if you're getting
commit access, this is because you're deemed to be *both* technically
savvy and socially capable of interacting with a community and
understanding where you should be committing code and where you'd be
better ask for peer review in advance. If you take the social bit out
of the equation, clearly you need demarcation lines between spaces
you're allowed to mess with. But doing so also impairs the whole trust
notion.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Gianugo Rabellino wrote:
> I still contend that the
> main objective of this timeframe should be getting others involved.
> And it would be damn hard achieving that if there are too many gates
> to cross.
What has been discussed that results in an increased number of, or
complexity of, gates for non-committers?
> For one, I see the notion of "supercommitter" (or gatekeeper, in Bob
> words) as extremely harmful. In ASF-land there is no such thing (and
> this is a problem in itself).
(I don't understand the second parenthetical; it parses like a contradiction.)
ASF already has something stricter than gatekeeper: committers are
committers only for a specific codebase, not all of ASF-land.
To cite from
http://apache.org/foundation/glossary.html#Codebase
"Some projects involve only a single codebase, while others have several."
My notion of gatekeeper is akin to dividing up the River project into
multiple codebases with independent committers, but less rigid than that,
as it only imposes a quorum on reviewers.
(No doubt someone will tell me that this part of the ASF web site
also does not reflect reality. ;-) )
> And this is why I
> see a lot of slippery slopes in introducing control-based processes
> that don't take reciprocal trust into account.
Committer privilege being only for a specific ASF project/codebase,
rather than all of ASF-land, does take reciprocal trust into account?
- Bob
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/29/07, Bob Scheifler <Bo...@sun.com> wrote:
> I dislike code review deadlines; code isn't correct just because a deadline
> passes. I also don't ever expect committers to be expert in the entire
> codebase, so I'm wary of accepting +1's from only those who don't really
> understand the code being changed. So for implementation changes I'm tempted
> towards having a set of gatekeepers for each component (achieved by merit),
> and review must have a +1 from a gatekeeper, and no vetoes within
> max(N days, vote by gatekeeper).
I think this email, other than convincing me even more that RTC is bad
in general and wrong in this context, is a clear sign that we need to
step back a minute and try to understand what we are really after.
First of all, what are we trying to achieve? What is our top priority?
As an ASF incubating project, the ultimate goal should be proving how
River is sustainable from a community perspective, much rather than
demonstrating technical excellence. While I can understand that River
is currently used in production in a number of places, with lots of
users relying on its quality and robustness, I still contend that the
main objective of this timeframe should be getting others involved.
And it would be damn hard achieving that if there are too many gates
to cross. If the codebase is too complex, the solution isn't raising
artificial barriers to avoid others from making silly mistakes. The
solution making it easier to grasp and provide a good community
framework that clearly outlines roles and responsibilities *while*
promoting participation.
For one, I see the notion of "supercommitter" (or gatekeeper, in Bob
words) as extremely harmful. In ASF-land there is no such thing (and
this is a problem in itself). We do have people responsiblle for parts
of the code, but this is usually governed by trust and common sense:
people won't commit crap to the repo just because they can, they will
resort to whomever knows best. I am, formally, a River committer, yet
I'm (very!) far from changing a single line of code. Heck, I did check
out the repo just to make sure that there were no obvious legal
issues. And I'm not going to vote on technical issues, no matter what:
all you will be seeing from me are abstains or, at most, +-0s. I know
where I stand, I know what my role is, I know if and when I can talk
about the codebase (never, for the time being) or vote about
legal/community issues (always).
Side note: I grew up as a commiter in Cocoon-land which, as some of
you may know, is a highly complex beast, very modular and with a lot
of different technologies involved. When I was an active developer, I
was following a few modules, where I felt confident and knowledgeable
enough to directly commit code. Of course from time to time I had to
chime in someone else's realm, where I possibly knew the big picture
but I was definitely a complete ignorant about the actual
implementation and potential impact of my changes. In such cases, I
resorted to posting to the mailing list, possibly with a
proposal/diff, and wait for a green light from the "gatekeeper", that
is someone I knew was knowledgeable enough. Think of it as an
informal, community-oriented, RTC in a CTR environment. And believe
me, it just works: when meritocracy is at work, committers aren't just
people with technical skills, they know how to work within a
community.
I think River needs to recreate such an environment. And this is why I
see a lot of slippery slopes in introducing control-based processes
that don't take reciprocal trust into account. This is not to say that
RTC is bad in itself: it might work as an excellent tool to ensure
control where control is key (stuff like backports, security issues,
et al), just make sure it's there for the correct reasons.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I'm inclined to a Review-Then-Commit policy although a 3 days period
> before being able to check-in feels like a very long time in some cases,
> although completely understandable from the perspective to give people
> time to look into it. Another risk is that 'commit starvation' occurs
> when there are no 3 committers finding the time to look into it and as a
> result there won't be any 3 +1's required to be allowed to check-in the
> code.
I'm no doubt being socially incorrect, but...
I dislike code review deadlines; code isn't correct just because a deadline
passes. I also don't ever expect committers to be expert in the entire
codebase, so I'm wary of accepting +1's from only those who don't really
understand the code being changed. So for implementation changes I'm tempted
towards having a set of gatekeepers for each component (achieved by merit),
and review must have a +1 from a gatekeeper, and no vetoes within
max(N days, vote by gatekeeper).
- Bob
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Jukka Zitting wrote:
> Hi,
>
> On 8/29/07, Mark Brouwer <ma...@cheiron.org> wrote:
>> I'm inclined to a Review-Then-Commit policy although a 3 days period
>> before being able to check-in feels like a very long time in some cases,
>> although completely understandable from the perspective to give people
>> time to look into it.
>
> A good balance would be to allow a commit to take place as soon as the
> 3 +1 votes (and no vetoes) are cast, as it's always possible to revert
> a change if someone later wants to veto it.
I like that.
>> Another risk is that 'commit starvation' occurs when there are no 3
>> committers finding the time to look into it and as a result there won't
>> be any 3 +1's required to be allowed to check-in the code.
>
> A lazy consensus rule could be used to pass "under-reviewed" changes
> after some number of days.
I like that too, any suggestion what the right number of days would be
in such a case?
With Jukka's suggestions I think we can have a proper review policy in
place that is swift in case 3 or more pair of eyes like the commit and
prevents from a commit stalling when there are no people to do the
review or want to 'veto' indirectly by expressing no opinion.
--
Mark
Re: development process
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/29/07, Mark Brouwer <ma...@cheiron.org> wrote:
> I'm inclined to a Review-Then-Commit policy although a 3 days period
> before being able to check-in feels like a very long time in some cases,
> although completely understandable from the perspective to give people
> time to look into it.
A good balance would be to allow a commit to take place as soon as the
3 +1 votes (and no vetoes) are cast, as it's always possible to revert
a change if someone later wants to veto it.
> Another risk is that 'commit starvation' occurs when there are no 3
> committers finding the time to look into it and as a result there won't
> be any 3 +1's required to be allowed to check-in the code.
A lazy consensus rule could be used to pass "under-reviewed" changes
after some number of days.
BR,
Jukka Zitting
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> (Note: we made good progress on the first question... but
> just leaving room for anyone else to add in before I summarized).
> Meanwhile... on to the next)
>
> As we continue discussing the "AR1" release questions/tasks...
> here's the next:
>
>> * What kind of development process do we need? JIRA issues for
>> all changes? code reviews?
I would say JIRA issues for all changes, except for the really trivial
stuff (like fixing a typo while working on another issue, but I believe
people are smart enough to get a feeling what belongs in JIRA).
> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything). We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable. I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.
Code review is indeed immensely valuable and rather essential especially
for those things that are extremely hard to test properly, such as
concurrency related code or for which it is extremely hard to get the
right conditions into place and I think that a lot of the current
codebase falls into this category.
As all code changes are subject to voting and require 3 +1 votes and no
veto I expect people to give their vote only when they looked into it
sufficiently to backup their opinion.
So if we decide to have a Review-Then-Commit policy
(http://apache.org/foundation/glossary.html#ReviewThenCommit) I think
code review is in place by default, if we decide to go for
Commit-Then-Review
(http://apache.org/foundation/glossary.html#CommitThenReview) and you
want to be assured that all code finally checked in is reviewed by
somebody else we need to come up with a procedure that takes care of that.
I'm inclined to a Review-Then-Commit policy although a 3 days period
before being able to check-in feels like a very long time in some cases,
although completely understandable from the perspective to give people
time to look into it. Another risk is that 'commit starvation' occurs
when there are no 3 committers finding the time to look into it and as a
result there won't be any 3 +1's required to be allowed to check-in the
code.
Maybe there are cases and/or parts of the codebase where
Commit-Then-Review is more appropriate (website updates e.g.) and I have
no problem with applying them both.
--
Mark
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
On Aug 28, 2007, at 9:16 PM, Jim Hurley wrote:
> Jukka, Phil, Gianugo -- Any guidance from the mentors on this?
Not a mentor but hope this is useful...
>
> Do other Apache projects typically:
> - require code reviews (prior to integration)?
Depends. Projects have either RTC (review then commit) or CTR (commit
then review) depending on how the community wants to organize itself.
There's no guidance. For RTC the patch is typically attached to a JIRA.
> - require tests (prior to integration)?
Typically yes. Many projects have an official (checked in) test suite
that must pass before checking anything in. Many projects also have
private test suites (various reasons, including complex setups or
proprietary test harnesses) that are run either before (if the
committer has access) or after a checkin. And it's always a good idea
to have a test case as part of a bug fix that fails without the fix
and succeeds with it, checked in as part of the fix.
> - use JIRA for all changes (so they can be tracked),
> or only for 'substantive' ones?
None of the projects I am familiar with require a JIRA for typos,
javadoc, "obvious" bug fixes (e.g. FindBugs reports), etc. Most
projects expect a JIRA for substantial changes, not just bug fixes.
>
> It seems like that background might be helpful to making
> a decision here.
Other things that I'm familiar with include a recommendation (not a
requirement) for a peer code review for all substantial checkins.
Craig
>
> thanks -Jim
>
>
> On Aug 28, 2007, at 1:10 AM, Jim Hurley wrote:
> :
>>> * What kind of development process do we need? JIRA issues for
>>> all changes? code reviews?
>>
>> There's also a testing issue here (for example, do you need to
>> supply tests? if so, which framework or just unit tests). This
>> is somewhat tied into:
>>> * What kind of testing do we need?
>>
>> It would probably be easier to tackle these (dev process and
>> testing process) separately.... but if they spill into one another,
>> than so be it.
>>
>> So, regarding development process -- what do you think?
>> In looking around, I didn't see a norm for things (for example,
>> not sure if projects use JIRA for everything). We've used code
>> reviews inside our group at Sun for the starter kit, and it's proved
>> immensely valuable. I'd vote to continue it - both as a quality
>> measure as well as a way to get more people involved and
>> knowledgeable about the different pieces of code.
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi Nigel,
Nigel Daley wrote:
> What a verbose community we have when it comes to process :-) Here are
> my votes, without explanation, for the core river code (what's in
> subversion now).
>
>
> +1 for RTC manifested as a "+1 code review" comment on the Jira issue
I'm not totally clear on what you mean here (process wise that is),
could you elaborate?
--
Mark
Re: development process
Posted by Nigel Daley <nd...@mac.com>.
What a verbose community we have when it comes to process :-) Here
are my votes, without explanation, for the core river code (what's in
subversion now).
+1 for RTC manifested as a "+1 code review" comment on the Jira issue
+1 for every commit coming from a patch attached to a Jira issue
-1 for every patch needing a vote (but a committer is free to
explicitly call for a vote if the discussion on the issue appears
controversial without conclusion)
-1 for gatekeepers of subcomponents (but committers are urged to only
commit in areas where they understand the codebase)
+1 for starting with a simple process and revisiting when necessary
Re: development process
Posted by Phil Steitz <ph...@gmail.com>.
On 8/29/07, Bob Scheifler <Bo...@sun.com> wrote:
> Craig L Russell wrote:
> > I don't know of a project (here or elsewhere) that votes on code
> > changes.
>
> Then why is it #1 on http://apache.org/foundation/voting.html?
>
What is being called out here is the distinguishing characteristic of
decisions regarding code modifications (either individual commits,
branch merges or modification plans). These are subject to *veto* -
i.e., a single -1 is enough for a negative outcome. We rarely
formally VOTE on code-related issues though, preferring to reach
consensus via discussion. Lazy consensus does fail now and then,
though - i.e., -1's on commits do occur and in this case the committer
is expected to reverse the commit.
Phil
> - Bob
>
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
FYI...
Thanks to this question, I've asked around and it looks like very few
projects use the RTC model, and those projects use CTR for the trunk
and RTC for backports where stability is paramount.
Having RTC for some portions of a project where it's important, and
CTR for other parts is a rational policy. Especially since RTC by the
formal definition requires a +3 vote for all code changes, which is a
pretty significant hurdle.
How does this affect this discussion?
1. RTC and CTR can coexist in the same project for different parts.
Examples were contained in Gianugo's message yesterday: strong RTC
(that is review + vote) required for specific subsets such as:
- API changes
- backward-incompatible user-visible changes
- backports to release branches
- security fixes
2. CTR can be modified to include a requirement for at least one
review for significant changes.
3. Apache communities generally leave it up to the committers'
discretion whether a change is significant enough to warrant review.
Craig
On Aug 29, 2007, at 7:55 AM, Craig L Russell wrote:
> Hi Bob,
>
> On Aug 29, 2007, at 7:25 AM, Bob Scheifler wrote:
>
>> Craig L Russell wrote:
>>> I don't know of a project (here or elsewhere) that votes on code
>>> changes.
>>
>> Then why is it #1 on http://apache.org/foundation/voting.html?
>
> I believe that this page doesn't reflect current practice for most
> projects. I'll ask around and get a better answer.
>
> Thanks for following up.
>
> Craig
>>
>> - Bob
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Bob,
On Aug 29, 2007, at 7:25 AM, Bob Scheifler wrote:
> Craig L Russell wrote:
>> I don't know of a project (here or elsewhere) that votes on code
>> changes.
>
> Then why is it #1 on http://apache.org/foundation/voting.html?
I believe that this page doesn't reflect current practice for most
projects. I'll ask around and get a better answer.
Thanks for following up.
Craig
>
> - Bob
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Craig L Russell wrote:
> I don't know of a project (here or elsewhere) that votes on code
> changes.
Then why is it #1 on http://apache.org/foundation/voting.html?
- Bob
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
I'd like to second what Gianugo says here. I'll paraphrase a bit.
I don't know of a project (here or elsewhere) that votes on code
changes. [The incubator vote to accept blocks of code doesn't apply
once committers start working on the code base in the svn repo.] Even
when the RTC policy is used, it generally means the code change is
attached as a patch to a JIRA and others are encouraged to review and
comment. There can be iteration on the JIRA and after some grace
period with no additional comments, the developer commits the code.
The project can choose to require that major changes actually have a
JIRA comment before commit just to be sure that someone has reviewed
it. But simply posting the patch in a JIRA could be considered
sufficient. And having more than one review might be considered
overkill.
Most projects have some documented "best practice" for the patches
that are attached to JIRA. For example, the policy might be to go to
the svn trunk and do svn diff >RIVER-325.patch so that whoever wants
to review the patch then does cd trunk; patch -p0 <RIVER-325.patch on
the downloaded patch file. But even if submitted patches (e.g. by a
community developer) don't follow the policy, they can still be
reviewed.
As Gianugo points out, there's no lasting harm from committing a
patch that breaks something. (Even breaking the build isn't
considered a hanging offense here). The patch can be rolled back in
its entirety or a fix can be applied to the patch (the fix commit can
reference the same issue so that JIRA tracks both commits as part of
the issue, e.g. commit -m "RIVER-325 Fixed missed listener event in
original patch").
A final comment on the review itself. Apache communities are
typically geographically diverse, so in general it's impractical to
conduct face-to-face (f2f) code reviews. It will be good to think in
terms of a 24 hour time zone as you plan how to implement the review
policy.
Craig
On Aug 29, 2007, at 12:18 AM, Gianugo Rabellino wrote:
> On 8/29/07, Jim Hurley <Ji...@sun.com> wrote:
>> Jukka, Phil, Gianugo -- Any guidance from the mentors on this?
>>
>> Do other Apache projects typically:
>> - require code reviews (prior to integration)?
>> - require tests (prior to integration)?
>> - use JIRA for all changes (so they can be tracked),
>> or only for 'substantive' ones?
>
> As others have mentioned, both RTC and CTR are used within Apache. I'd
> venture to say that the latter is much more popular, though.
>
> Personally, I'm not a RTC fan. I consider that somewhat harmful from a
> community perspective, considering that:
>
> - the Apache meritocratic process means that committers have earnt
> trust from their peers
> - we have a number of tools (commit emails, CI, automated tests) to
> warn us about potential mishaps
> - Rolling changes back in SVN is easy enough
>
> RTC to me looks like an artificial burden: if you have a good
> community willing to perform code reviews, then you won't need patches
> attached to Jira. People will read the commit logs and run diffs
> themselves. Not to mention that a good committer should always know
> when it's better to talk about a potentially dangerous patch on the
> list before even trying to write it down.
>
> A bad community, OTOH, won't make any use of Jira-based RTC, which
> will effectively just means having to wait before code gets into the
> codebase, as people won't review patches anyways. If you add to this
> the additional burden for every committer of downloading and applying
> the patch manually to see if everything works as advertised, then
> revert the patch since it's the original author the one supposed to
> update the tree, you end up with something that just gets in the way.
>
> Bottom line: I think CTR + a good use of common sense is more than
> enough. But then again, this is only me and RTC is kosher as well. If
> you're used to it, I see no reason to change that immediately.
>
>
> --
> Gianugo Rabellino
> Sourcesense, making sense of Open Source: http://www.sourcesense.com
> Orixo, the XML business alliance: http://www.orixo.com
> (blogging at http://www.rabellino.it/blog/)
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I realize code-reviewing from patches alone is hard, and applying diffs
> you obtain from JIRA yourself for reviewing purposes is far from ideal.
Could webrevs be published on the ASF site?
- Bob
Re: development process
Posted by Thomas Vinod Johnson <Th...@Sun.COM>.
Mark Brouwer wrote:
> Gianugo Rabellino wrote:
>
>> Bottom line: I think CTR + a good use of common sense is more than
>> enough. But then again, this is only me and RTC is kosher as well. If
>> you're used to it, I see no reason to change that immediately.
>
> Hi Gianugo,
>
> I see your points and as any process could work depending on the type of
> people and their willingness to make it work, I believe there are 2
> issues not yet mentioned related to the River codebase that make RTC
> IMHO the best choice for the moment.
>
Given the definitions of RTC and CTR (is useful in rapid-prototyping
environments) in the glossary, I concur that RTC is a better candidate
for the existing codebase. Moreover, I think starting off with a more
familiar process helps to ease the transition.
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
Mark,
I understand your position: I'm adding this mostly as FFT:
On 8/29/07, Mark Brouwer <ma...@cheiron.org> wrote:
> I believe most parts of the Jini codebase represent extremely
> sophisticated/complex code designed with security in mind for each and
> every aspect as well as taking high levels of concurrency into account.
> Testing for this in a proper and cost efficient way is an art I'm still
> trying to master, I feel it is good to have a more rigid way of people
> looking into these aspects through code review [1].
Honestly, I don't really see how CTR is going to help here. RTC isn't
about lack of code review, it's quite the opposite actually: you still
get notifications and ou can discuss changes and maybe revert/change
the commit. In this case actually CTR can be a great way to foster
discussion.
> Another one is that almost all committers are Sun based and we have only
> a few external ones and likely most committers only have their expertise
> in certain areas. I can imagine that it will be easier for Sun
> committers to 'nitpick' on proposed changes to the codebase instead of
> voting down a commit each time. I haven't work as their shrink ;-) so I
> can't tell whether they like the latter option more, but I can image
> that RTC will lower the barrier to comment on proposed changes and I
> suspect it will be quite a long way before we have a diverse group of
> committers that 'trust' each other enough to have CTR in place.
Well, here I'm definitely seeing a problem. What I'm reading is that
there are committers as in people with SVN write access who are no
"committers" the way Apache intends them to be, as fully trusted
members of the community who have a sound grasp of the technical side
and, most importantly, know if and when to commit straight away or ask
the community beforehand. If this is the case, then we have a
different and major issue to tackle.
> Therefore I feel it is important to start with the customs that resulted
> in the excellent code quality we have right now, if it doesn't work we
> should change.
This is a valid point: if you're used to this process, then just go
for it. Do keep in mind, however, that there is always a trade-off
between excellent *code* quality and excellent *community* quality. It
has been said a number of times already how bad code creates great
communities while excellent code rarely has a great community behind
it. We don't need to go the the extreme here, but just know that the
ASF values communities much more than code.
> I realize code-reviewing from patches alone is hard, and applying diffs
> you obtain from JIRA yourself for reviewing purposes is far from ideal.
> SVN is not the ideal tool to support this model, but it is also possible
> people expose their workspace through Mercurial e.g.
> (http://www.selenic.com/mercurial/wiki/) so people can pull in changes
> or sync to other people their workspaces.
Yes, that's possible. However, know that there might be some legal
issues with hosting ASF code on external repositories. Probably this
is not the case, yet it's something to consider.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Gianugo Rabellino wrote:
> Bottom line: I think CTR + a good use of common sense is more than
> enough. But then again, this is only me and RTC is kosher as well. If
> you're used to it, I see no reason to change that immediately.
Hi Gianugo,
I see your points and as any process could work depending on the type of
people and their willingness to make it work, I believe there are 2
issues not yet mentioned related to the River codebase that make RTC
IMHO the best choice for the moment.
I believe most parts of the Jini codebase represent extremely
sophisticated/complex code designed with security in mind for each and
every aspect as well as taking high levels of concurrency into account.
Testing for this in a proper and cost efficient way is an art I'm still
trying to master, I feel it is good to have a more rigid way of people
looking into these aspects through code review [1].
Another one is that almost all committers are Sun based and we have only
a few external ones and likely most committers only have their expertise
in certain areas. I can imagine that it will be easier for Sun
committers to 'nitpick' on proposed changes to the codebase instead of
voting down a commit each time. I haven't work as their shrink ;-) so I
can't tell whether they like the latter option more, but I can image
that RTC will lower the barrier to comment on proposed changes and I
suspect it will be quite a long way before we have a diverse group of
committers that 'trust' each other enough to have CTR in place.
Therefore I feel it is important to start with the customs that resulted
in the excellent code quality we have right now, if it doesn't work we
should change.
I realize code-reviewing from patches alone is hard, and applying diffs
you obtain from JIRA yourself for reviewing purposes is far from ideal.
SVN is not the ideal tool to support this model, but it is also possible
people expose their workspace through Mercurial e.g.
(http://www.selenic.com/mercurial/wiki/) so people can pull in changes
or sync to other people their workspaces.
Ok, enough of my opinion ...
[1] I like to emphasize that I don't see it as a replacement for
testing, more to complement tests, especially for those cases one (or at
least I) can't test (in isolation).
--
Mark
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/30/07, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On 8/29/07, Gianugo Rabellino <gi...@apache.org> wrote:
> > Bottom line: I think CTR + a good use of common sense is more than
> > enough.
>
> +1
>
> There's another angle on the CTR/RTC issue as well. Especially with a
> complex codebase there is a danger that people will just "do their
> thing" and keep committing stuff without communicating with the rest
> of the team/community on what's going on. Even though RTC does raise
> the commit barrier, it also forces people to communicate what they are
> doing.
True, but I think that the word "forces" captures why this is about
treating symptoms rather than causes. If people don't communicate,
this is a community issue that needs to be resolved within the
community (by nudging, educating and - as a radical last resort - move
to RTC for a short period of time while considering whether it
wouldn't be better to just get rid of the guy). RTC might just sweep
the problem under the rug, and make it actually worse.
> With that in mind I'd suggest using at least a relaxed version of RTC
> where Jira issues are raised for all non-trivial changes and a patch
> or at least a written outline of the proposed solution is posted
> before making the change based on lazy consensus. This is actually
> what many (most?) Apache projects do in practice even if following the
> CTR policy.
Well said. My ideal workflow would be something like:
a) generally speaking, a free-for-all CTR with common sense, which
means everyone should feel comfortable in prodding the list for peer
review before committing
b) strong RTC (that is review + vote) required for specific subsets such as:
- API changes
- backward-incompatible user-visible changes
- backports to release branches
- security fixes
c) RTC actually means:
1. a proposal to the dev list
2. patch in Jira
3. (alternatively) vote (if (b) applies) or lazy consensus
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/29/07, Gianugo Rabellino <gi...@apache.org> wrote:
> Bottom line: I think CTR + a good use of common sense is more than
> enough.
+1
There's another angle on the CTR/RTC issue as well. Especially with a
complex codebase there is a danger that people will just "do their
thing" and keep committing stuff without communicating with the rest
of the team/community on what's going on. Even though RTC does raise
the commit barrier, it also forces people to communicate what they are
doing.
With that in mind I'd suggest using at least a relaxed version of RTC
where Jira issues are raised for all non-trivial changes and a patch
or at least a written outline of the proposed solution is posted
before making the change based on lazy consensus. This is actually
what many (most?) Apache projects do in practice even if following the
CTR policy.
We could also start with a formal RTC policy, and relax it later as or
if people feel comfortable doing that.
BR,
Jukka Zitting
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/29/07, Jim Hurley <Ji...@sun.com> wrote:
> Jukka, Phil, Gianugo -- Any guidance from the mentors on this?
>
> Do other Apache projects typically:
> - require code reviews (prior to integration)?
> - require tests (prior to integration)?
> - use JIRA for all changes (so they can be tracked),
> or only for 'substantive' ones?
As others have mentioned, both RTC and CTR are used within Apache. I'd
venture to say that the latter is much more popular, though.
Personally, I'm not a RTC fan. I consider that somewhat harmful from a
community perspective, considering that:
- the Apache meritocratic process means that committers have earnt
trust from their peers
- we have a number of tools (commit emails, CI, automated tests) to
warn us about potential mishaps
- Rolling changes back in SVN is easy enough
RTC to me looks like an artificial burden: if you have a good
community willing to perform code reviews, then you won't need patches
attached to Jira. People will read the commit logs and run diffs
themselves. Not to mention that a good committer should always know
when it's better to talk about a potentially dangerous patch on the
list before even trying to write it down.
A bad community, OTOH, won't make any use of Jira-based RTC, which
will effectively just means having to wait before code gets into the
codebase, as people won't review patches anyways. If you add to this
the additional burden for every committer of downloading and applying
the patch manually to see if everything works as advertised, then
revert the patch since it's the original author the one supposed to
update the tree, you end up with something that just gets in the way.
Bottom line: I think CTR + a good use of common sense is more than
enough. But then again, this is only me and RTC is kosher as well. If
you're used to it, I see no reason to change that immediately.
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 8/29/07, Jim Hurley <Ji...@sun.com> wrote:
> Do other Apache projects typically:
> - require code reviews (prior to integration)?
> - require tests (prior to integration)?
> - use JIRA for all changes (so they can be tracked),
> or only for 'substantive' ones?
>
> It seems like that background might be helpful to making
> a decision here.
It's typically up to each project to come up with the development
practices that work best for them, and there are even projects that
have different practices for different parts of their codebase (e.g.
RTC for a stable core and CTR for experimental modules). As you
noticed, there's no normative "Apache Development Process".
If you've already used to doing code reviews, then it might make sense
to start with the review-then-commit policy (RTC, see [1]) and perhaps
relax that later. A typical workflow is that a patch is first attached
to the respective JIRA issue and applied once (lazy) consensus is
reached.
[1] http://www.apache.org/foundation/glossary.html#ReviewThenCommit
BR,
Jukka Zitting
Re: development process
Posted by Jim Hurley <Ji...@Sun.COM>.
Jukka, Phil, Gianugo -- Any guidance from the mentors on this?
Do other Apache projects typically:
- require code reviews (prior to integration)?
- require tests (prior to integration)?
- use JIRA for all changes (so they can be tracked),
or only for 'substantive' ones?
It seems like that background might be helpful to making
a decision here.
thanks -Jim
On Aug 28, 2007, at 1:10 AM, Jim Hurley wrote:
:
>> * What kind of development process do we need? JIRA issues for
>> all changes? code reviews?
>
> There's also a testing issue here (for example, do you need to
> supply tests? if so, which framework or just unit tests). This
> is somewhat tied into:
>> * What kind of testing do we need?
>
> It would probably be easier to tackle these (dev process and
> testing process) separately.... but if they spill into one another,
> than so be it.
>
> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything). We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable. I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.
Re: development process
Posted by Jools <jo...@gmail.com>.
Ciao Gianugo,
On 8/31/07, Gianugo Rabellino <gi...@apache.org> wrote:
>
> Hello Jools,
>
> On 8/31/07, Jools <jo...@gmail.com> wrote:
>
> > > * What kind of development process do we need? JIRA issues for
> > > > all changes? code reviews?
> >
> > IMHO I would prefer that JIRA be used for all code changes. It gives us
> > visibility of what is happening, and can be used as the index for a
> change
> > log which should be produced for every release.
>
> Beware, however, of mailing list and Jira getting out of sync, with
> discussions moving to the issue tracker (bad!) and progress being
> tracked on the mailing list (bad, again). This is something that is
> bound to happen if there are information duplicates.
We are notified on the list when a new JIRA issue is created here on the
list.
If I feel that this bug effects me in some way, I will make the effort to
communicate these feelings via the comments facility in JIRA.
That way, anybody who might come cold to the bug or issue will get the
complete context of the issue, and not have to go searching through the
mailing archives( a Good Thing TM )
If we all make an effort to be consistent, then I'm sure that duplicates
will be minimized. (another Good Thing TM )
> Also, it might be that a developer in his own time developers a patch
> which
> > is then submitted to the committers in private which would mean that the
> > community would not have any visibility of the change in code.
>
> Ouch. Why on earth should that happen? If there is something that ASF
> is opposing, that's development and discussions happening outside the
> mailing list and the community oversight. So much that, to some
> extents, F2F events are somewhat discouraged and definitely regulated
> in order to make sure that the discussion outcome gets to the mailing
> list.
I think we've already covered this, regarding security issues.
> If I was to offer my advice, I'd say keep the committer pool fairly small
> > and allow submissions in the form of a patch.
>
> Note that this is, again, somewhat against the established practice of
> most (not any, httpd being a notable and important exception) ASF
> projects, where the committer bar is kept intentionally low as a
> community building methodology.
I can see where you are coming from, however I don't feel that lowering the
bar to being a comitter would be a (good thing TM).
I would consider myself pretty well versed in the jini source code, and I
would not feel demeaned being asked to produce bug report/patch/unit test
which would then be open to scrutiny and which may or may not be accepted in
the form I submitted it.
In fact that knowledge would make me happier to suggest using river to my
management.
--Jools
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
Hello Jools,
On 8/31/07, Jools <jo...@gmail.com> wrote:
> > * What kind of development process do we need? JIRA issues for
> > > all changes? code reviews?
>
> IMHO I would prefer that JIRA be used for all code changes. It gives us
> visibility of what is happening, and can be used as the index for a change
> log which should be produced for every release.
Beware, however, of mailing list and Jira getting out of sync, with
discussions moving to the issue tracker (bad!) and progress being
tracked on the mailing list (bad, again). This is something that is
bound to happen if there are information duplicates.
> Also, it might be that a developer in his own time developers a patch which
> is then submitted to the committers in private which would mean that the
> community would not have any visibility of the change in code.
Ouch. Why on earth should that happen? If there is something that ASF
is opposing, that's development and discussions happening outside the
mailing list and the community oversight. So much that, to some
extents, F2F events are somewhat discouraged and definitely regulated
in order to make sure that the discussion outcome gets to the mailing
list.
> If I was to offer my advice, I'd say keep the committer pool fairly small
> and allow submissions in the form of a patch.
Note that this is, again, somewhat against the established practice of
most (not any, httpd being a notable and important exception) ASF
projects, where the committer bar is kept intentionally low as a
community building methodology.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Jools,
Just one comment...
On Aug 31, 2007, at 8:13 AM, Jools wrote:
> My personal preference would be as follows;
>
> 1) Issue gets raised on mailing list.
> 2) If the issue is genuine, then raise a JIRA id for it.
> 3) Add yourself as interested in the id, and you will be notified of
> changes.
With the JIRA installation for RIVER, every change made to any JIRA
will be sent to the river-dev alias. You don't need to be interested.
Being a river dev is enough.
The only thing about this is that the email message contains only the
issue description and the latest comment. So to see the entire thread
you need to click on the link in the message that takes you to the
JIRA issue itself (which you cannot do if you're reading email offline).
Craig
> 4) If you feel the need to comment, it will be recorded in the
> right place,
> once. No need for any copying.
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Gianugo Rabellino <gi...@apache.org>.
On 8/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
> What is the opinion on dealing with security issues?
Usually, security issues are initially discussed in the private PMC
list. Note, however, that the PMC still represents the community, and
whatever technical discussion should move to the public dev list as
soon as the privacy issues are sorted out.
Ciao,
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
Re: development process
Posted by Jools <jo...@gmail.com>.
On 8/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
>
> Jools wrote:
>
> > If a security issues was found in river, I'd prefer that it be discussed
> > with a little privacy until the nature of the issue was fully
> understood,
> > and the possible issues which users of river may be exposed to should
> they
> > fail to patch their systems.
> >
> > All issues will ultimately become visible via JIRA, and should anybody
> > involved in the project wish to make a constructive comment, I would
> suggest
> > that be the place to do it.
>
> Good point, AFAIK there has is no special field yet to mark an issue as
> a security issue in which case only committers can see it and its
> details. This is possible in JIRA to achieve as I've done the same thing
> for Cheiron.
>
> What is the opinion on dealing with security issues? My personal opinion
> would be the include a special "Security Level" field that has 2
> options: "None" and "Security risk" or to have the problem mailed to one
> of the committers who can take care of entering it in JIRA. We can use
> the private PMC list for discussing the matter.
I'd prefer it discussed on the private PMC list, transfered to JIRA using
the above mentioned security notation.
Once the issues has been resolved and a fix specified, then it should be
come public.
I'm sure this will be a 'once in a blue moon' type thing, but it's better to
be ahead of the curve :-)
> My personal preference would be as follows;
> >
> > 1) Issue gets raised on mailing list.
> > 2) If the issue is genuine, then raise a JIRA id for it.
> > 3) Add yourself as interested in the id, and you will be notified of
> > changes.
> > 4) If you feel the need to comment, it will be recorded in the right
> place,
> > once. No need for any copying.
>
> Ok, I was thinking earlier on you were refering to remarks related to
> the actual code reviewing.
I would expect all comments, be they review or otherwise to be added to the
JIRA report.
--Jools
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Jools wrote:
> If a security issues was found in river, I'd prefer that it be discussed
> with a little privacy until the nature of the issue was fully understood,
> and the possible issues which users of river may be exposed to should they
> fail to patch their systems.
>
> All issues will ultimately become visible via JIRA, and should anybody
> involved in the project wish to make a constructive comment, I would suggest
> that be the place to do it.
Good point, AFAIK there has is no special field yet to mark an issue as
a security issue in which case only committers can see it and its
details. This is possible in JIRA to achieve as I've done the same thing
for Cheiron.
What is the opinion on dealing with security issues? My personal opinion
would be the include a special "Security Level" field that has 2
options: "None" and "Security risk" or to have the problem mailed to one
of the committers who can take care of entering it in JIRA. We can use
the private PMC list for discussing the matter.
> My personal preference would be as follows;
>
> 1) Issue gets raised on mailing list.
> 2) If the issue is genuine, then raise a JIRA id for it.
> 3) Add yourself as interested in the id, and you will be notified of
> changes.
> 4) If you feel the need to comment, it will be recorded in the right place,
> once. No need for any copying.
Ok, I was thinking earlier on you were refering to remarks related to
the actual code reviewing.
>> Committer applies patch to the code base after reviews are complete.
>>> Hope it helps.....
>> Any feelings with regard to code modifications of committers themselves,
>> i.e. RTC versus CTR. Does it make any difference in your willingness to
>> participate and becoming a committer.
>
>
> I know which I prefer, but I'm agnostic to the process. I will still
> continue to help and support where and when I can.
I was going to ask "which is" but that would only be for my own
curiosity given your later statement, so I'll refrain :-)
--
Mark
Re: development process
Posted by Jools <jo...@gmail.com>.
On 8/31/07, Mark Brouwer <ma...@cheiron.org> wrote:
>
> Thanks for chipping in Jools,
>
> Jools wrote:
> > Sorry for any duplication in existing in other responses, not really had
> > time to read the whole thread.
> >
> >
> >> * What kind of development process do we need? JIRA issues for
> >>> all changes? code reviews?
> >
> >
> > IMHO I would prefer that JIRA be used for all code changes. It gives us
> > visibility of what is happening, and can be used as the index for a
> change
> > log which should be produced for every release.
>
> Agreed.
>
> > Also, it might be that a developer in his own time developers a patch
> which
> > is then submitted to the committers in private which would mean that the
> > community would not have any visibility of the change in code.
>
> I'm not sure whether I like the idea that patches are reviewed and
> discussed in private (in the general case). I can imagine that some form
> of criticism is better served by going private, but in most cases I like
> the transparency when there is e.g. disagreement about some code
> modifications.
If a security issues was found in river, I'd prefer that it be discussed
with a little privacy until the nature of the issue was fully understood,
and the possible issues which users of river may be exposed to should they
fail to patch their systems.
All issues will ultimately become visible via JIRA, and should anybody
involved in the project wish to make a constructive comment, I would suggest
that be the place to do it.
> Code reviews should be part of the JIRA entry for the change. Valuable
> > comments are made during code reviews, and these should be captured
> against
> > the issues to which they pertain.
>
> Personally I'm not that fond of having JIRA as the log for discussions.
> I prefer to have (threaded) discussions on the mailing-list and
> summarize the outcome in JIRA, either by copying a conclusion or
> pointing to the archives. From what I've seen in the ASF JIRA it seems
> to be a mixture though.
My personal preference would be as follows;
1) Issue gets raised on mailing list.
2) If the issue is genuine, then raise a JIRA id for it.
3) Add yourself as interested in the id, and you will be notified of
changes.
4) If you feel the need to comment, it will be recorded in the right place,
once. No need for any copying.
> There's also a testing issue here (for example, do you need to
> >> supply tests? if so, which framework or just unit tests). This
> >> is somewhat tied into:
> >>> * What kind of testing do we need?
> >
> >
> >
> > Every test should have a unit test. JUnit has served me well over the
> years.
> > Every patch should have an attached unit test to prove out the patch.
> >
> > Both the patch and the unit test must be reviewed.
> >
> > A bug in the unit test is sometimes worse than a bug in the patch !
>
> I hope Nigel of others familiar with the QA framework can shed some
> light here, but in general I think we should continue with what is
> already in place.
If it serves the community moving forward. I presume this is also up for
debate.
However, if I submit a patch I would feel honour bound to supply a unit
test.
For many things I want to submit I fail to see how to write a proper
> unit test (which can be entirely my fault). Most of these fixes were
> indirectly tested by deployment of complete systems and observed for
> strange/other behavior. It sounds kind of lame ... but e.g. writing a
> test for a modification to ClassDep I consider too complex and expensive
> versus seeing whether Seven and other services still correctly builds
> (which touches everything).
Yes, I know where you are coming from. However, I've been known to spend 1/2
tracking and fixing a bug. Then spending 2 more days writing test cases to
ensure that a) it's reproducible b) it won't happen again c) if
functionality changes the test case will highlight the change.
Perhaps it's not the answer but the working out which is important ? (as my
old maths professor would say!)
> If I was to offer my advice, I'd say keep the committer pool fairly small
> > and allow submissions in the form of a patch.
> >
> > A committer will then pick up the patch and review the change, and
> perhaps
> > communicate with the patch author regarding any pertinent details.
>
> In case of patches from non-committers I believe this is standard ASF
> practice.
Yes, this is true.
> Committer applies patch to the code base after reviews are complete.
> >
> > Hope it helps.....
>
> Any feelings with regard to code modifications of committers themselves,
> i.e. RTC versus CTR. Does it make any difference in your willingness to
> participate and becoming a committer.
I know which I prefer, but I'm agnostic to the process. I will still
continue to help and support where and when I can.
--Jools
Re: development process
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Mark,
On Aug 31, 2007, at 7:09 AM, Mark Brouwer wrote:
> Personally I'm not that fond of having JIRA as the log for
> discussions.
This appears to me to be a real issue, that is probably worthy of a
discussion and vote just by itself.
There are pros and cons to having discussions, that are too numerous
to summarize in five lines. It will need to be decided by the community.
> I prefer to have (threaded) discussions on the mailing-list and
> summarize the outcome in JIRA, either by copying a conclusion or
> pointing to the archives. From what I've seen in the ASF JIRA it seems
> to be a mixture though.
Right. Some communities like having every comment in JIRA (works well
for many) and some like having threaded email discussions,
considering that someone has to summarize (multiple times) for the
JIRA issue.
Craig
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Hi John,
John McClain - Sun Microsystems, Inc. wrote:
> Mark Brouwer wrote:
>> Thanks for chipping in Jools,
>>
>> Jools wrote:
>
> [...]
>
>>> Every test should have a unit test. JUnit has served me well over the
>>> years.
>
> FWIW, in "service land" (e.g. Reggie, Outrigger, etc.) I wouldn't
> characterize most (any?) of the existing tests as "unit tests", they
> generally run against complete services (or even multiple services). Not
> sure how "unit testable" the River services are.
>
> The other nice thing about writing against the service interfaces is the
> tests are (generally) still valid after the internals of the service
> changes.
That is certainly true but setting up a complete environment to run
tests after minor modifications is often a bit labor-intensive.
In hindsight, having learned from many mistakes and without any time
constraints imposed on me I would have often preferred writing the logic
of my services in a way that no Jini concepts such as lease and txn
participation would have crept deep into the code. That would allowed
for easier (unit) testing, which of course doesn't dismiss one from
distributed testing.
In the past I have converted Mahalo, Outrigger and Reggie to JSC
Services for deployment in Seven and due to the fact that in general
there is one huge server class with dozens of inner classes that
represents all server side logic and also all stuff related to
exporting, leases, etc. (starter framework) I had to do a lot of
stripping (of the code I mean).
In the Mahalo and Outrigger case I left most of that stuff intact,
because the JSC Specification introduces no limitation on e.g. using
Landlord, or writing your own transaction participation code, or using a
different persistence store. But in the case of Reggie (to be able to
support the inverted event model) I stripped almost everything except
for the stuff related to what Reggie really does, i.e. registering
services and performing lookups.
The above makes it harder for me to integrate changes from River to
Cheiron (always time consuming 3-way diffs/merges I did to inspect and
integrated the changes between the various JTSK releases) but it works
also the other way around. For example my work on Mahalo for named
transactions (mutual exclusion service) is also harder to migrate back
to River if there was interest in extending the Transaction
Specification due to the way the code is written.
I think all I want to say is that when the contributed services where
written in a way that most of the code was agnostic to e.g. the starter
framework and there would have been a greater separation between some of
the logic and the way these are exposed as Jini concepts that testing
would have been easier as well it would have allowed for easier
integration with more advanced/user friendly deployment platforms.
--
Mark
Re: development process
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Mark Brouwer wrote:
> Thanks for chipping in Jools,
>
> Jools wrote:
[...]
>> Every test should have a unit test. JUnit has served me well over the
>> years.
FWIW, in "service land" (e.g. Reggie, Outrigger, etc.) I wouldn't
characterize most (any?) of the existing tests as "unit tests", they
generally run against complete services (or even multiple services). Not
sure how "unit testable" the River services are.
The other nice thing about writing against the service interfaces is the
tests are (generally) still valid after the internals of the service
changes.
>> Every patch should have an attached unit test to prove out the patch.
>>
>> Both the patch and the unit test must be reviewed.
>>
>> A bug in the unit test is sometimes worse than a bug in the patch !
>
> I hope Nigel of others familiar with the QA framework can shed some
> light here, but in general I think we should continue with what is
> already in place.
>
> For many things I want to submit I fail to see how to write a proper
> unit test (which can be entirely my fault). Most of these fixes were
> indirectly tested by deployment of complete systems and observed for
> strange/other behavior. It sounds kind of lame ... but e.g. writing a
> test for a modification to ClassDep I consider too complex and expensive
> versus seeing whether Seven and other services still correctly builds
> (which touches everything).
I have certainly done a number of bug fixes where it was impractical to
write a test. Race conditions are a particular issue here.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Thanks for chipping in Jools,
Jools wrote:
> Sorry for any duplication in existing in other responses, not really had
> time to read the whole thread.
>
>
>> * What kind of development process do we need? JIRA issues for
>>> all changes? code reviews?
>
>
> IMHO I would prefer that JIRA be used for all code changes. It gives us
> visibility of what is happening, and can be used as the index for a change
> log which should be produced for every release.
Agreed.
> Also, it might be that a developer in his own time developers a patch which
> is then submitted to the committers in private which would mean that the
> community would not have any visibility of the change in code.
I'm not sure whether I like the idea that patches are reviewed and
discussed in private (in the general case). I can imagine that some form
of criticism is better served by going private, but in most cases I like
the transparency when there is e.g. disagreement about some code
modifications.
> Code reviews should be part of the JIRA entry for the change. Valuable
> comments are made during code reviews, and these should be captured against
> the issues to which they pertain.
Personally I'm not that fond of having JIRA as the log for discussions.
I prefer to have (threaded) discussions on the mailing-list and
summarize the outcome in JIRA, either by copying a conclusion or
pointing to the archives. From what I've seen in the ASF JIRA it seems
to be a mixture though.
> There's also a testing issue here (for example, do you need to
>> supply tests? if so, which framework or just unit tests). This
>> is somewhat tied into:
>>> * What kind of testing do we need?
>
>
>
> Every test should have a unit test. JUnit has served me well over the years.
> Every patch should have an attached unit test to prove out the patch.
>
> Both the patch and the unit test must be reviewed.
>
> A bug in the unit test is sometimes worse than a bug in the patch !
I hope Nigel of others familiar with the QA framework can shed some
light here, but in general I think we should continue with what is
already in place.
For many things I want to submit I fail to see how to write a proper
unit test (which can be entirely my fault). Most of these fixes were
indirectly tested by deployment of complete systems and observed for
strange/other behavior. It sounds kind of lame ... but e.g. writing a
test for a modification to ClassDep I consider too complex and expensive
versus seeing whether Seven and other services still correctly builds
(which touches everything).
> If I was to offer my advice, I'd say keep the committer pool fairly small
> and allow submissions in the form of a patch.
>
> A committer will then pick up the patch and review the change, and perhaps
> communicate with the patch author regarding any pertinent details.
In case of patches from non-committers I believe this is standard ASF
practice.
> Committer applies patch to the code base after reviews are complete.
>
> Hope it helps.....
Any feelings with regard to code modifications of committers themselves,
i.e. RTC versus CTR. Does it make any difference in your willingness to
participate and becoming a committer.
--
Mark
Re: development process
Posted by Jools <jo...@gmail.com>.
Sorry for any duplication in existing in other responses, not really had
time to read the whole thread.
> * What kind of development process do we need? JIRA issues for
> > all changes? code reviews?
IMHO I would prefer that JIRA be used for all code changes. It gives us
visibility of what is happening, and can be used as the index for a change
log which should be produced for every release.
Also, it might be that a developer in his own time developers a patch which
is then submitted to the committers in private which would mean that the
community would not have any visibility of the change in code.
Code reviews should be part of the JIRA entry for the change. Valuable
comments are made during code reviews, and these should be captured against
the issues to which they pertain.
There's also a testing issue here (for example, do you need to
> supply tests? if so, which framework or just unit tests). This
> is somewhat tied into:
> > * What kind of testing do we need?
Every test should have a unit test. JUnit has served me well over the years.
Every patch should have an attached unit test to prove out the patch.
Both the patch and the unit test must be reviewed.
A bug in the unit test is sometimes worse than a bug in the patch !
It would probably be easier to tackle these (dev process and
> testing process) separately.... but if they spill into one another,
> than so be it.
>
> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything). We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable. I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.
If I was to offer my advice, I'd say keep the committer pool fairly small
and allow submissions in the form of a patch.
A committer will then pick up the patch and review the change, and perhaps
communicate with the patch author regarding any pertinent details.
Committer applies patch to the code base after reviews are complete.
Hope it helps.....
--Jools
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> An important aspect that hasn't been touched on in this round
>>> of the discussion is "specs" vs code. Are people thinking
>>> public API changes will be under the same decision process as
>>> implementation changes?
>>
>> Should I read 'specs' for com.sun.jini (future
>> org.apache.river[.jini].*) and net.jini (the former Standards) as being
>> equal in this question?
>
> Good question, I don't recall prior discussions coming to any conclusion
> there.
That is my recollection too, but I think we should have that discussion
as well because no doubt there will be people who think they want to
add/deprecate methods/classes in the net.jini name space.
> But my question applies to both the public net.jini APIs and
> the subset of com.sun.jini APIs that are considered public.
Well that depends on what the outcome for the process for code
modifications will be, so I'll await that one first.
--
Mark
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
>> An important aspect that hasn't been touched on in this round
>> of the discussion is "specs" vs code. Are people thinking
>> public API changes will be under the same decision process as
>> implementation changes?
>
> Should I read 'specs' for com.sun.jini (future
> org.apache.river[.jini].*) and net.jini (the former Standards) as being
> equal in this question?
Good question, I don't recall prior discussions coming to any conclusion
there. But my question applies to both the public net.jini APIs and
the subset of com.sun.jini APIs that are considered public.
- Bob
Re: development process
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> An important aspect that hasn't been touched on in this round
> of the discussion is "specs" vs code. Are people thinking
> public API changes will be under the same decision process as
> implementation changes?
Should I read 'specs' for com.sun.jini (future
org.apache.river[.jini].*) and net.jini (the former Standards) as being
equal in this question?
--
Mark
Re: development process
Posted by Bob Scheifler <Bo...@Sun.COM>.
An important aspect that hasn't been touched on in this round
of the discussion is "specs" vs code. Are people thinking
public API changes will be under the same decision process as
implementation changes?
- Bob
Re: development process
Posted by Jim Hurley <Ji...@Sun.COM>.
On Sep 1, 2007, at 6:50 PM, Phil Steitz wrote:
> :
> :
> To put this matter to rest and get moving on community-building and
> cutting a release, I think it is a good idea to pull together a
> proposal and put it to a VOTE. In general, we like to avoid too many
> VOTEs, but in this case to move forward I think it is a good idea. I
> am happy to write up a proposal along the lines above, but would be
> heppier still if Jim or one of the initial committers proposed
> something that we could agree on.
Thanks Phil. I'll do my best to put together a proposal and get it
out by tomorrow.
This has been a long and winding discussion, but I think very good
in enabling lots of perspectives to get on the table. I've learned more
about the options, guidelines, and philosophy within ASF - so many
thanks to Craig, Jukka, Gianugo, and Phil for their insights.
Process discussions are never fun (obvious stated here ;-o), so I
appreciate the broad involvement from those in the Jini/River community
who added their voice to the thread. Thanks.
-Jim
Re: development process
Posted by Phil Steitz <ph...@gmail.com>.
On 8/27/07, Jim Hurley <Ji...@sun.com> wrote:
> (Note: we made good progress on the first question... but
> just leaving room for anyone else to add in before I summarized).
> Meanwhile... on to the next)
>
> As we continue discussing the "AR1" release questions/tasks...
> here's the next:
>
> > * What kind of development process do we need? JIRA issues for
> > all changes? code reviews?
>
> There's also a testing issue here (for example, do you need to
> supply tests? if so, which framework or just unit tests). This
> is somewhat tied into:
> > * What kind of testing do we need?
>
> It would probably be easier to tackle these (dev process and
> testing process) separately.... but if they spill into one another,
> than so be it.
>
> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything). We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable. I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.
>
> Please share your thoughts.
Sorry to be "late to the party" on this. Based on the discussion on
this thread and how things work elsewhere at the ASF, here are my
thoughts.
You are correct, Jim, when you state that the project has wide
latitude in defining its own policies and RTC is "allowed". This is
an important principle that we all need to keep in mind - it is up to
the community to decide how it operates. The mentors, incubator PMC
members and other interested parties at the ASF can comment, make
recommendations, share opinions and raise concerns, but it is up to
you, the community, to decide.
Open development is the one non-negotiable requirement at Apache - so
private code-related decision-making, private f2f reviews where
decisions are made, off-list communications, etc., cannot be an
essential part of the development process. It is certainly fine for
people to get together and look at, play with, brainstorm code-related
issues; but decisions have to be public and the entire community - not
just committers or PMC members - need to be allowed and encouraged to
participate in the discussion and review. One way to look at this is
to say that the thought process behind all changes needs to make sense
to, and be influenceable by, any iterested member of the community who
is willing to invest the time to dig into the code. This is the key
to growing the community and a big challenge for complex projects like
River. Documentation and test suites requiring no special setups are
key to this (an area where I would like to help).
Ron and others succinctly make the point that the complexity of the
River codebase and potential for changes to introduce subtle bugs
argues for careful review as part of the development process. On
this, all seem to agree. Open development, even using CTR, does not
have to mean "shooting from the hip" or "commit then crash" or
anything of the sort, though. We have other similarly complex
codebases at the ASF that use lots of discussion, tests and eyeballs
to ensure commit quality.
It seems reasonable that RTC could "force" the necessary review. I
agree with that from a practical standpoint, especially if formal
votes are required for each commit. I have to agree with the other
mentors, however, that this is an extreme measure and the same effect
could be accomplished by just agreeing that non-trivial code changes
start with list discussion, then JIRA tickets with patches, and then a
reasonable lazy consensus period before commit.
To get "the same effect" without the formal "rules" of RTC and commit
votes requires trust and cooperation. I have seen nothing on this
list to indicate that there is a real reason to worry about that.
To put this matter to rest and get moving on community-building and
cutting a release, I think it is a good idea to pull together a
proposal and put it to a VOTE. In general, we like to avoid too many
VOTEs, but in this case to move forward I think it is a good idea. I
am happy to write up a proposal along the lines above, but would be
heppier still if Jim or one of the initial committers proposed
something that we could agree on.
Once again, as I said at the beginning, it is up to the community how
we want to operate and we can always change down the road. The only
requirement - and the objective to keep our eyes on - is that we
remain open and inclusive.
Phil