geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: [RTC] Clarification please from the PMC
Date Sat, 01 Jul 2006 01:55:47 GMT
Jason Dillon wrote:
> NOTE: My comments below are not directed towards anyone in 
> particular... mostly this just expresses my frustration with some of 
> the more harmful politics that Apache Geronimo has picked up over the 
> past few months...
>> Although RTC has slowed down development a bit (or even more), it 
>> will pay off very
>> soon.
> I think "slowed down development a bit (or even more)" is an 
> understatement.  I believe that RTC has the development team running 
> through molasses.  And in some cases has caused some patches and 
> issues to get stuck in the tar.  Not really the types of things you 
> want from a vibrant, active and positive community.
I agree development has slowed down and there were good reasons why RTC 
was introduced, so lets try to find ways of working more effectively 
with it.
>> We need to be very patient until more committers become PMC
>> members and their votes are binding.
I have similar frustrations with what Jacek said regarding with the 
limited amount of spare time I have. The spare time I had was focused on 
the oversight of the 1.1 release.  Now that 1.1 is out the door I will 
try to get more involved in the RTC process.  Hopefully this will become 
less of an issue when the PMC grows.

Some of the issues I currently see with the way we are working the 
process (and some related issues) are:

1. Hard to tell what fixes are pending review. 

*Action* I have started a new thread "[Proposal] Tracking the status of 
patches under RTC (was Re: [RTC] Clarification please from the PMC)" to 
discuss this.

2. Not all communication regarding the fix is done in JIRA comments, 
therefore people reviewing the fix have to search the mailing lists and 
JIRA reducing the amount of time they have to actually review the 
change.  This also makes it harder for people in the future who look up 
the JIRA and only see half the picture.

*Action* To prevent communication regarding patches under RTC being 
conducted outside of JIRA, I suggest that a combination of the previous 
suggestion and having "[RTC]" as the first characters of the JIRA 
summary should be sufficient ( no need to send a mail to the dev list, 
as it only encourages people to communicate on the dev list rather than 
in JIRA ).  When the JIRA is closed, the [RTC] characters can be removed 
from the summary to make it suitable for the release notes.  Comments?

3. There have been JIRAs for RTCs where in the mailing list they have 
been described as a major enhancement, yet the JIRA does not even have a 
description or comments.  The lack of information about the changes in 
the JIRA makes it harder for others to review.  Lack of information also 
means that it will be unlikely that the change will be identified as 
needing to be documented in the manuals and possibly migration 
information in the release notes.  Users picking up the next release 
will see the JIRA entry and start asking "What is this enhancement? "on 
the mailing list, adding to the load of everyone's inbox.

*Action* I will start a new mail thread "[DISCUSS] Tracking 
documentation tasks in JIRA ( was Re: [RTC] Clarification please from 
the PMC )".

4. The lack of progress may be exacerbated by a number of PMC members 
(myself included) being in different timezones where it is not always 
suitable to discuss patches over IRC due to  the need to sleep or other 
commitments :-)

*Action* We need to improve communication on mail lists and increase 
documentation in JIRAs and Wiki to minimize dependence on IRC.

5. The amount of spare time that PMC members can volunteer is finite and 
the amount of spare time available may vary from person to person due to 
their other commitments. 

* Action* Discussion of Priorities..
Do people feel all RTC's should have the same priority? If not, how 
would you justify one RTC request being more important than another?
Would it be fair to say some patches to be reviewed may be minor changes 
that wouldn't prevent the development community from moving forward if 
the review is postponed, whilst other patches may be needed by a number 
of developers and the RTC is impeding further development by the 
community?  Should we be considering prioritizing RTC requests?

It may seem like I am trying to introduce more red tape, but I think it 
will pay off in terms of improving communication regarding code changes 
and improve the end product.  I look forward to some constructive 
discussions.  I also think that developing agreed upon procedures that 
ensure documentation is part of the development process will also help 
the project operate more effectively in the long term.

> This will not remedy the fact that RTC rules dictate that patches must 
> be applied and tested before a +1 can be given, which normally would 
> have happened once when the *trusted* developer has applied the 
> patch.  But now we need a gang of people to apply the patch, which 
> usually means dropping any other work they were doing to get a clean 
> tree and then apply the patch, pray that the build succeeds in a 
> reasonable amount of time, running through a test case or two and then 
> blowing it all away to get back to the work that they were actually 
> doing before.
Regarding the "clean tree" issue.... You can have have Geronimo checked 
out in more than one directory, so have one directory for your main 
development and one (or more if needed) for reviewing patches.  You can 
even have separate maven local repositories if needed by specifying the 
appropriate maven properties on the command line.  It may take a bit of 
effort to get your environment set up to do this simply, but it would 
probably be worth it in the long run. Luckly we aren't using Visual 
SourceSafe that has the one checkout per user limitation :-)
> I fail to see how this will increase anything but frustration of 
> developers to have to jump through those hoops to get changes made.... 
> maybe it will increase communication about how frustrating RTC is 
> though ;-)
I agree that RTC for the incremental m1 -> m2 changes is painful and 
Matt's suggestion sounds reasonable to me.  Would like to hear Ken's 

Some of the benefits I see with developers having to jump through these 
hoops for significant changes are:

* Developers have to document what they are working on so others can 
test it.  I think it is a problem (for the project as a whole) when 
developers commit code where they (or a small group of developers on the 
project) are the only ones who understand how the code works and what it 
means to the end user, especially if that information is only in their 
heads.  If we want to become a "vibrant player in the app-server space" 
we need to do more than push out code.  We need to be able to grow the 
developer community, the user community also has to have faith in our 
processes and the software needs to be usable.  If documentation for the 
software is lacking then I don't think it is very usable (except for a 
minority of users who are developers on the project).  Hernan and those 
who have helped him getting the cwiki site going have set up a good 
foundation for the documentation and I thank them for their efforts.  We 
now need to start discussing how we can ensure documentation is part of 
the development process to maximize communication between developers and 
enable users to get the most out of Geronimo.

* The code in svn should always build. During the development of 1.0 and 
1.1 there were long periods of time where builds were broken due to 
people committing code without doing a build to test it.  In some cases 
the developer may have done a build and it was successful, but when they 
committed the changes, they accidentally left out a file from the 
commit.  There were a number of times where people broke the build in 
their last checkin when they were blurry-eyed and just about to head off 
to sleep.  Developers in other timezones then wasted time either 
debugging the problem, or waiting for the developer who checked in the 
change to wake up or trying to find a revision that does build. 

>> Painful, but in the end it might boost development significantly.
> How will this boost anything?
>> AFAIUI, the whole point of RTC is to ensure communication through
>> dev/user mailing lists rather than in closed circles.
> I don't understand how, dropping what I am working on, applying 
> patches, running tests and then coaxing the few PMC members with votes 
> will ensure more communication.  In may respects I think it actually 
> hinders communication, as people will just shy away from applying 
> changes or from proposing to make new changes.  RTC, IMO is the road 
> to complacency.
>>> It would seem to me that the process for RTC would be to send an RTC 
>>> about the Maven 1 -> 2
>>> conversion with some preliminary ideas.
> I'm confused now... how can one send a RTC w/o having a patch or 
> patches for others to review?
>  * * *
> RTC is crippling Apache Geronimo's ability to become a vibrant player 
> in the app-server space.  RTC has made us a Red Tape Community, where 
> it takes weeks to get trivial changes implemented.
> The problem is made worse by the fact that most of the PMC members who 
> we are supposed to coax into following RTC and voting in the changes 
> are simply not available.  Not all of them mind you, but out of 10 PMC 
> members I can only think of a few who have had time or desire to 
> participate in the RTC and actually give their binding votes.  IMO the 
> only way that RTC could possibly with is if the PMC members drop 
> anything else they are working on and devote their time to applying 
> patches, building and testing... BUT, I don't see that happening.  The 
> people who are actually doing the work are for the most part not PMC 
> members.  The people who are actually applying these patches are not 
> PMC members.  Lucky enough though, I think that there are at least 3 
> PMC members who are being active, so there is a shot for us to get 
> work done... its just going to be really slow moving.  At this rate, 
> maybe we will have EJB3 support out by the time that EJB4 is 
> dominant... or get out build working on m2 by the time m3 is out...
> :-\
> --jason

View raw message