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 Sun, 02 Jul 2006 00:44:47 GMT
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) 
>> 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.

> --jason

View raw message