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?
JIRA is not a discussion forum... maybe it should have that feature,
but it doesn't. I agree that the major details and comments should
be captured in the issue, but I do not believe that the issue should
be used to facilitate discussion.
Use email, and if needed attach a link to the Nabble archive for the
relevant conversations.
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.
Generally I think that every issue should have a description. Not
really much point in creating an issue that does not have one...
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.
I generally don't believe that we want to minimize (or even reduce)
IRC usage. It is a great tool that helps our community greatly by
facilitating some aspects of communication.
I do agree though, that we need to be sure that the relevant details
make it back to the dev list. In many ways I see that IRC is good to
help facilitate the exchange of ideas that in the end will help build
up a more comprehensive and thoughtful email to the dev list.
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?
NOTE: Once we get all [RTC] in JIRA, then it should be much easier to
track which issues are out there pending and which are growing stale.
IMO the important thing is that those who actually have binding votes
be very diligent about working through the open RTC's so that we
don't loose anything by having those issues go stale... or turn
people off by the slow turn around of accepting their patch... and to
avoid unneeded slowness that will incur when work is done, but
pending finalization by RTC which is blocking future work... forcing
one to be idle and wait for the RTC to go through.
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 :-)
Well, lets all have a good cheer that we are not using VSS.
But, IMO it is more than just needing a separate tree (and probably
IDE config, etc)... but more that folks need to context switch all
over different parts of the system which they many not be experts
in. This context switching is harmful to the progress in areas of
the developers expertise... since they need to stop what they are
doing, setup a clean room, apply some patches, understand what it is
doing, etc.
I forget who said it on the list, but there are also trust issues
going on here. I trust other developers who are domain experts in
certain areas to frankly know their shit. I do like to check what
they are doing from time to time, but I certainly don't have time or
energy to become domain experts in every domain (I think I might
spontaneously combust if I tried).
I hope that we can in time reestablish this trust across the entire
community. With out that trust I think we are just going to be
spinning our wheels... or just end up screwing ourselves (and not in
any good way).
* The code in svn should always build.
Amen!
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.
Well, that happens from time to time... and probably will continue to
do so until everyone shares one single massive google filesystem for
everything :-(
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.
Well, that is probably also going to continue from time to time.
Hopefully we can reduce this, but... well not sure its possible to
completely eliminate... unless everyone moves to California (the
weather is nice) :-P
--jason
