geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: [RTC] Clarification please from the PMC
Date Sat, 01 Jul 2006 06:13:02 GMT
> 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.


> 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


View raw message