Jason Dillon wrote:
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.
It may not have been clear, bud a mail to the list describing what they
plan to do, why the change is needed etc (this information should also
be in the JIRA description), so everyone is aware of what you are
working on and everyone has the opportunity to provide some input before
you spend a lot of time coding up the new feature. If there is
disagreement amongst developers about the feature you are working on,
then hot I was referring to communication once a JIRA has been marked
for RTC. I was imagining that when someone is working on a new feature
they will first create a JIRA for what they are working on and
senpefully those disagreements will be resolved before it moves to the
RTC phase (before everyone takes the time to build and test). Once it
moves into the RTC phase, I was suggesting all communication be in the
JIRA so it is easy to correlate votes and see the status of the RTC. I
have seen other projects use JIRA/Bugzilla's commenting feature more
heavily than we do without a problem.
Would be interested in hearing other's views on whether these sound like
reasonable guidelines.
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...
Agree there isn't much point, but it has happened, and I am thinking we
need to be more explicit in our guidelines (do we have any formal
guidelines?) of what is required to make a change. Not just that every
change should have a JIRA, but every change should have a JIRA and
adequate information in the JIRA for others to understand what the
change does, why it is needed, what the impact on users will be (if any)
etc.
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.
Agree that it is useful, but I have seen many questions asked a number
of times by different people relating to changes that were made in the
past where if it was documented in the first place, the questions
probably wouldn't needed to be asked (saving everyone time that can be
better spent writing code etc). I am trying to minimize the amount of
times people have to use IRC or email to ask about undocumented changes
that have been introduced.
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.
I agree with you that IRC is good for exchange of ideas (as long as it
makes it back 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).
Hopefully over time more people will become knowledgeable in some of
those domain expert areas. The chances of that happening are going to
increase if there is more communication and documentation.
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 :-(
Shouldn't happen under RTC since others test the changes.
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
Thanks for taking the time to discuss this.
John
--jason
