Request change to RTC Process

[Kevan Miller <ke...@gmail.com>]

I'd like to request a change to the RTC process being used by  
Geronimo (or at least I'm requesting a relaxation of Ken's  
interpretation of the RTC process).

In Ken's announcement of the change to the commit model, he stated  
that a +1 to an RTC request means "I have applied this patch and  
tested it and found it good". Although a relaxation of this  
interpretation has been suggested (or mentioned), to my knowledge  
nothing has actually changed.

In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
difficult task for most committers. The fact that there are not more  
committers interested in these areas of Geronimo is an acknowledged  
issue. However, it's unlikely that current Geronimo committers want  
to be intimately familiar with some of these Geronimo components --  
we've all had our chance to get involved, so far, but have chosen not  
to.

That's a specific problem with the current process. However, I think  
there's a general problem with this interpretation for all areas of  
Geronimo. IMO, this interpretation is not really helping to address  
the fundamental problems/concerns which have prompted the move to  
RTC. IMO, these concerns are that 1) some enhancements are not being  
properly communicated with the Geronimo community, 2) too many  
discussions/debates are occurring on private channels, and 3) some  
people are being intimidated to remain silent on some public  
discussions.

I'd like to see some specific RTC guidelines created for Geronimo.  
I'm sure other projects must have already crafted similar guidelines.  
So, I'd like to take a look at those, before spending too much time  
on creating guidelines from scratch (I'd also like to shove 1.1. out  
the door...)

In the meantime, I propose the following interpretation of a +1 vote  
to an RTC request:

"I have reviewed (and possibly tested) this patch and found it good.  
I understand the capability which the patch is adding and support the  
direction in which it is taking the Geronimo project"

Comments and suggestions are, of course, welcome...

--kevan

Re: Request change to RTC Process

[Jeff Genender <jg...@apache.org>]

Kevan,

I totally agree with you.  I think "eyeballing" a patch is more than
good enough to wage a +1.  I surely do not have the time to apply and
test every patch.

Thanks,

Jeff


Kevan Miller wrote:
> I'd like to request a change to the RTC process being used by Geronimo
> (or at least I'm requesting a relaxation of Ken's interpretation of the
> RTC process).
> 
> In Ken's announcement of the change to the commit model, he stated that
> a +1 to an RTC request means "I have applied this patch and tested it
> and found it good". Although a relaxation of this interpretation has
> been suggested (or mentioned), to my knowledge nothing has actually
> changed.
> 
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and
> difficult task for most committers. The fact that there are not more
> committers interested in these areas of Geronimo is an acknowledged
> issue. However, it's unlikely that current Geronimo committers want to
> be intimately familiar with some of these Geronimo components -- we've
> all had our chance to get involved, so far, but have chosen not to.
> 
> That's a specific problem with the current process. However, I think
> there's a general problem with this interpretation for all areas of
> Geronimo. IMO, this interpretation is not really helping to address the
> fundamental problems/concerns which have prompted the move to RTC. IMO,
> these concerns are that 1) some enhancements are not being properly
> communicated with the Geronimo community, 2) too many
> discussions/debates are occurring on private channels, and 3) some
> people are being intimidated to remain silent on some public discussions.
> 
> I'd like to see some specific RTC guidelines created for Geronimo. I'm
> sure other projects must have already crafted similar guidelines. So,
> I'd like to take a look at those, before spending too much time on
> creating guidelines from scratch (I'd also like to shove 1.1. out the
> door...)
> 
> In the meantime, I propose the following interpretation of a +1 vote to
> an RTC request:
> 
> "I have reviewed (and possibly tested) this patch and found it good. I
> understand the capability which the patch is adding and support the
> direction in which it is taking the Geronimo project"
> 
> Comments and suggestions are, of course, welcome...
> 
> --kevan
> 
> 

Re: Request change to RTC Process

[Prasad Kashyap <go...@gmail.com>]

On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I don't consider this valid, either.  If you have the
> time to be a committer, you have the time to be part of
> the community and collaborate with your peers on the
> project.  One thing about RTC is that it tends to promote
> interaction, since people are dependent on each other and
> the occasional quid pro quo -- unlike the everyone haring
> off in his own direction with no-one else watching that
> can occur (and has occurred) under CTR.
>
> No-one says you have to test *anyone* else's patches.  Unless,
> of course, you hope they'll test *yours*, which is where
> the collaboration-for-the-project aspect comes in.  So if
> you don't find time to test someone else's code, regardless
> of for whom he may work, don't expect him to spend a lot
> of time testing *yours*.
>

True. But this quid pro quo holds good only for code submitted by
committers. Consider the case of active contributors who are
non-committers. If they choose to work on JIRAs in the wish list, it
will be quite a herculean task for them to get a sign-off from 3
committers. The "you scratch my back, I'll scratch yours" convenience
is not available for non-committers.

Going by this thread, if the committers of the project are
apprehensive about the RTC model and are requesting changes, then
contributors have an even tougher task cut out for them.  I hope that
doesn't sent a message to the community that only patches from
committers have any chance of getting in. I hope that doesn't
de-moralize the non-committers and turn them away from the project.

The RTC is not entirely bad either. It is a good thing to happen to
the project but not in it's present form. What would be good for
Geronimo would be take the best of RTC and CTR.

Here's something to think about -
1) Bug fixes (esp. blockers)  shouldn't need a review.
2) Improvements need atleast ONE +1 vote by a commiter. RTC turns into
CTR after 15 days. A reminder message to be sent 3 days before the
model changes to CTR.
3) Features need THREE +1 votes by other committers. RTC turns into
CTR after 30 days. A reminder message to be sent 7 days before the
model changes to CTR

Just a suggestion.

Cheers
Prasad.


> - --
> #ken    P-|}
>
> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> Author, developer, opinionist      http://Apache-Server.Com/
>
> "Millennium hand and shrimp!"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
> 38KzZSDD1WM=
> =M+w0
> -----END PGP SIGNATURE-----
>

Re: Request change to RTC Process

[Neal Sanche <ne...@nsdev.org>]

Hi Guys and Gals,

I just wanted to chime into this thread since the discussion is quite 
lively right now. Obviously not being a commiter on the project directly 
I don't really have a leg to stand on from a developer perspective, but 
I do come from a user perspective having worked through various issues 
with using Geronimo over the past year, and have been writing what I 
find for the community to learn from.

Development sure has slowed down recently. That's true. But, on the 
other hand, I have been able to check out the source tree and build it 
every single time I've tried lately. That is important to me when I'm 
trying to get some work done. But of course there's other ways to 
achieve this stability. For instance, an unstable and stable branch 
structure could cause the same stability for those of us in the 
community trying to get some work done. You folks in the developer 
community work on the trunk, and migrate fixes over to the stable 
branch, promoting the unstable branch to stable periodically. The 
problem with that approach is that it takes a lot of time to migrate 
fixes to the stable branch, and sometimes with large enough changes, 
it's next to impossible not to destabilize the stable branch.

 From my point of view I feel that slowing down the development at this 
point needs to be carefully balanced with the implementation of the Java 
EE 5 functionality. It would seem prudent to me, keeping in mind I have 
no real voice in your developer community, that two things need to be 
done. Keep part of the Geronimo tree stable for those of us who need to 
work with this stuff, while at the same time take the leash off those 
developers that feel the need to implement the Java EE 5 functionality, 
providing them a place where they can build out the new functionality as 
fast as possible with less restriction. In my opinion that is the most 
important thing for moving application servers into the future.

The fact that it took me over a week (of evenings) to write out a little 
J2EE application that had 1 CMP bean, 1 Session bean, 1 MDB bean, and a 
simple list based Add, Modify, Delete Struts application says something 
to me. Much of the time was trying to figure out what was going on 
between the EJB and Web containers (what JNDI names were valid and so 
on), trying to figure out what my deployment descriptors and deployment 
plans should say, and how to hook up my MDB bean to a GBean timer thread 
that would pulse the message queue periodically. The rest was all 
standard boilerplate code. Much of that will dissapear in a Java EE 5 
world. It makes me yearn for next summer when Geronimo would have had 
those features too (or still may).

With this 'new' (I use the word 'new' mostly in ignorance, for it may 
not be so) development process that has been imposed I feel that goal 
will be unattainable. I realize there is a lot of full-time developer 
horsepower behind the Glassfish project at Sun, but it's there for 
people to try out now, and people will: it's a big draw for developers. 
I also want to begin using Java EE 5, and would like that learning to be 
done on a Geronimo platform because I agree more with the licensing 
philosophy you have. Wrapping up the project in a red-tape effort to 
produce stability at this point may be a mistake (I am trying to be 
generous with my assessments even though I think it will have more dire 
consequences than I'm letting on).

I've likely already said too much. In summary, I'll say: Stability is 
good, put it on a stable branch. Then let the unstable development 
happen more freely (perhaps a single +1 to allow commits, without a 
patch review to at least have people state their intents publicly, but 
not have such a delay as 'must be a patch' and have three +1s). But for 
the stable branch, the 'must be a patch' and have 3 +1s would be the 
only way.

Cheers.

-Neal

Dain Sundstrom wrote:
> Ken, I think you have a faulty assumption that this project cares 
> about what you call "tested quality".  I for one am fine with changes 
> that haven't been tested to the level you are demanding from this 
> project.  Personally, I'd like to see less perfect software that 
> people want to use, other than perfect software that is so 
> functionally incomplete that no one will uses it.
>
> If the community agrees with me, is there anything we can do to change 
> your process or are we just stuck with it?

Re: Request change to RTC Process

[David Jencks <da...@yahoo.com>]

--- Dain Sundstrom <da...@iq80.com> wrote:

> On Jun 17, 2006, at 10:00 AM, Rodent of Unusual Size
> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Aaron Mulder wrote:
> >> On 6/17/06, Rodent of Unusual Size
> <Ke...@golux.com> wrote:
> >>> If that means things languish for weeks or
> months, then
> >>> that's what it means.
> >>
> >> I don't think this is a good idea.
> >
> > RTC means tested quality, not assumed quality.  If
> you
> > can't find people to test the quality of
> something, it
> > doesn't go in because the quality isn't assured.
> 
> Ken, I think you have a faulty assumption that this
> project cares  
> about what you call "tested quality".  I for one am
> fine with changes  
> that haven't been tested to the level you are
> demanding from this  
> project.  Personally, I'd like to see less perfect
> software that  
> people want to use, other than perfect software that
> is so  
> functionally incomplete that no one will uses it.
> 
> If the community agrees with me, is there anything
> we can do to  
> change your process or are we just stuck with it?
> 
> -dain 
> 

Ken, I think you are changing the story about the
purpose of RTC and I would like to know  why.  Your
original edict was:
----------

On May 21, 2006, at 7:57 PM, Rodent of Unusual Size
wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Due to concerns about how some changes have been
getting
made in the codebase, I am changing the commit model
for the time being.

Effective immediately, the development model for
Apache
Geronimo is changed from Commit-Then-Review to
Review-Then-Commit.

This means that all code changes that aren't for
documentation or a specific bug fix need to be
submitted as patches to the dev@geronimo.apache.org
list before getting committed.  They can get applied
after three other committers have voted +1 -- which
in this mode means 'I have applied this patch and
tested it and found it good' -- and no committers
have vetoed it.

I'm doing this to put to rest widespread concerns
that development in Geronimo *isn't* being done
entirely in the open.  It's a drastic step, but
those concerns have been around for a while and
just don't seem to be going away.

This also means that everyone needs to take interest
in the changes being proposed for the code.  Everyone
knowing more about what everyone else is doing isn't
a bad thing, and cooperating more to get them made
isn't a bad thing either.
- --
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini 
http://Ken.Coar.Org/
Author, developer, opinionist     
http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla -
http://enigmail.mozdev.org

iQCVAwUBRHD+TZrNPMCpn3XdAQJ9FwQAlwe2L+SvgffPyPSvXi0GjefJBSN/DZtQ
CPE/OPkJrC8QxKegPsu4wRmYJK0HkilWkojglPYSZkKEP94fOIEA+R3Nh+IByo+D
q8LF12qpkvxI9RjsEMEqa3+awNt7uag0GT0WgMDEX3VMupPRq3X52V7XiSzATqmp
rwb0h13AQlc=
=LjSH
-----END PGP SIGNATURE-----

--------------


Read it carefully.  You do not mention the word
"quality" once.  You do express concern about "how
some changes have been getting made in the codebase" 
and sa y IIUC that the purpose is to assure that  we
are communicating with each other about all changes. 
The closest to a mention of quality to my eyes is
"They can get applied
after three other committers have voted +1 -- which
in this mode means 'I have applied this patch and
tested it and found it good' -- and no committers
have vetoed it."

Tieing the phrase "found it good" to quality seems
disingenuous to me.  To me it primarily means, "this
moves the project in a direction I approve of", not
"this has few bugs"

I'd also like to point out that insisting that anyone
apply a patch and test it is actually likely to reduce
quality over simply inspecting the patch carefully. 
I'm sure you are well aware of all the studies on code
inspection that show that code inspection is the
fastest cheapest and most reliable way to eliminate
defects.  Personally I trust ALL the geronimo
committers to have verified that any patch they
propose applies cleanly, keeps all unit tests passing,
and results in a server that starts.  I would much
rather 3 other people look carefully at my code than
all the committers verify that I'm not lying that the
patch can be applied and doesn't break anything
obvious, which is what your requirement boils down to.

I repeat dain's question, is this process something
the project  gets to decide on or only you?

My point of view at this time is that I think having 3
people review patches before or after they are 
applied is a good idea that will improve the
community, but that requiring anyone to verify that a 
patch applies, builds, and runs is a waste of
everyones time that will reduce overall software
quality and reduce the number of people willing to
contribute to geronimo.  Can you please supply any
evidence that your assertion that asking people to
apply a patch, build the result, etc, provides better
quality than spending the same time in code
inspection?  

thanks
david jencks

Re: Request change to RTC Process

[Dain Sundstrom <da...@iq80.com>]

On Jun 17, 2006, at 10:00 AM, Rodent of Unusual Size wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aaron Mulder wrote:
>> On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>>> If that means things languish for weeks or months, then
>>> that's what it means.
>>
>> I don't think this is a good idea.
>
> RTC means tested quality, not assumed quality.  If you
> can't find people to test the quality of something, it
> doesn't go in because the quality isn't assured.

Ken, I think you have a faulty assumption that this project cares  
about what you call "tested quality".  I for one am fine with changes  
that haven't been tested to the level you are demanding from this  
project.  Personally, I'd like to see less perfect software that  
people want to use, other than perfect software that is so  
functionally incomplete that no one will uses it.

If the community agrees with me, is there anything we can do to  
change your process or are we just stuck with it?

-dain 

Re: Request change to RTC Process

[Aaron Mulder <am...@alumni.princeton.edu>]

On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> > Why are you so hung up on this?
>
> Because you did it under CTR and claimed that RTC wouldn't
> have made any difference.

What are you talking about?  When did I claim anything about what RTC
would or wouldn't have changed?

> CTR also says 'ideas are always RTC.'  You didn't offer
> any of the new concept up for discussion, you just went
> ahead and did it.  So it wasn't even done under the CTR
> rules.

I disagree.  I discussed the feature with a number of people, we
tossed a couple works in progress around, and then I checked it in.
If you want to say it should have been discussed with the whole
community, that's fine, that's constructive criticism.  If you change
the whole mechanics of the project because I didn't discuss it with
enough people, that's just ridiculous.

> > It certainly doesn't seem sensible to put a major crimp in project
> > progress in order to assure that no code goes in that hasn't been
> > pre-discussed (except, again, for a bug fix release like 1.1.1).
>
> Your opinion.  Other opinions vary.

How can you assert anyone's opinion but your own?  Shall we take a
vote?  Isn't that the Apache way?  Where in the meritocracy and Apache
way does it say that the PMC chair makes all the decisions?

> > Because Geronimo doesn't exist in a vacuum.  We've started
> > significantly after competing open-source application servers such as
> > JOnAS, JBoss, and GlassFish.
>
> So the goal of Geronimo isn't to be good, or the best, but
> to compete with other offerings in the same space?  I think
> perhaps we should poll the entire project on that.

Is the very definition of "be the best" that it exceeds the competing
offerings in the same space?  If we're lacking major features that
they offer and that developers are looking for, isn't that the
textbook definition of "not the best"?

> > This is the time to hurry, not the time to stall.
>
> Considering the strain that the 'hurrying' has put on the
> project, I think it is most *definitely* time to slow
> down and take stock.
>
> > I'll take a breather once we have full clustering support, a lively
> > community of plugins, and a solid set of Java EE 5 features.
>
> Don't assume that everyone else wants to go at the same
> pace you do, has the same goals you have, or believes that
> the end justifies the means.

Fine -- let's take a vote.  I'm all about that.

Thanks,
    Aaron

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Mulder wrote:
> On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>> RTC means that you can't unilaterally and arbitrarily do things
>> *without* discussion.  Like, say, setting up a 
>> non-project-sponsored .com site and pointing project code at it
>> without discussion.
> 
> Why are you so hung up on this?

Because you did it under CTR and claimed that RTC wouldn't
have made any difference.

> I don't see a problem.

Which may be part of the problem.

> This is how CTR works -- if there's an issue, people raise it, and
> changes are made.

CTR also says 'ideas are always RTC.'  You didn't offer
any of the new concept up for discussion, you just went
ahead and did it.  So it wasn't even done under the CTR
rules.

> It doesn't seem sensible that people are complaining about this
> months later.

At this point I think the complaints are more likely to
be addressing the apparent fact that you didn't and don't
see anything inappropriate with what you did.

> It certainly doesn't seem sensible to put a major crimp in project
> progress in order to assure that no code goes in that hasn't been
> pre-discussed (except, again, for a bug fix release like 1.1.1).

Your opinion.  Other opinions vary.

>> Only if some specific date schedule is a factor.  And if it is, I
>> ask again: why?
> 
> Because Geronimo doesn't exist in a vacuum.  We've started 
> significantly after competing open-source application servers such as
> JOnAS, JBoss, and GlassFish.

So the goal of Geronimo isn't to be good, or the best, but
to compete with other offerings in the same space?  I think
perhaps we should poll the entire project on that.

> This is the time to hurry, not the time to stall.

Considering the strain that the 'hurrying' has put on the
project, I think it is most *definitely* time to slow
down and take stock.

> I'll take a breather once we have full clustering support, a lively
> community of plugins, and a solid set of Java EE 5 features.

Don't assume that everyone else wants to go at the same
pace you do, has the same goals you have, or believes that
the end justifies the means.
- --
#ken	P-|}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJQ/OZrNPMCpn3XdAQJKlAP/X89Pw+AlZR0wuvinVfHnkmTIOznbucV4
nGaihOjCvl8mltxri4dXIFnd4eud6neezuhzoP8O5aEkIVUs7+/mswboDLt0a0tp
bIG8GZJ4tzxGRgq3DxihK4EAR5RPZYXgP1xHWbuBb+J/SYzZ1Knfo3mQ7gaWkjn5
gB6iofiyPPs=
=UnXe
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[Aaron Mulder <am...@alumni.princeton.edu>]

On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> RTC means that you can't unilaterally and arbitrarily do
> things *without* discussion.  Like, say, setting up a
> non-project-sponsored .com site and pointing project code at
> it without discussion.

Why are you so hung up on this?  The change was reviewed and issues
were raised and long ago we put in a list served from Apache hardware
so the community could adjust this (and they have chosen not to!).  I
don't see a problem.  This is how CTR works -- if there's an issue,
people raise it, and changes are made.  It doesn't seem sensible that
people are complaining about this months later.  It certainly doesn't
seem sensible to put a major crimp in project progress in order to
assure that no code goes in that hasn't been pre-discussed (except,
again, for a bug fix release like 1.1.1).

>> Now, you can argue in favor of this for a maintenance / bug-fix
>> release like 1.1.1, where the main goal is to improve quality and
>> extra eyes on every line may help avoid bugs.  But it's a significant
>> obstacle for a feature release like 1.2.
>
> Only if some specific date schedule is a factor.  And if it is,
> I ask again: why?

Because Geronimo doesn't exist in a vacuum.  We've started
significantly after competing open-source application servers such as
JOnAS, JBoss, and GlassFish.  We made great progress in getting to
J2EE 1.4 and we've put in some great innovations, but we're still
significantly behind.  GlassFish and JBoss both have Java EE 5
features, and we don't.  That's one of the key items on the agenda for
Geronimo 1.2.    I know you're not real interested in Java
development, but you must realize how much the tide has turned toward
lightweight development and architectures and technologies like AJAX
and SOA.  J2EE 1.4 is a significant obstacle to that -- the web
services features are terrible, EJB 2.x is anything but lightweight,
and the integration strategies are what, JAX-RPC, CORBA and J2EE
connectors?  That's a joke!

This is the time to hurry, not the time to stall.  I'll take a
breather once we have full clustering support, a lively community of
plugins, and a solid set of Java EE 5 features.

Thanks,
    Aaron

Re: Request change to RTC Process

[Matt Hogstrom <ma...@hogstrom.org>]

ROFLMAO :)

See my comments on chimerical (excellent...excellent)

Agree with your other statements.

Hiram Chirino wrote:
> On 6/19/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
>> I'm not sure Ken's intent was to introduce a new concept as much as he 
>> was pointing out a side
>> benefit.  My understanding was that RTC was enforce to improve 
>> community collaboration and
>> communication.  Clearly its not working very well based on the 
>> comments in this thread.  Seems to be
>> going the opposite way.
>>
>> Clearly the opinion of some on the thread is they trust each other and 
>> communication has already
>> been fine so this is just slowing them down?  Is that the summary?  
>> I'd have to disagree that things
>> have been fine although I'll concede that perhaps some changes to RTC 
>> may be warranted.
>>
>> I'm sitting in an airport right now so I don't have time to do this 
>> but it might be nice if someone
>> can compile some statistics on what has actually transpired and then 
>> we can discuss why this isn't
>> working and then make some recommendations as to how to move forward 
>> rather than the current
>> dialogue which doesn't seem to be improving collaboration and 
>> communication but is actually driving
>> polarization (which I think we're trying to avoid).
>>
>> Hiram Chirino wrote:
>> > On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>> >
>> >> RTC means tested quality, not assumed quality.  If you
>> >> can't find people to test the quality of something, it
>> >> doesn't go in because the quality isn't assured.
>> >>
>> >
>> > I'm not sure where 'quality' requirement is coming from.  I don't
>> > think it's ever been discussed on the list.  For example, I don't
>> > remember a discussion of should we focus on stabilizing and in effect
>> > slowing down the development of Geronimo.  Or should it focus on
>> > implementing the J2EE features that it's missing as quickly as
>> > possible?  I can see how IBM would prefer the 1st option since it
>> > would allow it's chimerical offerings to stay differentiated from
>> > Geronimo. But I don't think the rest of this community would agree.
>>
>> I'm having trouble understanding the above paragraph and Dain's 
>> comments in another e-mail.  I
>> proposed that we take 1.1.1 to stabilize it because there are a number 
>> of quality issues in Geronimo
>> that make it undesireable in a production enviroment.  NPEs abound and 
>> we have usability problems.
>> Personally I think these need to be addressed to improve the adoption 
>> rate of Geronimo.  I'm not
>> aware of a lot of developers or administrators that accept a server 
>> that is 90% reliable (my made up
>> number).  If you disagree that fixing these are a waste of time then 
>> please speak up.  I have other
>> things to do then.
> 
> I think that's great! and I hope a 1.1.2 rolls out soon too and that
> the 1.1 branch keeps stabilizing at a good pace.
> 
>>
>> I'm also having difficulty understanding the chimerical comment.  I 
>> can only assume that you mean
>> that WAS CE is some mythical and unachievable goal?  Here is where I'm 
>> drawing my inference from:
>>
>> http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html
>>
>> Here is a quote from the above:
>>
>> 1. Merely imaginary; produced by or as if by a wildly fanciful 
>> imagination; fantastic; improbable or
>> unrealistic.
>>
>> If WAS CE is mythical then I'm not sure what hope there is for 
>> Geronimo because it is the basis for
>> WAS CE.  If CE can't succeed then I'd say Geronimo poisoned the apple.
>>
>> Can you please clarify your comments Hiram because they aren't making 
>> sense to me.  I'm sure you
>> don't mean the above.
>>
> 
> lol.. that's why you can't trust spell checkers! replace chimerical
> with commercial!  I was more referring to WAS compared to WASCE and it
> staying highly differentiated because RTC could stifle geronimo's
> innovation.
> 

Ok this is awesome :-0  I was wondering if you meant commercial but it was such a perfect fit at 
chimerical you had me guessing :)

>>
>> >
>> >> >  - Eliminates trust.  I know say, David J has a lot of experience 
>> with
>> >> > say, connectors, and if he puts a patch in that area, I think I can
>> >> > read his summary and trust that he's implemented it sensibly.  
>> But now
>> >> > that doesn't count, I have to review it line by line?  I think it
>> >> > should be up to me which patches I trust and which patches want to
>> >> > review in detail.
>> >>
>> >> Considering the problems concerning trust that are already
>> >> extant, I think the first sentence as a conclusion is bogus.
>> >> And once again you want to *assume* quality rather than *assure*
>> >> it.  That's how CTR works.  RTC works to *assure* it.
>> >>
>> >
>> > I trust a bunch of the folks that work here and while I could review
>> > patches, unless you are working with that code ALL the time, there
>> > could be unexpected side-effects that only folks working on it all the
>> > time could catch.  So I would rather than assume I know what I'm
>> > doing, I'd delegate to folks who specialize in that area of Geronimo.
>> >
>>
>> By way of example, if its connector or Tx code I'd trust Jencks.  
>> Perhaps the problem is that
>> Geronimo has not attracted enough people to have more than one person 
>> interested in a specific area.
>>   I would say this is unfortunate but I agree with your trust comment 
>> in light of individual components.
>>
>> >> >  - Favors full-time open source developers over free-time
>> >> > contributors.  I don't have enough time to work on the work *I* want
>> >> > to do in my spare time, much less get a clean tree to apply, 
>> test, and
>> >> > review everyone else's patches
>> >>
>> >> I don't consider this valid, either.  If you have the
>> >> time to be a committer, you have the time to be part of
>> >> the community and collaborate with your peers on the
>> >> project.  One thing about RTC is that it tends to promote
>> >> interaction, since people are dependent on each other and
>> >> the occasional quid pro quo -- unlike the everyone haring
>> >> off in his own direction with no-one else watching that
>> >> can occur (and has occurred) under CTR.
>> >>
>> >
>> > Well, I think I have my plate full just implementing that patches.  I
>> > think every one's plate if full too.  So either we are slowing down
>> > everything by 3x or we are assuming that every one's bandwidth was 1/4
>> > full (or something like that).  It seems to me that things have slowed
>> > down by 3x.  BTW who are the full time developers on Geronimo?  Cause
>> > it seems to me that If I want to get my patches in I better start
>> > helping them out so that they can return the favor.
>> >
>>
>> I think your last comment is the point in terms of working together.  
>> Your comments are valid as
>> code quality would slip in other areas if we're all spread so thin 
>> that we can't get anything done.
>>   We are interested in quality code, right ?
>>
> 
> and mostly innovation.
> 
>> >> No-one says you have to test *anyone* else's patches.  Unless,
>> >> of course, you hope they'll test *yours*, which is where
>> >> the collaboration-for-the-project aspect comes in.  So if
>> >> you don't find time to test someone else's code, regardless
>> >> of for whom he may work, don't expect him to spend a lot
>> >> of time testing *yours*.
>> >>
>> >> >  - Favors bug fixes over innovation.  Anything that's 
>> characterized as
>> >> > a bug fix gets a free pass.
>> >>
>> >> Quality, remember?  Not bells or features.
>> >>
>> >
>> > I would agree we need quality in the 1.0.x and 1.1.x development
>> > branches.  I don't think we need to stress quality in the 1.x
>> > branches.
>> >
>>
>> Perhaps this is a point that needs to be clarified with the 
>> community.  I've seen other posts that
>> talk about stable and unstable branches.  I think this makes sense in 
>> the short term and perhaps in
>> the long term if there are people that are interested in shoring up 
>> Geronimo.  Hopefully the people
>> writing the prototypes would be good enough to help fix the other 
>> branches as well :)
>>
> 
> Yeah. I guess we should start throwing up new threads for this.
> 
>> >> >  - Encourages "cliques".  Who am I going to ask to give me a 
>> quick +1?
>> >>
>> >> Rubbish.  'Cliques' is exactly what the previous environment
>> >> supported.  No such thing as a 'quick +1,' unless the patch
>> >> has been tested quickly -- and by three people.  Anyone who
>> >> gives a quick +1 as lip-service under RTC is in trouble.
>> >>
>> >
>> > Right.. but, you still need to entice 3 other people to do work for
>> > you.. Unless I 'm giving them a pay check, this is sometimes hard to
>> > do.  I think that 'cliques' of a sort will form.  In the heavy
>> > lifter's sub-consciousness they will soon start to think "I'll review
>> > X's patch because I'm in debt to him since he reviewed my patch.  If I
>> > don't keep working on his patches, perhaps he will stop working on
>> > mine."  Also, I would think that folk who work for the same employer
>> > will be more likely to review each others patches before they review
>> > patches for folks they don't know.
>> >
>>
>> I think we already have cliques of people that are accustomed to 
>> working together.  This isn't a
>> problem if they are not exclusionary.  Otherwise it would be hard to 
>> grow the project.  Perhaps this
> 
> agreed.
> 
>> is Ken's point and he is looking for evidence that this is working.  
>> My guess is that if people want
>> to work alone we'll see more sandbox activity and side branches where 
>> activity occurs rather than
>> trunk.  If thats the case then I think Ken's concerns are validated to 
>> an extent.
>>
> 
> Perhaps.. I could see folks working on a branch/sandbox to validate
> ideas before wasting folks time reviewing things that eventually need
> to be rolled back.
> 
>> >> > Now, you can argue in favor of this for a maintenance / bug-fix
>> >> > release like 1.1.1, where the main goal is to improve quality and
>> >> > extra eyes on every line may help avoid bugs.  But it's a 
>> significant
>> >> > obstacle for a feature release like 1.2.
>> >>
>> >> Only if some specific date schedule is a factor.  And if it is,
>> >> I ask again: why?  Or if the 'features' aren't sufficiently
>> >> popular among the developers -- in which case why should they
>> >> be included?
>> >>
>> >
>> > You bring up 2 issues.  J2EE requires you to implement a ton of non
>> > popular features.  They are features no one really uses!  And they are
>> > hard to implement.  So, yes we need to develop un-popular features
>> > because they are mandated by J2EE (Just think CORBA).
>> >
>> > The date thing.. Isn't the aim of Geronimo to be the best open source
>> > Application Server?  Well, we are not right now.  I don't want to work
>> > on a project that is content with not being used.  "Lets do all this
>> > work and put it on the shelf."  It's cute, but it falls so short of
>> > everything else that is available.  And date has alot to do with it.
>> > There is no point in implementing a feature that has become legacy
>> > technology.
>> >
>>
>> Yup, EJBs are a good example as well as J2EE WebServices.  Perhaps 
>> then Geronimo should decide that
>> J2EE isn't its goal and jettison those features and not care about 
>> CTS.  I think that would be
>> unfortunate as we'd lose the credibility of having certification but 
>> it sounds like people would
>> rather be developing non-J2EE services and features.
>>
> 
> At least personally, I think certification is important.  It ensures
> at least some minimum level of interop.  But I do agree that we are
> far behind the curve in giving  users that next generation development
> platform.  And that's what users want.
> 
>> > The success of the HTTPD server is because it got such huge adaptation
>> > in the market.  Once we get that kind of adaptation, I think we can
>> > all start to breath easier and start to thing about quality and not
>> > quantity.
>> >
>> >> > Additionally, it doesn't
>> >> > help the stated goal of improving communication.
>> >>
>> >> I disagree here, as well.  I think it has already done a
>> >> tremendous job of improving communication.
>> >>
>> >> > If everyone wants to
>> >> > see what I'm doing, and I post it to a Jira and announce it, they 
>> can
>> >> > see.  If they want to review in detail, they can.  If they can 
>> review
>> >> > the description and perhaps give it a cursory glance and give it 
>> a +1,
>> >> > that's achieved the goal of making sure they're aware of things 
>> going
>> >> > on in the project.
>> >>
>> >> You're replacing the 'must be reviewed' aspect of RTC -- which
>> >> is the major point -- with 'reviewed if people feel like it
>> >> and remember to.'
>> >>
>> >> RTC means that you can't unilaterally and arbitrarily do
>> >> things *without* discussion.  Like, say, setting up a
>> >> non-project-sponsored .com site and pointing project code at
>> >> it without discussion.
>> >>
>> >> > If you say they can't +1 it without an exhaustive
>> >> > review and test, that doesn't add to the quality or quantity of
>> >> > communication.  It only adds obstacles to delivering the features
>> >> > desired for the 1.2 release.
>> >>
>> >> I regard the first sentence as as a completely baseless assertion.
>> >> For the second.. Again, only if time is a factor.  Or if changes
>> >> are too uninteresting to be able to get three people to even look
>> >> at them.
>> >> - --
>> >> #ken    P-|}
>> >>
>> >> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
>> >> Author, developer, opinionist      http://Apache-Server.Com/
>> >>
>> >> "Millennium hand and shrimp!"
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.2.4 (MingW32)
>> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >>
>> >> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
>> >> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
>> >> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
>> >> 38KzZSDD1WM=
>> >> =M+w0
>> >> -----END PGP SIGNATURE-----
>> >>
>> >
>> >
>>
> 
> 

Re: Request change to RTC Process

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/19/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side
> benefit.  My understanding was that RTC was enforce to improve community collaboration and
> communication.  Clearly its not working very well based on the comments in this thread.  Seems to be
> going the opposite way.
>
> Clearly the opinion of some on the thread is they trust each other and communication has already
> been fine so this is just slowing them down?  Is that the summary?  I'd have to disagree that things
> have been fine although I'll concede that perhaps some changes to RTC may be warranted.
>
> I'm sitting in an airport right now so I don't have time to do this but it might be nice if someone
> can compile some statistics on what has actually transpired and then we can discuss why this isn't
> working and then make some recommendations as to how to move forward rather than the current
> dialogue which doesn't seem to be improving collaboration and communication but is actually driving
> polarization (which I think we're trying to avoid).
>
> Hiram Chirino wrote:
> > On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> >
> >> RTC means tested quality, not assumed quality.  If you
> >> can't find people to test the quality of something, it
> >> doesn't go in because the quality isn't assured.
> >>
> >
> > I'm not sure where 'quality' requirement is coming from.  I don't
> > think it's ever been discussed on the list.  For example, I don't
> > remember a discussion of should we focus on stabilizing and in effect
> > slowing down the development of Geronimo.  Or should it focus on
> > implementing the J2EE features that it's missing as quickly as
> > possible?  I can see how IBM would prefer the 1st option since it
> > would allow it's chimerical offerings to stay differentiated from
> > Geronimo. But I don't think the rest of this community would agree.
>
> I'm having trouble understanding the above paragraph and Dain's comments in another e-mail.  I
> proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in Geronimo
> that make it undesireable in a production enviroment.  NPEs abound and we have usability problems.
> Personally I think these need to be addressed to improve the adoption rate of Geronimo.  I'm not
> aware of a lot of developers or administrators that accept a server that is 90% reliable (my made up
> number).  If you disagree that fixing these are a waste of time then please speak up.  I have other
> things to do then.

I think that's great! and I hope a 1.1.2 rolls out soon too and that
the 1.1 branch keeps stabilizing at a good pace.

>
> I'm also having difficulty understanding the chimerical comment.  I can only assume that you mean
> that WAS CE is some mythical and unachievable goal?  Here is where I'm drawing my inference from:
>
> http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html
>
> Here is a quote from the above:
>
> 1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable or
> unrealistic.
>
> If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the basis for
> WAS CE.  If CE can't succeed then I'd say Geronimo poisoned the apple.
>
> Can you please clarify your comments Hiram because they aren't making sense to me.  I'm sure you
> don't mean the above.
>

lol.. that's why you can't trust spell checkers! replace chimerical
with commercial!  I was more referring to WAS compared to WASCE and it
staying highly differentiated because RTC could stifle geronimo's
innovation.

>
> >
> >> >  - Eliminates trust.  I know say, David J has a lot of experience with
> >> > say, connectors, and if he puts a patch in that area, I think I can
> >> > read his summary and trust that he's implemented it sensibly.  But now
> >> > that doesn't count, I have to review it line by line?  I think it
> >> > should be up to me which patches I trust and which patches want to
> >> > review in detail.
> >>
> >> Considering the problems concerning trust that are already
> >> extant, I think the first sentence as a conclusion is bogus.
> >> And once again you want to *assume* quality rather than *assure*
> >> it.  That's how CTR works.  RTC works to *assure* it.
> >>
> >
> > I trust a bunch of the folks that work here and while I could review
> > patches, unless you are working with that code ALL the time, there
> > could be unexpected side-effects that only folks working on it all the
> > time could catch.  So I would rather than assume I know what I'm
> > doing, I'd delegate to folks who specialize in that area of Geronimo.
> >
>
> By way of example, if its connector or Tx code I'd trust Jencks.  Perhaps the problem is that
> Geronimo has not attracted enough people to have more than one person interested in a specific area.
>   I would say this is unfortunate but I agree with your trust comment in light of individual components.
>
> >> >  - Favors full-time open source developers over free-time
> >> > contributors.  I don't have enough time to work on the work *I* want
> >> > to do in my spare time, much less get a clean tree to apply, test, and
> >> > review everyone else's patches
> >>
> >> I don't consider this valid, either.  If you have the
> >> time to be a committer, you have the time to be part of
> >> the community and collaborate with your peers on the
> >> project.  One thing about RTC is that it tends to promote
> >> interaction, since people are dependent on each other and
> >> the occasional quid pro quo -- unlike the everyone haring
> >> off in his own direction with no-one else watching that
> >> can occur (and has occurred) under CTR.
> >>
> >
> > Well, I think I have my plate full just implementing that patches.  I
> > think every one's plate if full too.  So either we are slowing down
> > everything by 3x or we are assuming that every one's bandwidth was 1/4
> > full (or something like that).  It seems to me that things have slowed
> > down by 3x.  BTW who are the full time developers on Geronimo?  Cause
> > it seems to me that If I want to get my patches in I better start
> > helping them out so that they can return the favor.
> >
>
> I think your last comment is the point in terms of working together.  Your comments are valid as
> code quality would slip in other areas if we're all spread so thin that we can't get anything done.
>   We are interested in quality code, right ?
>

and mostly innovation.

> >> No-one says you have to test *anyone* else's patches.  Unless,
> >> of course, you hope they'll test *yours*, which is where
> >> the collaboration-for-the-project aspect comes in.  So if
> >> you don't find time to test someone else's code, regardless
> >> of for whom he may work, don't expect him to spend a lot
> >> of time testing *yours*.
> >>
> >> >  - Favors bug fixes over innovation.  Anything that's characterized as
> >> > a bug fix gets a free pass.
> >>
> >> Quality, remember?  Not bells or features.
> >>
> >
> > I would agree we need quality in the 1.0.x and 1.1.x development
> > branches.  I don't think we need to stress quality in the 1.x
> > branches.
> >
>
> Perhaps this is a point that needs to be clarified with the community.  I've seen other posts that
> talk about stable and unstable branches.  I think this makes sense in the short term and perhaps in
> the long term if there are people that are interested in shoring up Geronimo.  Hopefully the people
> writing the prototypes would be good enough to help fix the other branches as well :)
>

Yeah. I guess we should start throwing up new threads for this.

> >> >  - Encourages "cliques".  Who am I going to ask to give me a quick +1?
> >>
> >> Rubbish.  'Cliques' is exactly what the previous environment
> >> supported.  No such thing as a 'quick +1,' unless the patch
> >> has been tested quickly -- and by three people.  Anyone who
> >> gives a quick +1 as lip-service under RTC is in trouble.
> >>
> >
> > Right.. but, you still need to entice 3 other people to do work for
> > you.. Unless I 'm giving them a pay check, this is sometimes hard to
> > do.  I think that 'cliques' of a sort will form.  In the heavy
> > lifter's sub-consciousness they will soon start to think "I'll review
> > X's patch because I'm in debt to him since he reviewed my patch.  If I
> > don't keep working on his patches, perhaps he will stop working on
> > mine."  Also, I would think that folk who work for the same employer
> > will be more likely to review each others patches before they review
> > patches for folks they don't know.
> >
>
> I think we already have cliques of people that are accustomed to working together.  This isn't a
> problem if they are not exclusionary.  Otherwise it would be hard to grow the project.  Perhaps this

agreed.

> is Ken's point and he is looking for evidence that this is working.  My guess is that if people want
> to work alone we'll see more sandbox activity and side branches where activity occurs rather than
> trunk.  If thats the case then I think Ken's concerns are validated to an extent.
>

Perhaps.. I could see folks working on a branch/sandbox to validate
ideas before wasting folks time reviewing things that eventually need
to be rolled back.

> >> > Now, you can argue in favor of this for a maintenance / bug-fix
> >> > release like 1.1.1, where the main goal is to improve quality and
> >> > extra eyes on every line may help avoid bugs.  But it's a significant
> >> > obstacle for a feature release like 1.2.
> >>
> >> Only if some specific date schedule is a factor.  And if it is,
> >> I ask again: why?  Or if the 'features' aren't sufficiently
> >> popular among the developers -- in which case why should they
> >> be included?
> >>
> >
> > You bring up 2 issues.  J2EE requires you to implement a ton of non
> > popular features.  They are features no one really uses!  And they are
> > hard to implement.  So, yes we need to develop un-popular features
> > because they are mandated by J2EE (Just think CORBA).
> >
> > The date thing.. Isn't the aim of Geronimo to be the best open source
> > Application Server?  Well, we are not right now.  I don't want to work
> > on a project that is content with not being used.  "Lets do all this
> > work and put it on the shelf."  It's cute, but it falls so short of
> > everything else that is available.  And date has alot to do with it.
> > There is no point in implementing a feature that has become legacy
> > technology.
> >
>
> Yup, EJBs are a good example as well as J2EE WebServices.  Perhaps then Geronimo should decide that
> J2EE isn't its goal and jettison those features and not care about CTS.  I think that would be
> unfortunate as we'd lose the credibility of having certification but it sounds like people would
> rather be developing non-J2EE services and features.
>

At least personally, I think certification is important.  It ensures
at least some minimum level of interop.  But I do agree that we are
far behind the curve in giving  users that next generation development
platform.  And that's what users want.

> > The success of the HTTPD server is because it got such huge adaptation
> > in the market.  Once we get that kind of adaptation, I think we can
> > all start to breath easier and start to thing about quality and not
> > quantity.
> >
> >> > Additionally, it doesn't
> >> > help the stated goal of improving communication.
> >>
> >> I disagree here, as well.  I think it has already done a
> >> tremendous job of improving communication.
> >>
> >> > If everyone wants to
> >> > see what I'm doing, and I post it to a Jira and announce it, they can
> >> > see.  If they want to review in detail, they can.  If they can review
> >> > the description and perhaps give it a cursory glance and give it a +1,
> >> > that's achieved the goal of making sure they're aware of things going
> >> > on in the project.
> >>
> >> You're replacing the 'must be reviewed' aspect of RTC -- which
> >> is the major point -- with 'reviewed if people feel like it
> >> and remember to.'
> >>
> >> RTC means that you can't unilaterally and arbitrarily do
> >> things *without* discussion.  Like, say, setting up a
> >> non-project-sponsored .com site and pointing project code at
> >> it without discussion.
> >>
> >> > If you say they can't +1 it without an exhaustive
> >> > review and test, that doesn't add to the quality or quantity of
> >> > communication.  It only adds obstacles to delivering the features
> >> > desired for the 1.2 release.
> >>
> >> I regard the first sentence as as a completely baseless assertion.
> >> For the second.. Again, only if time is a factor.  Or if changes
> >> are too uninteresting to be able to get three people to even look
> >> at them.
> >> - --
> >> #ken    P-|}
> >>
> >> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> >> Author, developer, opinionist      http://Apache-Server.Com/
> >>
> >> "Millennium hand and shrimp!"
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.2.4 (MingW32)
> >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >>
> >> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
> >> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
> >> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
> >> 38KzZSDD1WM=
> >> =M+w0
> >> -----END PGP SIGNATURE-----
> >>
> >
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Request change to RTC Process

[David Blevins <da...@visi.com>]

On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:

> I'm not sure Ken's intent was to introduce a new concept as much as  
> he was pointing out a side benefit.  My understanding was that RTC  
> was enforce to improve community collaboration and communication.   
> Clearly its not working very well based on the comments in this  
> thread.  Seems to be going the opposite way.

I'd agree with your first two statements, but I think you went a  
little off track in your generalization that "it's not working very  
well" and "seems to be going the opposite way."

I certainly don't agree.  I'm very happy to see so many people say  
they like RTC -- I like it too -- and am encouraged to see people  
actually think about RTC in general and how it can benefit Geronimo  
best.

In the eye of this beholder, these are good omens.

-David

Re: Request change to RTC Process

[Matt Hogstrom <ma...@hogstrom.org>]

Ok, I understand the issue.  To be honest I took a look at Hiram's RTC request.  The time to take 
and apply the patches and test them was a bit onerous given the other things I was working on.

I think Ken's switch from CTR to RTC was to promote communication as well as improve knowledge (I 
really do think his comment on quality was a side benefit and not the driving force) of other areas. 
   I think Greg Stein had also indicated that perhaps a review (and not a token +1) was fair.  I 
think that would be a place to perhaps move to and if Ken perceives were back in a ditch then he can 
tighten it back up.

I agree that communication is much better since the RTC.  Thanks to DBlevins for whacking me in his 
response to this.  It seemed that this thread was going the wrong way but perhaps I mis read it.

Cheers.

Dain Sundstrom wrote:
> On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:
> 
>> Clearly the opinion of some on the thread is they trust each other and 
>> communication has already been fine so this is just slowing them 
>> down?  Is that the summary?  I'd have to disagree that things have 
>> been fine although I'll concede that perhaps some changes to RTC may 
>> be warranted.
> 
> I think that the model of reviewing is working and I like it.  What I 
> don't like is the requirement to physically apply every patch and run a 
> full build.  I feel that a careful read of the patch is good enough for 
> trunk and tends to spur collaboration and communication that was the 
> original intent of switching to RTC.
> 
> For micro releases, I taking a more conservative approach may be 
> warranted, but I honestly don't see how applying a patch and building it 
> is going to find more error.  For example, the NPEs you pointed out are 
> likely to only be found by testing user applications, and when we do 
> find one a test case should be added to prevent regressions.
> 
> -dain
> 
> 
> 
> 

Re: Request change to RTC Process

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/19/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:
>
> > Clearly the opinion of some on the thread is they trust each other
> > and communication has already been fine so this is just slowing
> > them down?  Is that the summary?  I'd have to disagree that things
> > have been fine although I'll concede that perhaps some changes to
> > RTC may be warranted.
>
> I think that the model of reviewing is working and I like it.  What I
> don't like is the requirement to physically apply every patch and run
> a full build.  I feel that a careful read of the patch is good enough
> for trunk and tends to spur collaboration and communication that was
> the original intent of switching to RTC.
>

+1

> For micro releases, I taking a more conservative approach may be
> warranted, but I honestly don't see how applying a patch and building
> it is going to find more error.  For example, the NPEs you pointed
> out are likely to only be found by testing user applications, and
> when we do find one a test case should be added to prevent regressions.
>
> -dain
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Request change to RTC Process

[Dain Sundstrom <da...@iq80.com>]

On Jun 19, 2006, at 4:28 PM, Matt Hogstrom wrote:

> Clearly the opinion of some on the thread is they trust each other  
> and communication has already been fine so this is just slowing  
> them down?  Is that the summary?  I'd have to disagree that things  
> have been fine although I'll concede that perhaps some changes to  
> RTC may be warranted.

I think that the model of reviewing is working and I like it.  What I  
don't like is the requirement to physically apply every patch and run  
a full build.  I feel that a careful read of the patch is good enough  
for trunk and tends to spur collaboration and communication that was  
the original intent of switching to RTC.

For micro releases, I taking a more conservative approach may be  
warranted, but I honestly don't see how applying a patch and building  
it is going to find more error.  For example, the NPEs you pointed  
out are likely to only be found by testing user applications, and  
when we do find one a test case should be added to prevent regressions.

-dain

Re: Request change to RTC Process

[Matt Hogstrom <ma...@hogstrom.org>]

I'm not sure Ken's intent was to introduce a new concept as much as he was pointing out a side 
benefit.  My understanding was that RTC was enforce to improve community collaboration and 
communication.  Clearly its not working very well based on the comments in this thread.  Seems to be 
going the opposite way.

Clearly the opinion of some on the thread is they trust each other and communication has already 
been fine so this is just slowing them down?  Is that the summary?  I'd have to disagree that things 
have been fine although I'll concede that perhaps some changes to RTC may be warranted.

I'm sitting in an airport right now so I don't have time to do this but it might be nice if someone 
can compile some statistics on what has actually transpired and then we can discuss why this isn't 
working and then make some recommendations as to how to move forward rather than the current 
dialogue which doesn't seem to be improving collaboration and communication but is actually driving 
polarization (which I think we're trying to avoid).

Hiram Chirino wrote:
> On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> 
>> RTC means tested quality, not assumed quality.  If you
>> can't find people to test the quality of something, it
>> doesn't go in because the quality isn't assured.
>>
> 
> I'm not sure where 'quality' requirement is coming from.  I don't
> think it's ever been discussed on the list.  For example, I don't
> remember a discussion of should we focus on stabilizing and in effect
> slowing down the development of Geronimo.  Or should it focus on
> implementing the J2EE features that it's missing as quickly as
> possible?  I can see how IBM would prefer the 1st option since it
> would allow it's chimerical offerings to stay differentiated from
> Geronimo. But I don't think the rest of this community would agree.

I'm having trouble understanding the above paragraph and Dain's comments in another e-mail.  I 
proposed that we take 1.1.1 to stabilize it because there are a number of quality issues in Geronimo 
that make it undesireable in a production enviroment.  NPEs abound and we have usability problems. 
Personally I think these need to be addressed to improve the adoption rate of Geronimo.  I'm not 
aware of a lot of developers or administrators that accept a server that is 90% reliable (my made up 
number).  If you disagree that fixing these are a waste of time then please speak up.  I have other 
things to do then.

I'm also having difficulty understanding the chimerical comment.  I can only assume that you mean 
that WAS CE is some mythical and unachievable goal?  Here is where I'm drawing my inference from:

http://dictionary.reference.com/wordoftheday/archive/2003/02/24.html

Here is a quote from the above:

1. Merely imaginary; produced by or as if by a wildly fanciful imagination; fantastic; improbable or 
unrealistic.

If WAS CE is mythical then I'm not sure what hope there is for Geronimo because it is the basis for 
WAS CE.  If CE can't succeed then I'd say Geronimo poisoned the apple.

Can you please clarify your comments Hiram because they aren't making sense to me.  I'm sure you 
don't mean the above.


> 
>> >  - Eliminates trust.  I know say, David J has a lot of experience with
>> > say, connectors, and if he puts a patch in that area, I think I can
>> > read his summary and trust that he's implemented it sensibly.  But now
>> > that doesn't count, I have to review it line by line?  I think it
>> > should be up to me which patches I trust and which patches want to
>> > review in detail.
>>
>> Considering the problems concerning trust that are already
>> extant, I think the first sentence as a conclusion is bogus.
>> And once again you want to *assume* quality rather than *assure*
>> it.  That's how CTR works.  RTC works to *assure* it.
>>
> 
> I trust a bunch of the folks that work here and while I could review
> patches, unless you are working with that code ALL the time, there
> could be unexpected side-effects that only folks working on it all the
> time could catch.  So I would rather than assume I know what I'm
> doing, I'd delegate to folks who specialize in that area of Geronimo.
> 

By way of example, if its connector or Tx code I'd trust Jencks.  Perhaps the problem is that 
Geronimo has not attracted enough people to have more than one person interested in a specific area. 
  I would say this is unfortunate but I agree with your trust comment in light of individual components.

>> >  - Favors full-time open source developers over free-time
>> > contributors.  I don't have enough time to work on the work *I* want
>> > to do in my spare time, much less get a clean tree to apply, test, and
>> > review everyone else's patches
>>
>> I don't consider this valid, either.  If you have the
>> time to be a committer, you have the time to be part of
>> the community and collaborate with your peers on the
>> project.  One thing about RTC is that it tends to promote
>> interaction, since people are dependent on each other and
>> the occasional quid pro quo -- unlike the everyone haring
>> off in his own direction with no-one else watching that
>> can occur (and has occurred) under CTR.
>>
> 
> Well, I think I have my plate full just implementing that patches.  I
> think every one's plate if full too.  So either we are slowing down
> everything by 3x or we are assuming that every one's bandwidth was 1/4
> full (or something like that).  It seems to me that things have slowed
> down by 3x.  BTW who are the full time developers on Geronimo?  Cause
> it seems to me that If I want to get my patches in I better start
> helping them out so that they can return the favor.
> 

I think your last comment is the point in terms of working together.  Your comments are valid as 
code quality would slip in other areas if we're all spread so thin that we can't get anything done. 
  We are interested in quality code, right ?

>> No-one says you have to test *anyone* else's patches.  Unless,
>> of course, you hope they'll test *yours*, which is where
>> the collaboration-for-the-project aspect comes in.  So if
>> you don't find time to test someone else's code, regardless
>> of for whom he may work, don't expect him to spend a lot
>> of time testing *yours*.
>>
>> >  - Favors bug fixes over innovation.  Anything that's characterized as
>> > a bug fix gets a free pass.
>>
>> Quality, remember?  Not bells or features.
>>
> 
> I would agree we need quality in the 1.0.x and 1.1.x development
> branches.  I don't think we need to stress quality in the 1.x
> branches.
> 

Perhaps this is a point that needs to be clarified with the community.  I've seen other posts that 
talk about stable and unstable branches.  I think this makes sense in the short term and perhaps in 
the long term if there are people that are interested in shoring up Geronimo.  Hopefully the people 
writing the prototypes would be good enough to help fix the other branches as well :)

>> >  - Encourages "cliques".  Who am I going to ask to give me a quick +1?
>>
>> Rubbish.  'Cliques' is exactly what the previous environment
>> supported.  No such thing as a 'quick +1,' unless the patch
>> has been tested quickly -- and by three people.  Anyone who
>> gives a quick +1 as lip-service under RTC is in trouble.
>>
> 
> Right.. but, you still need to entice 3 other people to do work for
> you.. Unless I 'm giving them a pay check, this is sometimes hard to
> do.  I think that 'cliques' of a sort will form.  In the heavy
> lifter's sub-consciousness they will soon start to think "I'll review
> X's patch because I'm in debt to him since he reviewed my patch.  If I
> don't keep working on his patches, perhaps he will stop working on
> mine."  Also, I would think that folk who work for the same employer
> will be more likely to review each others patches before they review
> patches for folks they don't know.
> 

I think we already have cliques of people that are accustomed to working together.  This isn't a 
problem if they are not exclusionary.  Otherwise it would be hard to grow the project.  Perhaps this 
is Ken's point and he is looking for evidence that this is working.  My guess is that if people want 
to work alone we'll see more sandbox activity and side branches where activity occurs rather than 
trunk.  If thats the case then I think Ken's concerns are validated to an extent.

>> > Now, you can argue in favor of this for a maintenance / bug-fix
>> > release like 1.1.1, where the main goal is to improve quality and
>> > extra eyes on every line may help avoid bugs.  But it's a significant
>> > obstacle for a feature release like 1.2.
>>
>> Only if some specific date schedule is a factor.  And if it is,
>> I ask again: why?  Or if the 'features' aren't sufficiently
>> popular among the developers -- in which case why should they
>> be included?
>>
> 
> You bring up 2 issues.  J2EE requires you to implement a ton of non
> popular features.  They are features no one really uses!  And they are
> hard to implement.  So, yes we need to develop un-popular features
> because they are mandated by J2EE (Just think CORBA).
> 
> The date thing.. Isn't the aim of Geronimo to be the best open source
> Application Server?  Well, we are not right now.  I don't want to work
> on a project that is content with not being used.  "Lets do all this
> work and put it on the shelf."  It's cute, but it falls so short of
> everything else that is available.  And date has alot to do with it.
> There is no point in implementing a feature that has become legacy
> technology.
> 

Yup, EJBs are a good example as well as J2EE WebServices.  Perhaps then Geronimo should decide that 
J2EE isn't its goal and jettison those features and not care about CTS.  I think that would be 
unfortunate as we'd lose the credibility of having certification but it sounds like people would 
rather be developing non-J2EE services and features.

> The success of the HTTPD server is because it got such huge adaptation
> in the market.  Once we get that kind of adaptation, I think we can
> all start to breath easier and start to thing about quality and not
> quantity.
> 
>> > Additionally, it doesn't
>> > help the stated goal of improving communication.
>>
>> I disagree here, as well.  I think it has already done a
>> tremendous job of improving communication.
>>
>> > If everyone wants to
>> > see what I'm doing, and I post it to a Jira and announce it, they can
>> > see.  If they want to review in detail, they can.  If they can review
>> > the description and perhaps give it a cursory glance and give it a +1,
>> > that's achieved the goal of making sure they're aware of things going
>> > on in the project.
>>
>> You're replacing the 'must be reviewed' aspect of RTC -- which
>> is the major point -- with 'reviewed if people feel like it
>> and remember to.'
>>
>> RTC means that you can't unilaterally and arbitrarily do
>> things *without* discussion.  Like, say, setting up a
>> non-project-sponsored .com site and pointing project code at
>> it without discussion.
>>
>> > If you say they can't +1 it without an exhaustive
>> > review and test, that doesn't add to the quality or quantity of
>> > communication.  It only adds obstacles to delivering the features
>> > desired for the 1.2 release.
>>
>> I regard the first sentence as as a completely baseless assertion.
>> For the second.. Again, only if time is a factor.  Or if changes
>> are too uninteresting to be able to get three people to even look
>> at them.
>> - --
>> #ken    P-|}
>>
>> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
>> Author, developer, opinionist      http://Apache-Server.Com/
>>
>> "Millennium hand and shrimp!"
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.2.4 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
>> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
>> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
>> 38KzZSDD1WM=
>> =M+w0
>> -----END PGP SIGNATURE-----
>>
> 
> 

Re: Request change to RTC Process

[Hiram Chirino <hi...@hiramchirino.com>]

On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:

> RTC means tested quality, not assumed quality.  If you
> can't find people to test the quality of something, it
> doesn't go in because the quality isn't assured.
>

I'm not sure where 'quality' requirement is coming from.  I don't
think it's ever been discussed on the list.  For example, I don't
remember a discussion of should we focus on stabilizing and in effect
slowing down the development of Geronimo.  Or should it focus on
implementing the J2EE features that it's missing as quickly as
possible?  I can see how IBM would prefer the 1st option since it
would allow it's chimerical offerings to stay differentiated from
Geronimo. But I don't think the rest of this community would agree.

> >  - Eliminates trust.  I know say, David J has a lot of experience with
> > say, connectors, and if he puts a patch in that area, I think I can
> > read his summary and trust that he's implemented it sensibly.  But now
> > that doesn't count, I have to review it line by line?  I think it
> > should be up to me which patches I trust and which patches want to
> > review in detail.
>
> Considering the problems concerning trust that are already
> extant, I think the first sentence as a conclusion is bogus.
> And once again you want to *assume* quality rather than *assure*
> it.  That's how CTR works.  RTC works to *assure* it.
>

I trust a bunch of the folks that work here and while I could review
patches, unless you are working with that code ALL the time, there
could be unexpected side-effects that only folks working on it all the
time could catch.  So I would rather than assume I know what I'm
doing, I'd delegate to folks who specialize in that area of Geronimo.

> >  - Favors full-time open source developers over free-time
> > contributors.  I don't have enough time to work on the work *I* want
> > to do in my spare time, much less get a clean tree to apply, test, and
> > review everyone else's patches
>
> I don't consider this valid, either.  If you have the
> time to be a committer, you have the time to be part of
> the community and collaborate with your peers on the
> project.  One thing about RTC is that it tends to promote
> interaction, since people are dependent on each other and
> the occasional quid pro quo -- unlike the everyone haring
> off in his own direction with no-one else watching that
> can occur (and has occurred) under CTR.
>

Well, I think I have my plate full just implementing that patches.  I
think every one's plate if full too.  So either we are slowing down
everything by 3x or we are assuming that every one's bandwidth was 1/4
full (or something like that).  It seems to me that things have slowed
down by 3x.  BTW who are the full time developers on Geronimo?  Cause
it seems to me that If I want to get my patches in I better start
helping them out so that they can return the favor.

> No-one says you have to test *anyone* else's patches.  Unless,
> of course, you hope they'll test *yours*, which is where
> the collaboration-for-the-project aspect comes in.  So if
> you don't find time to test someone else's code, regardless
> of for whom he may work, don't expect him to spend a lot
> of time testing *yours*.
>
> >  - Favors bug fixes over innovation.  Anything that's characterized as
> > a bug fix gets a free pass.
>
> Quality, remember?  Not bells or features.
>

I would agree we need quality in the 1.0.x and 1.1.x development
branches.  I don't think we need to stress quality in the 1.x
branches.

> >  - Encourages "cliques".  Who am I going to ask to give me a quick +1?
>
> Rubbish.  'Cliques' is exactly what the previous environment
> supported.  No such thing as a 'quick +1,' unless the patch
> has been tested quickly -- and by three people.  Anyone who
> gives a quick +1 as lip-service under RTC is in trouble.
>

Right.. but, you still need to entice 3 other people to do work for
you.. Unless I 'm giving them a pay check, this is sometimes hard to
do.  I think that 'cliques' of a sort will form.  In the heavy
lifter's sub-consciousness they will soon start to think "I'll review
X's patch because I'm in debt to him since he reviewed my patch.  If I
don't keep working on his patches, perhaps he will stop working on
mine."  Also, I would think that folk who work for the same employer
will be more likely to review each others patches before they review
patches for folks they don't know.

> > Now, you can argue in favor of this for a maintenance / bug-fix
> > release like 1.1.1, where the main goal is to improve quality and
> > extra eyes on every line may help avoid bugs.  But it's a significant
> > obstacle for a feature release like 1.2.
>
> Only if some specific date schedule is a factor.  And if it is,
> I ask again: why?  Or if the 'features' aren't sufficiently
> popular among the developers -- in which case why should they
> be included?
>

You bring up 2 issues.  J2EE requires you to implement a ton of non
popular features.  They are features no one really uses!  And they are
hard to implement.  So, yes we need to develop un-popular features
because they are mandated by J2EE (Just think CORBA).

The date thing.. Isn't the aim of Geronimo to be the best open source
Application Server?  Well, we are not right now.  I don't want to work
on a project that is content with not being used.  "Lets do all this
work and put it on the shelf."  It's cute, but it falls so short of
everything else that is available.  And date has alot to do with it.
There is no point in implementing a feature that has become legacy
technology.

The success of the HTTPD server is because it got such huge adaptation
in the market.  Once we get that kind of adaptation, I think we can
all start to breath easier and start to thing about quality and not
quantity.

> > Additionally, it doesn't
> > help the stated goal of improving communication.
>
> I disagree here, as well.  I think it has already done a
> tremendous job of improving communication.
>
> > If everyone wants to
> > see what I'm doing, and I post it to a Jira and announce it, they can
> > see.  If they want to review in detail, they can.  If they can review
> > the description and perhaps give it a cursory glance and give it a +1,
> > that's achieved the goal of making sure they're aware of things going
> > on in the project.
>
> You're replacing the 'must be reviewed' aspect of RTC -- which
> is the major point -- with 'reviewed if people feel like it
> and remember to.'
>
> RTC means that you can't unilaterally and arbitrarily do
> things *without* discussion.  Like, say, setting up a
> non-project-sponsored .com site and pointing project code at
> it without discussion.
>
> > If you say they can't +1 it without an exhaustive
> > review and test, that doesn't add to the quality or quantity of
> > communication.  It only adds obstacles to delivering the features
> > desired for the 1.2 release.
>
> I regard the first sentence as as a completely baseless assertion.
> For the second.. Again, only if time is a factor.  Or if changes
> are too uninteresting to be able to get three people to even look
> at them.
> - --
> #ken    P-|}
>
> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> Author, developer, opinionist      http://Apache-Server.Com/
>
> "Millennium hand and shrimp!"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
> 38KzZSDD1WM=
> =M+w0
> -----END PGP SIGNATURE-----
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: Request change to RTC Process

[David Blevins <da...@visi.com>]

On Jun 17, 2006, at 3:49 PM, Rodent of Unusual Size wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> David Blevins wrote:
>> Is there a code quality issue in this community?
>
> Not necessarily.  There *does* appear to be an issue
> with some people not wanting to abide by the requirements
> of the RTC model.

Ok.  IMHO, it's fine to revisit and even challenge the RTC topic if  
people need a reminder of what got us here -- part of the learning  
process.

But let's not use quality concerns as a justification for our model  
of RTC, it isn't necessary.  Ultimately, no changes in our RTC model  
will occur by definitively proving or disproving quality.   
Entertaining the debate leads people to believe it holds merit and  
it's not one of our issues.

-David

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Blevins wrote:
> Is there a code quality issue in this community?

Not necessarily.  There *does* appear to be an issue
with some people not wanting to abide by the requirements
of the RTC model.
- --
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJSHFJrNPMCpn3XdAQJx7wQAq67vDwENf8lACyDs3V0Ri0KXCNMKof8A
gIzBzIcU2iHRHM8UMK9PPZAADKSfILnGcdgJJc+6YFwj0NvQ9cOLvcoyNHlj/Lk+
7Wn0LSjrYsPQryN7AZ4sK1IvuqBXxm+CY8WI6QmELj24aACw8MTMrQmYImCYfynX
0UkHH/wKhLw=
=cPFU
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[David Blevins <da...@visi.com>]

Is there a code quality issue in this community?

-David

On Jun 17, 2006, at 10:00 AM, Rodent of Unusual Size wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Aaron Mulder wrote:
>> On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>>> If that means things languish for weeks or months, then
>>> that's what it means.
>>
>> I don't think this is a good idea.
>
> RTC means tested quality, not assumed quality.  If you
> can't find people to test the quality of something, it
> doesn't go in because the quality isn't assured.
>
>>  - Eliminates trust.  I know say, David J has a lot of experience  
>> with
>> say, connectors, and if he puts a patch in that area, I think I can
>> read his summary and trust that he's implemented it sensibly.  But  
>> now
>> that doesn't count, I have to review it line by line?  I think it
>> should be up to me which patches I trust and which patches want to
>> review in detail.
>
> Considering the problems concerning trust that are already
> extant, I think the first sentence as a conclusion is bogus.
> And once again you want to *assume* quality rather than *assure*
> it.  That's how CTR works.  RTC works to *assure* it.
>
>>  - Favors full-time open source developers over free-time
>> contributors.  I don't have enough time to work on the work *I* want
>> to do in my spare time, much less get a clean tree to apply, test,  
>> and
>> review everyone else's patches
>
> I don't consider this valid, either.  If you have the
> time to be a committer, you have the time to be part of
> the community and collaborate with your peers on the
> project.  One thing about RTC is that it tends to promote
> interaction, since people are dependent on each other and
> the occasional quid pro quo -- unlike the everyone haring
> off in his own direction with no-one else watching that
> can occur (and has occurred) under CTR.
>
> No-one says you have to test *anyone* else's patches.  Unless,
> of course, you hope they'll test *yours*, which is where
> the collaboration-for-the-project aspect comes in.  So if
> you don't find time to test someone else's code, regardless
> of for whom he may work, don't expect him to spend a lot
> of time testing *yours*.
>
>>  - Favors bug fixes over innovation.  Anything that's  
>> characterized as
>> a bug fix gets a free pass.
>
> Quality, remember?  Not bells or features.
>
>> Also, it's unmanageable to review large
>> changes in detail, so only small changes have any good change of  
>> being
>> applied in a timely fashion.
>
> Time, time, time.  What is this obsession with getting a
> perfect release out according to some arbitrary schedule?
>
>>  - Encourages "cliques".  Who am I going to ask to give me a quick  
>> +1?
>
> Rubbish.  'Cliques' is exactly what the previous environment
> supported.  No such thing as a 'quick +1,' unless the patch
> has been tested quickly -- and by three people.  Anyone who
> gives a quick +1 as lip-service under RTC is in trouble.
>
>> Now, you can argue in favor of this for a maintenance / bug-fix
>> release like 1.1.1, where the main goal is to improve quality and
>> extra eyes on every line may help avoid bugs.  But it's a significant
>> obstacle for a feature release like 1.2.
>
> Only if some specific date schedule is a factor.  And if it is,
> I ask again: why?  Or if the 'features' aren't sufficiently
> popular among the developers -- in which case why should they
> be included?
>
>> Additionally, it doesn't
>> help the stated goal of improving communication.
>
> I disagree here, as well.  I think it has already done a
> tremendous job of improving communication.
>
>> If everyone wants to
>> see what I'm doing, and I post it to a Jira and announce it, they can
>> see.  If they want to review in detail, they can.  If they can review
>> the description and perhaps give it a cursory glance and give it a  
>> +1,
>> that's achieved the goal of making sure they're aware of things going
>> on in the project.
>
> You're replacing the 'must be reviewed' aspect of RTC -- which
> is the major point -- with 'reviewed if people feel like it
> and remember to.'
>
> RTC means that you can't unilaterally and arbitrarily do
> things *without* discussion.  Like, say, setting up a
> non-project-sponsored .com site and pointing project code at
> it without discussion.
>
>> If you say they can't +1 it without an exhaustive
>> review and test, that doesn't add to the quality or quantity of
>> communication.  It only adds obstacles to delivering the features
>> desired for the 1.2 release.
>
> I regard the first sentence as as a completely baseless assertion.
> For the second.. Again, only if time is a factor.  Or if changes
> are too uninteresting to be able to get three people to even look
> at them.
> - --
> #ken	P-|}
>
> Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
> Author, developer, opinionist      http://Apache-Server.Com/
>
> "Millennium hand and shrimp!"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
> X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
> wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
> 38KzZSDD1WM=
> =M+w0
> -----END PGP SIGNATURE-----
>

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Mulder wrote:
> On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
>> If that means things languish for weeks or months, then
>> that's what it means.
> 
> I don't think this is a good idea.

RTC means tested quality, not assumed quality.  If you
can't find people to test the quality of something, it
doesn't go in because the quality isn't assured.

>  - Eliminates trust.  I know say, David J has a lot of experience with
> say, connectors, and if he puts a patch in that area, I think I can
> read his summary and trust that he's implemented it sensibly.  But now
> that doesn't count, I have to review it line by line?  I think it
> should be up to me which patches I trust and which patches want to
> review in detail.

Considering the problems concerning trust that are already
extant, I think the first sentence as a conclusion is bogus.
And once again you want to *assume* quality rather than *assure*
it.  That's how CTR works.  RTC works to *assure* it.

>  - Favors full-time open source developers over free-time
> contributors.  I don't have enough time to work on the work *I* want
> to do in my spare time, much less get a clean tree to apply, test, and
> review everyone else's patches

I don't consider this valid, either.  If you have the
time to be a committer, you have the time to be part of
the community and collaborate with your peers on the
project.  One thing about RTC is that it tends to promote
interaction, since people are dependent on each other and
the occasional quid pro quo -- unlike the everyone haring
off in his own direction with no-one else watching that
can occur (and has occurred) under CTR.

No-one says you have to test *anyone* else's patches.  Unless,
of course, you hope they'll test *yours*, which is where
the collaboration-for-the-project aspect comes in.  So if
you don't find time to test someone else's code, regardless
of for whom he may work, don't expect him to spend a lot
of time testing *yours*.

>  - Favors bug fixes over innovation.  Anything that's characterized as
> a bug fix gets a free pass.

Quality, remember?  Not bells or features.

> Also, it's unmanageable to review large
> changes in detail, so only small changes have any good change of being
> applied in a timely fashion.

Time, time, time.  What is this obsession with getting a
perfect release out according to some arbitrary schedule?

>  - Encourages "cliques".  Who am I going to ask to give me a quick +1?

Rubbish.  'Cliques' is exactly what the previous environment
supported.  No such thing as a 'quick +1,' unless the patch
has been tested quickly -- and by three people.  Anyone who
gives a quick +1 as lip-service under RTC is in trouble.

> Now, you can argue in favor of this for a maintenance / bug-fix
> release like 1.1.1, where the main goal is to improve quality and
> extra eyes on every line may help avoid bugs.  But it's a significant
> obstacle for a feature release like 1.2.

Only if some specific date schedule is a factor.  And if it is,
I ask again: why?  Or if the 'features' aren't sufficiently
popular among the developers -- in which case why should they
be included?

> Additionally, it doesn't
> help the stated goal of improving communication.

I disagree here, as well.  I think it has already done a
tremendous job of improving communication.

> If everyone wants to
> see what I'm doing, and I post it to a Jira and announce it, they can
> see.  If they want to review in detail, they can.  If they can review
> the description and perhaps give it a cursory glance and give it a +1,
> that's achieved the goal of making sure they're aware of things going
> on in the project.

You're replacing the 'must be reviewed' aspect of RTC -- which
is the major point -- with 'reviewed if people feel like it
and remember to.'

RTC means that you can't unilaterally and arbitrarily do
things *without* discussion.  Like, say, setting up a
non-project-sponsored .com site and pointing project code at
it without discussion.

> If you say they can't +1 it without an exhaustive
> review and test, that doesn't add to the quality or quantity of
> communication.  It only adds obstacles to delivering the features
> desired for the 1.2 release.

I regard the first sentence as as a completely baseless assertion.
For the second.. Again, only if time is a factor.  Or if changes
are too uninteresting to be able to get three people to even look
at them.
- --
#ken	P-|}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJQ1JZrNPMCpn3XdAQKLAQQAx58qgOEEdnrL79vPuXn8AWYwgrVcwH1j
X7cnZsvTGmQ4uZW7GiCjjkU2E0H0gGMIRUHFCuV8lul85DectAxE3+4M6pYPAG8v
wzg8OOYUl4Wmv6s31M1VDBruCseGLh01c+ilYl2G61mM+c+Ppt3dduD/VCqQDeao
38KzZSDD1WM=
=M+w0
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[Aaron Mulder <am...@alumni.princeton.edu>]

On 6/17/06, Rodent of Unusual Size <Ke...@golux.com> wrote:
> If that means things languish for weeks or months, then
> that's what it means.

I don't think this is a good idea.

The RTC process (as Ken is describing it) has a number of side effects:

 - Eliminates trust.  I know say, David J has a lot of experience with
say, connectors, and if he puts a patch in that area, I think I can
read his summary and trust that he's implemented it sensibly.  But now
that doesn't count, I have to review it line by line?  I think it
should be up to me which patches I trust and which patches want to
review in detail.

 - Favors full-time open source developers over free-time
contributors.  I don't have enough time to work on the work *I* want
to do in my spare time, much less get a clean tree to apply, test, and
review everyone else's patches

 - Favors bug fixes over innovation.  Anything that's characterized as
a bug fix gets a free pass.  Also, it's unmanageable to review large
changes in detail, so only small changes have any good change of being
applied in a timely fashion.

 - Encourages "cliques".  Who am I going to ask to give me a quick +1?

Now, you can argue in favor of this for a maintenance / bug-fix
release like 1.1.1, where the main goal is to improve quality and
extra eyes on every line may help avoid bugs.  But it's a significant
obstacle for a feature release like 1.2.  Additionally, it doesn't
help the stated goal of improving communication.  If everyone wants to
see what I'm doing, and I post it to a Jira and announce it, they can
see.  If they want to review in detail, they can.  If they can review
the description and perhaps give it a cursory glance and give it a +1,
that's achieved the goal of making sure they're aware of things going
on in the project.  If you say they can't +1 it without an exhaustive
review and test, that doesn't add to the quality or quantity of
communication.  It only adds obstacles to delivering the features
desired for the 1.2 release.

Thanks,
    Aaron

Re: Request change to RTC Process

[Kevan Miller <ke...@gmail.com>]

On Jun 17, 2006, at 10:21 AM, Rodent of Unusual Size wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevan Miller wrote:
>>
>> In Ken's announcement of the change to the commit model, he stated
>> that a +1 to an RTC request means "I have applied this patch and
>> tested it and found it good". Although a relaxation of this
>> interpretation has been suggested (or mentioned), to my knowledge
>> nothing has actually changed.
>
> Correct.
>
>> In some areas of Geronimo (e.g. devtools), this is a cumbersome and
>> difficult task for most committers. The fact that there are not more
>> committers interested in these areas of Geronimo is an acknowledged
>> issue. However, it's unlikely that current Geronimo committers want
>> to be intimately familiar with some of these Geronimo components --
>> we've all had our chance to get involved, so far, but have chosen not
>> to.
>
> Noted.
>
>> That's a specific problem with the current process. However, I think
>> there's a general problem with this interpretation for all areas of
>> Geronimo.
>
> IMHO, the problem lies with Geronimo, not with the interpretation.
>
>> (I'd also like to shove 1.1. out
>> the door...)
>
>> In the meantime, I propose the following interpretation of a +1 vote
>> to an RTC request:
>>
>> "I have reviewed (and possibly tested) this patch and found it good.
>> I understand the capability which the patch is adding and support the
>> direction in which it is taking the Geronimo project"
>
> No, that is inadequate.  RTC is not something to 'get around;'
> it's a fundamental way of progressing.  If something fails to
> garner three +1 votes, it means that there aren't three people
> who care enough about it for it to go into the code.  It's up
> to the person/people behind the item to drum up support for
> it.  It doesn't go in until three people have verified that
> it works acceptably.
>
> If that means things languish for weeks or months, then
> that's what it means.

Ken, I don't understand. How does my proposal 'get around' RTC? I  
haven't changed the requirement for three +1 votes. I'm trying to  
clarify what a +1 vote means. I think my interpretation is doing more  
to encourage communication within the community. I'd like to see some  
additional documentation requirements and guidelines be added to the  
RTC process to further encourage community communication. I assume  
that these changes would be determined by community vote? Or are all  
aspects of RTC under your jurisdiction?

BTW, I'm not the only one who disagrees with your 'patched and  
tested' interpretation. On May 24, 2006 3:53:23 PM EDT, Greg Stein  
commented in the original "Change to commit model for Apache  
Geronimo" thread:

> IMO #2, I disagree with Ken's "patched in and tested" ... there are  
> many
> changes that I've reviewed which I can give a +1 on just from  
> eyeballing
> it. Or provide feedback on what needs to change. IOW, I don't  
> always need
> a computer to tell me what it does. So I think it may be important to
> request that Ken officially relaxes that requirement a bit :-)

--kevan

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevan Miller wrote:
> 
> In Ken's announcement of the change to the commit model, he stated  
> that a +1 to an RTC request means "I have applied this patch and  
> tested it and found it good". Although a relaxation of this  
> interpretation has been suggested (or mentioned), to my knowledge  
> nothing has actually changed.

Correct.

> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not more  
> committers interested in these areas of Geronimo is an acknowledged  
> issue. However, it's unlikely that current Geronimo committers want  
> to be intimately familiar with some of these Geronimo components --  
> we've all had our chance to get involved, so far, but have chosen not  
> to.

Noted.

> That's a specific problem with the current process. However, I think  
> there's a general problem with this interpretation for all areas of  
> Geronimo.

IMHO, the problem lies with Geronimo, not with the interpretation.

> (I'd also like to shove 1.1. out  
> the door...)

> In the meantime, I propose the following interpretation of a +1 vote  
> to an RTC request:
> 
> "I have reviewed (and possibly tested) this patch and found it good.  
> I understand the capability which the patch is adding and support the  
> direction in which it is taking the Geronimo project"

No, that is inadequate.  RTC is not something to 'get around;'
it's a fundamental way of progressing.  If something fails to
garner three +1 votes, it means that there aren't three people
who care enough about it for it to go into the code.  It's up
to the person/people behind the item to drum up support for
it.  It doesn't go in until three people have verified that
it works acceptably.

If that means things languish for weeks or months, then
that's what it means.
- --
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJQQBJrNPMCpn3XdAQJCkgQAkoEFFBOGSCMeIMyhBYfc/w1jGKg0a+ri
2/ZlF9aU/X28K59vJUzrhU0JrMPegSKFoT2oyDmffqtUIqle8ap4hX+dTH4a8Tye
Qke4Bi+IngKgkBmjHdqDZ1W1bt1M5nmvBCNEN+aF7ZeQ9Ey9/4vc4Pw6eFv5w/VQ
FwH/0wNiwU4=
=7jv1
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One way to compare CTR and RTC to each other:

o With CTR, the focus is on getting things done.
o With RTC, the focus is on getting things done *well*
  and doing it together.
- --
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJQ6BJrNPMCpn3XdAQIYLQQAmbGbkw4FuCVX4Y+PVtD/9jvNkH3Q/h4I
XejcFhmbcxvgGGk2j7jrejZuVA/ugGrkJOXSXknekfPfFtFss0EFGBzovJGAhJr1
1xAzmrY3v/2Frv4vDVfc2TFLTUCzc/Gi6P+6v+wc1oO9WtVe0MsvW8jsf12nM6ei
Ehg06LWXbp0=
=IRdb
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[John Sisson <jr...@gmail.com>]

+1

See inline ..

Kevan Miller wrote:
> I'd like to request a change to the RTC process being used by Geronimo 
> (or at least I'm requesting a relaxation of Ken's interpretation of 
> the RTC process).
>
> In Ken's announcement of the change to the commit model, he stated 
> that a +1 to an RTC request means "I have applied this patch and 
> tested it and found it good". Although a relaxation of this 
> interpretation has been suggested (or mentioned), to my knowledge 
> nothing has actually changed.
>
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and 
> difficult task for most committers. The fact that there are not more 
> committers interested in these areas of Geronimo is an acknowledged 
> issue. However, it's unlikely that current Geronimo committers want to 
> be intimately familiar with some of these Geronimo components -- we've 
> all had our chance to get involved, so far, but have chosen not to.
>
> That's a specific problem with the current process. However, I think 
> there's a general problem with this interpretation for all areas of 
> Geronimo. IMO, this interpretation is not really helping to address 
> the fundamental problems/concerns which have prompted the move to RTC. 
> IMO, these concerns are that 1) some enhancements are not being 
> properly communicated with the Geronimo community, 2) too many 
> discussions/debates are occurring on private channels, and 3) some 
> people are being intimidated to remain silent on some public discussions.
>
> I'd like to see some specific RTC guidelines created for Geronimo. I'm 
> sure other projects must have already crafted similar guidelines. So, 
> I'd like to take a look at those, before spending too much time on 
> creating guidelines from scratch (I'd also like to shove 1.1. out the 
> door...)
>
It also isn't clear whether the required 3 positive votes for the 
current RTC process are only binding if they are from the PMC.  I think 
that would create a bottleneck considering the current size of the PMC.

In http://www.apache.org/foundation/voting.html it says "Only votes by 
PMC members are considered binding on code-modification issues", but I 
think we should develop our own guidelines that formalizes who can vote 
on code changes.  For example, http://xml.apache.org/decisions.html has 
their own policy on voting.

John
> In the meantime, I propose the following interpretation of a +1 vote 
> to an RTC request:
>
> "I have reviewed (and possibly tested) this patch and found it good. I 
> understand the capability which the patch is adding and support the 
> direction in which it is taking the Geronimo project"
>
> Comments and suggestions are, of course, welcome...
>
> --kevan
>
>
>
>

Re: Request change to RTC Process

[Paul McMahan <pa...@gmail.com>]

+1

On 6/3/06, Kevan Miller <ke...@gmail.com> wrote:
> I'd like to request a change to the RTC process being used by
> Geronimo (or at least I'm requesting a relaxation of Ken's
> interpretation of the RTC process).
>
> In Ken's announcement of the change to the commit model, he stated
> that a +1 to an RTC request means "I have applied this patch and
> tested it and found it good". Although a relaxation of this
> interpretation has been suggested (or mentioned), to my knowledge
> nothing has actually changed.
>
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and
> difficult task for most committers. The fact that there are not more
> committers interested in these areas of Geronimo is an acknowledged
> issue. However, it's unlikely that current Geronimo committers want
> to be intimately familiar with some of these Geronimo components --
> we've all had our chance to get involved, so far, but have chosen not
> to.
>
> That's a specific problem with the current process. However, I think
> there's a general problem with this interpretation for all areas of
> Geronimo. IMO, this interpretation is not really helping to address
> the fundamental problems/concerns which have prompted the move to
> RTC. IMO, these concerns are that 1) some enhancements are not being
> properly communicated with the Geronimo community, 2) too many
> discussions/debates are occurring on private channels, and 3) some
> people are being intimidated to remain silent on some public
> discussions.
>
> I'd like to see some specific RTC guidelines created for Geronimo.
> I'm sure other projects must have already crafted similar guidelines.
> So, I'd like to take a look at those, before spending too much time
> on creating guidelines from scratch (I'd also like to shove 1.1. out
> the door...)
>
> In the meantime, I propose the following interpretation of a +1 vote
> to an RTC request:
>
> "I have reviewed (and possibly tested) this patch and found it good.
> I understand the capability which the patch is adding and support the
> direction in which it is taking the Geronimo project"
>
> Comments and suggestions are, of course, welcome...
>
> --kevan
>
>
>
>

Re: Request change to RTC Process

[Kevan Miller <ke...@gmail.com>]

On Jun 3, 2006, at 11:25 AM, Sachin Patel wrote:

>
> On Jun 3, 2006, at 8:14 AM, Kevan Miller wrote:
>
>> However, it's unlikely that current Geronimo committers want to be  
>> intimately familiar with some of these Geronimo components --  
>> we've all had our chance to get involved, so far, but have chosen  
>> not to.
>
> Its very unfortunate that everyone is thinking this way.  After  
> some pondering this morning, this statement really bothers me.   
> These smaller components are extremely important to the success of  
> and future growth of the community.  When people see Geronimo, they  
> don't see the runtime, but the things that reflect its image are  
> things like the product documentation, the website, tooling and the  
> console.  Thus people's focus on only these runtime components will  
> have a negative bearing on the project.  The attitude needs to be  
> for each of us, that we make more of an effort in the future to get  
> involved in these areas.  If that means that we have to put less  
> function in primary components in order to spend time to grow these  
> areas, then so be it.

I don't know that everyone is thinking this way -- it's only my  
observation and I may be wrong. I also don't think this is  
necessarily unfortunate. I'd much rather have people working in areas  
that they are interested in/good at. I think we'd be better off  
attracting new community members, rather than asking existing members  
to refocus their efforts.

I agree with you that many of these components are important and  
vital to Geronimo. I agree that we as a community should strive to  
have a focus on our users. I think we should all be aware of what  
tasks are required of our users and what problems they face. I don't  
think that this means we should all start programming in devtools...

I think the point you are raising is how do we grow and broaden  
community participation especially in select Geronimo components--  
not what is the appropriate Geronimo RTC policy. I think that's a  
separate subject and invite you to start a discussion on this point.

--kevan

Re: Request change to RTC Process

[Sachin Patel <sp...@gmail.com>]

On Jun 3, 2006, at 8:14 AM, Kevan Miller wrote:

> However, it's unlikely that current Geronimo committers want to be  
> intimately familiar with some of these Geronimo components -- we've  
> all had our chance to get involved, so far, but have chosen not to.

Its very unfortunate that everyone is thinking this way.  After some  
pondering this morning, this statement really bothers me.  These  
smaller components are extremely important to the success of and  
future growth of the community.  When people see Geronimo, they don't  
see the runtime, but the things that reflect its image are things  
like the product documentation, the website, tooling and the  
console.  Thus people's focus on only these runtime components will  
have a negative bearing on the project.  The attitude needs to be for  
each of us, that we make more of an effort in the future to get  
involved in these areas.  If that means that we have to put less  
function in primary components in order to spend time to grow these  
areas, then so be it.

-sachin

Re: Request change to RTC Process

["Alan D. Cabrera" <li...@toolazydogs.com>]

Gianny Damour wrote:
> Rodent of Unusual Size wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Jacek Laskowski wrote:
>>  
>>
>>> Let's take this as an example. As we haven't discussed it yet, it
>>> seems to me that such a change requires 3x+1 from PMC members. So,
>>> only when this vote (it should possibly be a separate vote with
>>> 72-hour vote period to bring more attention) passes committers who are
>>> not PMC members have their +1 binding. Am I correct?
>>>   
>>
>> No.  Only PMC votes are binding.  There is only an issue here
>> because the PMC != committers.  I think the most desirable
>> solution is PMC === committers, but other people on the PMC
>> disagree.
>>  
>>
> Indeed, I disagree and I would like have this rule relaxed in the case 
> of RTC votes.
>
> I think that one of the main goals of RTC is to encourage discussion 
> of code changes and have a more collaborative development process. I 
> do not see how this restriction (only PMC votes are binding) promotes 
> further collaborative development.
>
> Having said that, this change to RTC is a very nice change as it is 
> now easier to follow what people are working on and more people can 
> get involved and contribute.
>
> Ken, could you please tell us if it is possible to relax the RTC rule? 
> If this is not possible, then is it possible to relax the 
> pre-requisites to be able to vote? For instance, I had a look to David 
> J. JACC patch; I am fine with it; however, I have not applied and 
> tested it; so, I cannot vote.

I've finally gotten through my email pile.  Did Ken ever reply to this 
email?


Regards,
Alan

Re: Request change to RTC Process

[Gianny Damour <gi...@optusnet.com.au>]

Rodent of Unusual Size wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Jacek Laskowski wrote:
>  
>
>>Let's take this as an example. As we haven't discussed it yet, it
>>seems to me that such a change requires 3x+1 from PMC members. So,
>>only when this vote (it should possibly be a separate vote with
>>72-hour vote period to bring more attention) passes committers who are
>>not PMC members have their +1 binding. Am I correct?
>>    
>>
>
>No.  Only PMC votes are binding.  There is only an issue here
>because the PMC != committers.  I think the most desirable
>solution is PMC === committers, but other people on the PMC
>disagree.
>  
>
Indeed, I disagree and I would like have this rule relaxed in the case 
of RTC votes.

I think that one of the main goals of RTC is to encourage discussion of 
code changes and have a more collaborative development process. I do not 
see how this restriction (only PMC votes are binding) promotes further 
collaborative development.

Having said that, this change to RTC is a very nice change as it is now 
easier to follow what people are working on and more people can get 
involved and contribute.

Ken, could you please tell us if it is possible to relax the RTC rule? 
If this is not possible, then is it possible to relax the pre-requisites 
to be able to vote? For instance, I had a look to David J. JACC patch; I 
am fine with it; however, I have not applied and tested it; so, I cannot 
vote.

Thanks,
Gianny

>- --
>#ken	P-|}
>
>Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
>Author, developer, opinionist      http://Apache-Server.Com/
>
>"Millennium hand and shrimp!"
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iQCVAwUBRJVk7prNPMCpn3XdAQIn3gQAlrUGNSNUZomw99D6efCrF2vGysX7lFVf
>OXGXMBcygerrUCoT7ldp0nylh18FDDiiYWoTzzAxsTWjYodwjUGVrbTX6Q/3o+hF
>Q+liFMYqo5p46kI2DZdbz8T//s/MsztCt9JC/zmAu5oYfQZtOpRe/t/aaJcie6Dy
>gCuDNpG/X4Y=
>=SBLj
>-----END PGP SIGNATURE-----
>
>
>  
>

Re: Request change to RTC Process

[Rodent of Unusual Size <Ke...@Golux.Com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jacek Laskowski wrote:
> 
> Let's take this as an example. As we haven't discussed it yet, it
> seems to me that such a change requires 3x+1 from PMC members. So,
> only when this vote (it should possibly be a separate vote with
> 72-hour vote period to bring more attention) passes committers who are
> not PMC members have their +1 binding. Am I correct?

No.  Only PMC votes are binding.  There is only an issue here
because the PMC != committers.  I think the most desirable
solution is PMC === committers, but other people on the PMC
disagree.
- --
#ken	P-|}

Ken Coar, Sanagendamgagwedweinini  http://Ken.Coar.Org/
Author, developer, opinionist      http://Apache-Server.Com/

"Millennium hand and shrimp!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRJVk7prNPMCpn3XdAQIn3gQAlrUGNSNUZomw99D6efCrF2vGysX7lFVf
OXGXMBcygerrUCoT7ldp0nylh18FDDiiYWoTzzAxsTWjYodwjUGVrbTX6Q/3o+hF
Q+liFMYqo5p46kI2DZdbz8T//s/MsztCt9JC/zmAu5oYfQZtOpRe/t/aaJcie6Dy
gCuDNpG/X4Y=
=SBLj
-----END PGP SIGNATURE-----

Re: Request change to RTC Process

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/4/06, David Jencks <da...@yahoo.com> wrote:

> In addition I think we should go against the PMC-only rule from the voting
> document and allow +1 and -1 from non-pmc committers to count.

+1

Let's take this as an example. As we haven't discussed it yet, it
seems to me that such a change requires 3x+1 from PMC members. So,
only when this vote (it should possibly be a separate vote with
72-hour vote period to bring more attention) passes committers who are
not PMC members have their +1 binding. Am I correct? If so, one
binding vote is in and awaits other +1 binding votes to be in effect
before +1 from non-PMC members are binding.

> david jencks

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: Request change to RTC Process

[David Jencks <da...@yahoo.com>]

On Jun 3, 2006, at 5:14 AM, Kevan Miller wrote:

> I'd like to request a change to the RTC process being used by  
> Geronimo (or at least I'm requesting a relaxation of Ken's  
> interpretation of the RTC process).
>
> In Ken's announcement of the change to the commit model, he stated  
> that a +1 to an RTC request means "I have applied this patch and  
> tested it and found it good". Although a relaxation of this  
> interpretation has been suggested (or mentioned), to my knowledge  
> nothing has actually changed.
>
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not  
> more committers interested in these areas of Geronimo is an  
> acknowledged issue. However, it's unlikely that current Geronimo  
> committers want to be intimately familiar with some of these  
> Geronimo components -- we've all had our chance to get involved, so  
> far, but have chosen not to.
>
> That's a specific problem with the current process. However, I  
> think there's a general problem with this interpretation for all  
> areas of Geronimo. IMO, this interpretation is not really helping  
> to address the fundamental problems/concerns which have prompted  
> the move to RTC. IMO, these concerns are that 1) some enhancements  
> are not being properly communicated with the Geronimo community, 2)  
> too many discussions/debates are occurring on private channels, and  
> 3) some people are being intimidated to remain silent on some  
> public discussions.
>
> I'd like to see some specific RTC guidelines created for Geronimo.  
> I'm sure other projects must have already crafted similar  
> guidelines. So, I'd like to take a look at those, before spending  
> too much time on creating guidelines from scratch (I'd also like to  
> shove 1.1. out the door...)
>
> In the meantime, I propose the following interpretation of a +1  
> vote to an RTC request:
>
> "I have reviewed (and possibly tested) this patch and found it  
> good. I understand the capability which the patch is adding and  
> support the direction in which it is taking the Geronimo project"
>
> Comments and suggestions are, of course, welcome...

I thought Derby was using RTC since they have a policy of all changes  
going through Jira and achieving consensus before being applied.   
However they apparently believe they are CTR.  I reviewed a few  
changes in derby and the maximum review, for a major change that took  
6 months and 9 patch revisions was 2 reviewers.  (DERBY-326)

the derby commit process is described at http://wiki.apache.org/db- 
derby/DerbyCommitProcess

I'm having trouble finding any other apache projects that are RTC.  I  
did find this exchange from 2000: http://marc2.theaimsgroup.com/? 
t=96942591500015&r=1&w=2

The httpd guidelines at http://httpd.apache.org/dev/guidelines.html say:

Ideas must be review-then-commit; patches can be commit-then-review.  
With a commit-then-review process, we trust that the developer doing  
the commit has a high degree of confidence in the change. Doubtful  
changes, new features, and large-scale overhauls need to be discussed  
before being committed to a repository. Any change that affects the  
semantics of arguments to configurable directives, significantly adds  
to the runtime size of the program, or changes the semantics of an  
existing API function must receive consensus approval on the mailing  
list before being committed. (continues, but mostly on other subjects).

I also see that according to: http://www.apache.org/foundation/ 
voting.html

Votes on code modifications follow a different model. In this  
scenario, a negative vote constitutes a veto, which cannot be  
overridden. Again, this model may be modified by a lazy consensus   
declaration when the request for a vote is raised, but the full-stop  
nature of a negative vote is unchanged. Under normal (non-lazy  
consensus) conditions, the proposal requires three positive votes and  
no negative ones in order to pass; if it fails to garner the  
requisite amount of support, it doesn't -- and typically is either  
withdrawn, modified, or simply allowed to languish as an open issue  
until someone gets around to removing it.

...
  Binding Votes

Who is permitted to vote is, to some extent, a community-specific  
thing. However, the basic rule is that only PMC members have binding  
votes, and all others are either discouraged from voting (to keep the  
noise down) or else have their votes considered of an indicative or  
advisory nature only.

That's the general rule. In actual fact, things tend to be a little  
looser, and procedural votes from developers and committers are  
sometimes considered binding if the voter has acquired enough merit  
and respect in the community. Only votes by PMC members are  
considered binding on code-modification issues, however.
Implications of Voting

...
If the R-T-C policy is in effect, a positive vote carries the very  
strong implied message, 'I have tested this patch myself, and found  
it good.' Similarly, a negative vote usually means that the patch was  
tested and found to be not-good, although the veto (for such it is in  
this case) may be based on other technical grounds.

----
This appears to mean that there's no point in non-pmc members voting  
on patches since their votes are considered noise and in any case are  
not binding.

I think that's all the research I want to do today on this subject.

------

Sachin objected to the comment that it was ok for no one but him to  
ever look at the devtools code.  I agree with Sachin's objection.  I  
think all the subsidiary projects need the attention of more than one  
developer.  Requiring this will I think make us a stronger project.

In any case:

+1 to Kevan's suggested meaning of a +1 vote

In addition I think we should go against the PMC-only rule from the  
voting document and allow +1 and -1 from non-pmc committers to count.

thanks
david jencks





>
> --kevan
>
>
>

Re: Request change to RTC Process

[Jan Bartel <ja...@mortbay.com>]

+1 to the suggested meaning of +1 votes
+1 to the suggestion of *all* committers voting


regards
Jan

Kevan Miller wrote:
> I'd like to request a change to the RTC process being used by  Geronimo 
> (or at least I'm requesting a relaxation of Ken's  interpretation of the 
> RTC process).
> 
> In Ken's announcement of the change to the commit model, he stated  that 
> a +1 to an RTC request means "I have applied this patch and  tested it 
> and found it good". Although a relaxation of this  interpretation has 
> been suggested (or mentioned), to my knowledge  nothing has actually 
> changed.
> 
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not more  
> committers interested in these areas of Geronimo is an acknowledged  
> issue. However, it's unlikely that current Geronimo committers want  to 
> be intimately familiar with some of these Geronimo components --  we've 
> all had our chance to get involved, so far, but have chosen not  to.
> 
> That's a specific problem with the current process. However, I think  
> there's a general problem with this interpretation for all areas of  
> Geronimo. IMO, this interpretation is not really helping to address  the 
> fundamental problems/concerns which have prompted the move to  RTC. IMO, 
> these concerns are that 1) some enhancements are not being  properly 
> communicated with the Geronimo community, 2) too many  
> discussions/debates are occurring on private channels, and 3) some  
> people are being intimidated to remain silent on some public  discussions.
> 
> I'd like to see some specific RTC guidelines created for Geronimo.  I'm 
> sure other projects must have already crafted similar guidelines.  So, 
> I'd like to take a look at those, before spending too much time  on 
> creating guidelines from scratch (I'd also like to shove 1.1. out  the 
> door...)
> 
> In the meantime, I propose the following interpretation of a +1 vote  to 
> an RTC request:
> 
> "I have reviewed (and possibly tested) this patch and found it good.  I 
> understand the capability which the patch is adding and support the  
> direction in which it is taking the Geronimo project"
> 
> Comments and suggestions are, of course, welcome...
> 
> --kevan
> 
> 
> 
> 

Re: Request change to RTC Process

[Sachin Patel <sp...@gmail.com>]

+1

On Jun 3, 2006, at 8:14 AM, Kevan Miller wrote:

> I'd like to request a change to the RTC process being used by  
> Geronimo (or at least I'm requesting a relaxation of Ken's  
> interpretation of the RTC process).
>
> In Ken's announcement of the change to the commit model, he stated  
> that a +1 to an RTC request means "I have applied this patch and  
> tested it and found it good". Although a relaxation of this  
> interpretation has been suggested (or mentioned), to my knowledge  
> nothing has actually changed.
>
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not  
> more committers interested in these areas of Geronimo is an  
> acknowledged issue. However, it's unlikely that current Geronimo  
> committers want to be intimately familiar with some of these  
> Geronimo components -- we've all had our chance to get involved, so  
> far, but have chosen not to.
>
> That's a specific problem with the current process. However, I  
> think there's a general problem with this interpretation for all  
> areas of Geronimo. IMO, this interpretation is not really helping  
> to address the fundamental problems/concerns which have prompted  
> the move to RTC. IMO, these concerns are that 1) some enhancements  
> are not being properly communicated with the Geronimo community, 2)  
> too many discussions/debates are occurring on private channels, and  
> 3) some people are being intimidated to remain silent on some  
> public discussions.
>
> I'd like to see some specific RTC guidelines created for Geronimo.  
> I'm sure other projects must have already crafted similar  
> guidelines. So, I'd like to take a look at those, before spending  
> too much time on creating guidelines from scratch (I'd also like to  
> shove 1.1. out the door...)
>
> In the meantime, I propose the following interpretation of a +1  
> vote to an RTC request:
>
> "I have reviewed (and possibly tested) this patch and found it  
> good. I understand the capability which the patch is adding and  
> support the direction in which it is taking the Geronimo project"
>
> Comments and suggestions are, of course, welcome...
>
> --kevan
>
>
>


-sachin

Re: Request change to RTC Process

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/3/06, Kevan Miller <ke...@gmail.com> wrote:

> "I have reviewed (and possibly tested) this patch and found it good.
> I understand the capability which the patch is adding and support the
> direction in which it is taking the Geronimo project"

+1

Very well said. The truth as I understand it is that everybody's
responsible for his/her votes so if one says +1 it's assumed (s)he's
aware of the consequences. In case of committers or PMCers it's even
more visible that they *do* need to understand the consequences. It
shouldn't be any doubt if a change should be applied or not and the
way one gets to that point is hir (=his/her) own method.

> --kevan

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: Request change to RTC Process

[anita kulshreshtha <a_...@yahoo.com>]

+1
Cheers
Anita

--- Kevan Miller <ke...@gmail.com> wrote:

> I'd like to request a change to the RTC process being used by  
> Geronimo (or at least I'm requesting a relaxation of Ken's  
> interpretation of the RTC process).
> 
> In Ken's announcement of the change to the commit model, he stated  
> that a +1 to an RTC request means "I have applied this patch and  
> tested it and found it good". Although a relaxation of this  
> interpretation has been suggested (or mentioned), to my knowledge  
> nothing has actually changed.
> 
> In some areas of Geronimo (e.g. devtools), this is a cumbersome and  
> difficult task for most committers. The fact that there are not more 
> 
> committers interested in these areas of Geronimo is an acknowledged  
> issue. However, it's unlikely that current Geronimo committers want  
> to be intimately familiar with some of these Geronimo components --  
> we've all had our chance to get involved, so far, but have chosen not
>  
> to.
> 
> That's a specific problem with the current process. However, I think 
> 
> there's a general problem with this interpretation for all areas of  
> Geronimo. IMO, this interpretation is not really helping to address  
> the fundamental problems/concerns which have prompted the move to  
> RTC. IMO, these concerns are that 1) some enhancements are not being 
> 
> properly communicated with the Geronimo community, 2) too many  
> discussions/debates are occurring on private channels, and 3) some  
> people are being intimidated to remain silent on some public  
> discussions.
> 
> I'd like to see some specific RTC guidelines created for Geronimo.  
> I'm sure other projects must have already crafted similar guidelines.
>  
> So, I'd like to take a look at those, before spending too much time  
> on creating guidelines from scratch (I'd also like to shove 1.1. out 
> 
> the door...)
> 
> In the meantime, I propose the following interpretation of a +1 vote 
> 
> to an RTC request:
> 
> "I have reviewed (and possibly tested) this patch and found it good. 
> 
> I understand the capability which the patch is adding and support the
>  
> direction in which it is taking the Geronimo project"
> 
> Comments and suggestions are, of course, welcome...
> 
> --kevan
> 
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com