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
feelings.
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.
John
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
