[RTC] Clarification please from the PMC

[Matt Hogstrom <ma...@hogstrom.org>]

There is a lot of work going on to migrate from Maven 1 to Maven 2 in our build.  A question came up 
as to whether or not we needed [RTC] for that activity.  Please read an excerpt from David's e-mail 
on the topic...

David Jencks wrote:
> AFAIK no one is planning to try to get 1.1 to build with m2.  I 
> certainly don't feel like I have time to deal with the RTC process for 
> something that requires zillions of trivial changes to get to work.
> 


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.   This type of activity is clearly incremental and highly 
disruptive in nature potentially so here is how it would work.

[RTC] M1 - M2 converstion e-mail sent to dev
Developers review the "plan" (as not all changes are known) and they reach consensus about the 
significant change.  They get they're +1s from the group and begin their work.

They continue their work posting status e-mails to the group but are not required to get 3 +1s on 
every change but only changes where it would warrant some input (like changing directory layouts, 
etc.)   Even these I see as informative and normal communication and not an [RTC] thread.

I believe the goal of RTC is to improve communication which in many instances it has.  In the spirit 
of RTC we could complete the Maven 1 -> 2 conversion without large numbers of RTCs required.

I think this is inline but would like your clarification.

Recently I think Jeff requested an RTC to update the committers page which I think falls outside of 
the RTC requirement so based on these two examples I believe there is still come confusion.

Cheers,

Matt

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

> David Jencks wrote:
>> AFAIK no one is planning to try to get 1.1 to build with m2.  I  
>> certainly don't feel like I have time to deal with the RTC process  
>> for something that requires zillions of trivial changes to get to  
>> work.

I think we should target the conversion for trunk, and after that is  
completed we can evaluate how much time/work is required to get 1.1  
onto m2, but IMO the goal should be to get trunk migrated.

--jason

Re: [RTC] Clarification please from the PMC

[Jeff Genender <jg...@apache.org>]

Jason Dillon wrote:
>>> Its a sad time when members of the community are scared to state their
>>> minds in fear of reprisal.
>>
>> Interesting comment, isn't this what started all of this to begin with?
> 
> I can't say... not really understanding all of the issues that led us to
> this situation.  I know of an event at JavaOne that appears to have been
> the boiling point, but I have also heard of other instances which have
> not been fully disclosed that have helped bring us to this situation.

I believe a quick perusal of the lists will show discussion regarding
intimidation.  I believe this fits in with your comment about folks in
the community being scared to speak their minds in fear of reprisal.

This exchange gives a bit of background:

http://tinyurl.com/jdv55

> 
> :-\
> 
> --jason

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

>> Its a sad time when members of the community are scared to state  
>> their
>> minds in fear of reprisal.
>
> Interesting comment, isn't this what started all of this to begin  
> with?

I can't say... not really understanding all of the issues that led us  
to this situation.  I know of an event at JavaOne that appears to  
have been the boiling point, but I have also heard of other instances  
which have not been fully disclosed that have helped bring us to this  
situation.

:-\

--jason

Re: [RTC] Clarification please from the PMC

[Jeff Genender <jg...@apache.org>]

Jason Dillon wrote:
> Its a sad time when members of the community are scared to state their
> minds in fear of reprisal.
> 

Interesting comment, isn't this what started all of this to begin with?

>  * * *
> 
> I was never very good at math... that is what calculators are for. :-P
> 
> --jason
> 
> 
> On Jun 29, 2006, at 2:17 PM, Aaron Mulder wrote:
> 
>> I'd like to +1 this, but I'm too scared to due to the political
>> ramifications.
>>
>> Yesterday, a PMC member told me that the only thing he could compare
>> Gernimo to was Avalon, where certain personalities were so destructive
>> that someone was kicked out of Apache altogether.
>>
>> You do the math.
>>
>> Thanks,
>>     Aaron
>>
>> On 6/29/06, Jason Dillon <ja...@planet57.com> 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.
>>>
>>>
>>> > We need to be very patient until more committers become PMC
>>> > members and their votes are binding.
>>>
>>> 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.
>>>
>>> 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 ;-)
>>>
>>>
>>> > 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
>>>

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

Its a sad time when members of the community are scared to state  
their minds in fear of reprisal.

  * * *

I was never very good at math... that is what calculators are for. :-P

--jason


On Jun 29, 2006, at 2:17 PM, Aaron Mulder wrote:

> I'd like to +1 this, but I'm too scared to due to the political  
> ramifications.
>
> Yesterday, a PMC member told me that the only thing he could compare
> Gernimo to was Avalon, where certain personalities were so destructive
> that someone was kicked out of Apache altogether.
>
> You do the math.
>
> Thanks,
>     Aaron
>
> On 6/29/06, Jason Dillon <ja...@planet57.com> 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.
>>
>>
>> > We need to be very patient until more committers become PMC
>> > members and their votes are binding.
>>
>> 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.
>>
>> 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 ;-)
>>
>>
>> > 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
>>

Re: [RTC] Clarification please from the PMC

[Aaron Mulder <am...@alumni.princeton.edu>]

I'd like to +1 this, but I'm too scared to due to the political ramifications.

Yesterday, a PMC member told me that the only thing he could compare
Gernimo to was Avalon, where certain personalities were so destructive
that someone was kicked out of Apache altogether.

You do the math.

Thanks,
     Aaron

On 6/29/06, Jason Dillon <ja...@planet57.com> 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.
>
>
> > We need to be very patient until more committers become PMC
> > members and their votes are binding.
>
> 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.
>
> 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 ;-)
>
>
> > 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
>

Re: [RTC] Clarification please from the PMC

[John Sisson <jr...@gmail.com>]

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
>

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

> 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

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

There was/is some bits on gbuild that is using Continuum... but I'm  
unsure at this time how trustworthy the setup is (ie. can we trust  
that a failure notice is really something broke or just something  
transient).

Once the m2 build is square we should get a concrete CI setup to help  
avoid future periods of build breakage.

--jason


On Jul 1, 2006, at 2:05 PM, Bryan Noll wrote:

>
>
> John Sisson wrote:
>> * 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
> This seems like a fairly fixable thing, right?  Some kind of  
> Continuous Integration for the project... Cruise Control or  
> whatever?  I noticed these JIRA's awhile back...
>
> http://issues.apache.org/jira/browse/GERONIMO-301
> http://issues.apache.org/jira/browse/GERONIMO-302
> http://issues.apache.org/jira/browse/GERONIMO-303
> http://issues.apache.org/jira/browse/GERONIMO-304
>
> I don't know the details, but it seems like I've seen communication  
> either here or on the IRC about some kind of CI stuff... thinking  
> Blevins has worked on that stuff if I remember right.  If that's  
> true, it's unclear to me what is currently happening in terms of CI  
> (anything?), and what yet needs to happen.
> So, could anyone here in the know please clarify that?
>
> Also, once I understand a bit better about what needs to be done  
> yet, I would be glad to help get it going.
>
>
> Thanks,
>
> Bryan
>

Re: [RTC] Clarification please from the PMC

[Bryan Noll <bw...@gmail.com>]

John Sisson wrote:
> * 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
This seems like a fairly fixable thing, right?  Some kind of Continuous 
Integration for the project... Cruise Control or whatever?  I noticed 
these JIRA's awhile back...

http://issues.apache.org/jira/browse/GERONIMO-301
http://issues.apache.org/jira/browse/GERONIMO-302
http://issues.apache.org/jira/browse/GERONIMO-303
http://issues.apache.org/jira/browse/GERONIMO-304

I don't know the details, but it seems like I've seen communication 
either here or on the IRC about some kind of CI stuff... thinking 
Blevins has worked on that stuff if I remember right.  If that's true, 
it's unclear to me what is currently happening in terms of CI 
(anything?), and what yet needs to happen. 

So, could anyone here in the know please clarify that?

Also, once I understand a bit better about what needs to be done yet, I 
would be glad to help get it going.


Thanks,

Bryan

Re: [RTC] Clarification please from the PMC

[John Sisson <jr...@gmail.com>]

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
>

Re: [RTC] Clarification please from the PMC

["Alan D. Cabrera" <li...@toolazydogs.com>]

This reflects my sentiments as well.


Regards,
Alan


Matt Hogstrom wrote:
>
>
> Jason Dillon wrote:
>>> I second your opinions, but that's how we operate and I can't do much
>>> regarding this matter other than to spare some time and vote at least.
>>> I think I'm not alone thinking that RTC is very painful, but some see
>>> it as a remedy of our troublesome happenings in the past. We'll see
>>> how it work out. The only thing I can do is to do my best to speed it
>>> up a bit and be more active in RTCs (given my manager doesn't get me
>>> swamped with other daily tasks that took me away for the past weeks).
>>> Not mentioning there're lots of bugs reported.
>>
>> I think that if the Apache Geronimo community is actually 
>> self-governing as I believed it was, then there is something that can 
>> be done about this.
>>
>> You are definitely not alone in thinking that RTC is painful (and 
>> non-functional I would like to add).
>>
>>
>>>> I'm confused now... how can one send a RTC w/o having a patch or
>>>> patches for others to review?
>>>
>>> Yes, you might've been confused as it's Matt's statement nor mine and
>>> thus the origin of your confusion, isn't it?
>>
>> Honestly... I don't know... but I am confused ;-)
>>
>
> My point was that for very complicated changes like M1 -> M2 a note 
> outlining the proposed action should not require a fully baked patch.  
> Perhaps I misstated.
>
>>
>>> I have never been as active in open source projects (Apache Geronimo
>>> and OpenEJB in particular) as I should've been. I haven't been able to
>>> manage my daily workload wisely and  spare more time to work on these
>>> OSSes at nights. At this point I'm completely overwhelmed with other
>>> stuff meaning I don't have as much time as is required from me to
>>> contribute.
>>
>> It happens... which is why we have a community of developers to help 
>> pick up the slack.  Unfortunately some decisions have been made which 
>> limit the abilities of the bulk of the community and force the 
>> minorities to play a much bigger part, which unfortunately most have 
>> not stepped up to do.
>>
> Jason, RTC was implemented because the PMC chair and the Board felt 
> that the G community was not functioning in an open fashion.  I don't 
> want to repeat that whole debate as its been debated and nothing 
> positive will come from rehashing it.
>
> RTC has improved communications I think is achieving its desired 
> effect.  Yes, the side effect is slowing down some development.  I 
> know its frustrating but if we work well together through the process 
> changes (RTC) we will be moving back to CTR.  Complaining about RTC 
> won't get us there. Yes, we're all frustrated and we all will get 
> through this working together.
>
>>
>>> I see it as a threat to me being a PMC member. Do you
>>> think I should step down having failed so often?
>>
>> Not at all.  I don't believe that you should step down at all.  You 
>> are one of the few PMC folks that is actually trying to keep up with 
>> the RTC and I certainly don't want to see those numbers reduced.
>>
>> As I mentioned before, I was not aiming my comments at anyone in 
>> particular.  I have just been quietly ignoring the situation for 
>> sometime, and feel that I can not do that anymore... it is not in my 
>> nature.
>>
> I agree that Jacek is doing great.  Collectively we all make this work 
> and all contributions great and small move us forward.
>>
>>> I remember having discussion about a distinction between a committer 
>>> and PMC member. Some believed there's none.
>>
>> I'm not sure that there is (or should be) much difference.
>>
>>
>>> It's not my decision to activate RTC, which as far as I understand has
>>> never proven itself to be successful, but that's reality we need to 
>>> live in.
>>
>> If our community is self-governing and the bulk of the community is 
>> in opposition to this rule, why then does that community need to live 
>> with it?
>>
> See above about the Board and PMCs perspective of our community dynamics.
>> BTW, that is my opinion... I have not performed any poll to see which 
>> parts of our community actually is in favor of RTC.  I would suggest 
>> that most folks agree that improved and more frequent communication 
>> is desired... but I also suggest that RTC in its current incarnation 
>> is NOT the best way to achieve those goals.
> Its moved us back from where we were at.  Certainly past where we 
> should be but I'm optimistic that we'll move back to the center.
>>
>>
>>> I believe, though, that it won't kill the project, but strengthen.
>>
>> That all depends on how long it goes not for...
>>
>> IMO, the longer it does, the more chances are that the end-result 
>> will be a more and more defunct community.
>>
>>  * * *
>>
>> Thanks for taking the time to respond.  I apologize if my comments 
>> stir your frustration... but I felt and fell like I have to say 
>> something, to play my part in this community.
>>
>> --jason
>>
>>
>>
>>

Re: [RTC] Clarification please from the PMC

[Jeff Genender <jg...@apache.org>]

Jason Dillon wrote:
> Guys, I feel like I am allowed to state my opinions.
> 
> I am not complaining (and a bit insulted that you think I am), but I
> believe that RTC is harmful for a few reasons.
> 
> I also feel like some responses to mails I have sent are basically that
> I should shut-up (my words), which I do not appreciate.
> 

Of course you have a right to speak your opinions, and they are
welcomed. The key really becomes how constructive they are.  Clearly RTC
is a PITA.  But it also was heavily needed to right ourselves from a
collaboration and communication perspective.  IMHO, I think it has been
successful, and once we have shown that we are working together better
as a team, I am sure we will be able to move back to CTS.

> :-(
> 
> --jason
> 
> 
> On Jun 30, 2006, at 5:35 AM, Matt Hogstrom wrote:
> 
>> Jason Dillon wrote:
>>>> I second your opinions, but that's how we operate and I can't do much
>>>> regarding this matter other than to spare some time and vote at least.
>>>> I think I'm not alone thinking that RTC is very painful, but some see
>>>> it as a remedy of our troublesome happenings in the past. We'll see
>>>> how it work out. The only thing I can do is to do my best to speed it
>>>> up a bit and be more active in RTCs (given my manager doesn't get me
>>>> swamped with other daily tasks that took me away for the past weeks).
>>>> Not mentioning there're lots of bugs reported.
>>> I think that if the Apache Geronimo community is actually
>>> self-governing as I believed it was, then there is something that can
>>> be done about this.
>>> You are definitely not alone in thinking that RTC is painful (and
>>> non-functional I would like to add).
>>>>> I'm confused now... how can one send a RTC w/o having a patch or
>>>>> patches for others to review?
>>>>
>>>> Yes, you might've been confused as it's Matt's statement nor mine and
>>>> thus the origin of your confusion, isn't it?
>>> Honestly... I don't know... but I am confused ;-)
>>
>> My point was that for very complicated changes like M1 -> M2 a note
>> outlining the proposed action should not require a fully baked patch. 
>> Perhaps I misstated.
>>
>>>> I have never been as active in open source projects (Apache Geronimo
>>>> and OpenEJB in particular) as I should've been. I haven't been able to
>>>> manage my daily workload wisely and  spare more time to work on these
>>>> OSSes at nights. At this point I'm completely overwhelmed with other
>>>> stuff meaning I don't have as much time as is required from me to
>>>> contribute.
>>> It happens... which is why we have a community of developers to help
>>> pick up the slack.  Unfortunately some decisions have been made which
>>> limit the abilities of the bulk of the community and force the
>>> minorities to play a much bigger part, which unfortunately most have
>>> not stepped up to do.
>> Jason, RTC was implemented because the PMC chair and the Board felt
>> that the G community was not functioning in an open fashion.  I don't
>> want to repeat that whole debate as its been debated and nothing
>> positive will come from rehashing it.
>>
>> RTC has improved communications I think is achieving its desired
>> effect.  Yes, the side effect is slowing down some development.  I
>> know its frustrating but if we work well together through the process
>> changes (RTC) we will be moving back to CTR.  Complaining about RTC
>> won't get us there. Yes, we're all frustrated and we all will get
>> through this working together.
>>
>>>> I see it as a threat to me being a PMC member. Do you
>>>> think I should step down having failed so often?
>>> Not at all.  I don't believe that you should step down at all.  You
>>> are one of the few PMC folks that is actually trying to keep up with
>>> the RTC and I certainly don't want to see those numbers reduced.
>>> As I mentioned before, I was not aiming my comments at anyone in
>>> particular.  I have just been quietly ignoring the situation for
>>> sometime, and feel that I can not do that anymore... it is not in my
>>> nature.
>> I agree that Jacek is doing great.  Collectively we all make this work
>> and all contributions great and small move us forward.
>>>> I remember having discussion about a distinction between a committer
>>>> and PMC member. Some believed there's none.
>>> I'm not sure that there is (or should be) much difference.
>>>> It's not my decision to activate RTC, which as far as I understand has
>>>> never proven itself to be successful, but that's reality we need to
>>>> live in.
>>> If our community is self-governing and the bulk of the community is
>>> in opposition to this rule, why then does that community need to live
>>> with it?
>> See above about the Board and PMCs perspective of our community dynamics.
>>> BTW, that is my opinion... I have not performed any poll to see which
>>> parts of our community actually is in favor of RTC.  I would suggest
>>> that most folks agree that improved and more frequent communication
>>> is desired... but I also suggest that RTC in its current incarnation
>>> is NOT the best way to achieve those goals.
>> Its moved us back from where we were at.  Certainly past where we
>> should be but I'm optimistic that we'll move back to the center.
>>>> I believe, though, that it won't kill the project, but strengthen.
>>> That all depends on how long it goes not for...
>>> IMO, the longer it does, the more chances are that the end-result
>>> will be a more and more defunct community.
>>>  * * *
>>> Thanks for taking the time to respond.  I apologize if my comments
>>> stir your frustration... but I felt and fell like I have to say
>>> something, to play my part in this community.
>>> --jason

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

Guys, I feel like I am allowed to state my opinions.

I am not complaining (and a bit insulted that you think I am), but I  
believe that RTC is harmful for a few reasons.

I also feel like some responses to mails I have sent are basically  
that I should shut-up (my words), which I do not appreciate.

:-(

--jason


On Jun 30, 2006, at 5:35 AM, Matt Hogstrom wrote:

> Jason Dillon wrote:
>>> I second your opinions, but that's how we operate and I can't do  
>>> much
>>> regarding this matter other than to spare some time and vote at  
>>> least.
>>> I think I'm not alone thinking that RTC is very painful, but some  
>>> see
>>> it as a remedy of our troublesome happenings in the past. We'll see
>>> how it work out. The only thing I can do is to do my best to  
>>> speed it
>>> up a bit and be more active in RTCs (given my manager doesn't get me
>>> swamped with other daily tasks that took me away for the past  
>>> weeks).
>>> Not mentioning there're lots of bugs reported.
>> I think that if the Apache Geronimo community is actually self- 
>> governing as I believed it was, then there is something that can  
>> be done about this.
>> You are definitely not alone in thinking that RTC is painful (and  
>> non-functional I would like to add).
>>>> I'm confused now... how can one send a RTC w/o having a patch or
>>>> patches for others to review?
>>>
>>> Yes, you might've been confused as it's Matt's statement nor mine  
>>> and
>>> thus the origin of your confusion, isn't it?
>> Honestly... I don't know... but I am confused ;-)
>
> My point was that for very complicated changes like M1 -> M2 a note  
> outlining the proposed action should not require a fully baked  
> patch.  Perhaps I misstated.
>
>>> I have never been as active in open source projects (Apache Geronimo
>>> and OpenEJB in particular) as I should've been. I haven't been  
>>> able to
>>> manage my daily workload wisely and  spare more time to work on  
>>> these
>>> OSSes at nights. At this point I'm completely overwhelmed with other
>>> stuff meaning I don't have as much time as is required from me to
>>> contribute.
>> It happens... which is why we have a community of developers to  
>> help pick up the slack.  Unfortunately some decisions have been  
>> made which limit the abilities of the bulk of the community and  
>> force the minorities to play a much bigger part, which  
>> unfortunately most have not stepped up to do.
> Jason, RTC was implemented because the PMC chair and the Board felt  
> that the G community was not functioning in an open fashion.  I  
> don't want to repeat that whole debate as its been debated and  
> nothing positive will come from rehashing it.
>
> RTC has improved communications I think is achieving its desired  
> effect.  Yes, the side effect is slowing down some development.  I  
> know its frustrating but if we work well together through the  
> process changes (RTC) we will be moving back to CTR.  Complaining  
> about RTC won't get us there. Yes, we're all frustrated and we all  
> will get through this working together.
>
>>> I see it as a threat to me being a PMC member. Do you
>>> think I should step down having failed so often?
>> Not at all.  I don't believe that you should step down at all.   
>> You are one of the few PMC folks that is actually trying to keep  
>> up with the RTC and I certainly don't want to see those numbers  
>> reduced.
>> As I mentioned before, I was not aiming my comments at anyone in  
>> particular.  I have just been quietly ignoring the situation for  
>> sometime, and feel that I can not do that anymore... it is not in  
>> my nature.
> I agree that Jacek is doing great.  Collectively we all make this  
> work and all contributions great and small move us forward.
>>> I remember having discussion about a distinction between a  
>>> committer and PMC member. Some believed there's none.
>> I'm not sure that there is (or should be) much difference.
>>> It's not my decision to activate RTC, which as far as I  
>>> understand has
>>> never proven itself to be successful, but that's reality we need  
>>> to live in.
>> If our community is self-governing and the bulk of the community  
>> is in opposition to this rule, why then does that community need  
>> to live with it?
> See above about the Board and PMCs perspective of our community  
> dynamics.
>> BTW, that is my opinion... I have not performed any poll to see  
>> which parts of our community actually is in favor of RTC.  I would  
>> suggest that most folks agree that improved and more frequent  
>> communication is desired... but I also suggest that RTC in its  
>> current incarnation is NOT the best way to achieve those goals.
> Its moved us back from where we were at.  Certainly past where we  
> should be but I'm optimistic that we'll move back to the center.
>>> I believe, though, that it won't kill the project, but strengthen.
>> That all depends on how long it goes not for...
>> IMO, the longer it does, the more chances are that the end-result  
>> will be a more and more defunct community.
>>  * * *
>> Thanks for taking the time to respond.  I apologize if my comments  
>> stir your frustration... but I felt and fell like I have to say  
>> something, to play my part in this community.
>> --jason

Re: [RTC] Clarification please from the PMC

[Matt Hogstrom <ma...@hogstrom.org>]

Jason Dillon wrote:
>> I second your opinions, but that's how we operate and I can't do much
>> regarding this matter other than to spare some time and vote at least.
>> I think I'm not alone thinking that RTC is very painful, but some see
>> it as a remedy of our troublesome happenings in the past. We'll see
>> how it work out. The only thing I can do is to do my best to speed it
>> up a bit and be more active in RTCs (given my manager doesn't get me
>> swamped with other daily tasks that took me away for the past weeks).
>> Not mentioning there're lots of bugs reported.
> 
> I think that if the Apache Geronimo community is actually self-governing 
> as I believed it was, then there is something that can be done about this.
> 
> You are definitely not alone in thinking that RTC is painful (and 
> non-functional I would like to add).
> 
> 
>>> I'm confused now... how can one send a RTC w/o having a patch or
>>> patches for others to review?
>>
>> Yes, you might've been confused as it's Matt's statement nor mine and
>> thus the origin of your confusion, isn't it?
> 
> Honestly... I don't know... but I am confused ;-)
> 

My point was that for very complicated changes like M1 -> M2 a note outlining the proposed action 
should not require a fully baked patch.  Perhaps I misstated.

> 
>> I have never been as active in open source projects (Apache Geronimo
>> and OpenEJB in particular) as I should've been. I haven't been able to
>> manage my daily workload wisely and  spare more time to work on these
>> OSSes at nights. At this point I'm completely overwhelmed with other
>> stuff meaning I don't have as much time as is required from me to
>> contribute.
> 
> It happens... which is why we have a community of developers to help 
> pick up the slack.  Unfortunately some decisions have been made which 
> limit the abilities of the bulk of the community and force the 
> minorities to play a much bigger part, which unfortunately most have not 
> stepped up to do.
> 
Jason, RTC was implemented because the PMC chair and the Board felt that the G community was not 
functioning in an open fashion.  I don't want to repeat that whole debate as its been debated and 
nothing positive will come from rehashing it.

RTC has improved communications I think is achieving its desired effect.  Yes, the side effect is 
slowing down some development.  I know its frustrating but if we work well together through the 
process changes (RTC) we will be moving back to CTR.  Complaining about RTC won't get us there. 
Yes, we're all frustrated and we all will get through this working together.

> 
>> I see it as a threat to me being a PMC member. Do you
>> think I should step down having failed so often?
> 
> Not at all.  I don't believe that you should step down at all.  You are 
> one of the few PMC folks that is actually trying to keep up with the RTC 
> and I certainly don't want to see those numbers reduced.
> 
> As I mentioned before, I was not aiming my comments at anyone in 
> particular.  I have just been quietly ignoring the situation for 
> sometime, and feel that I can not do that anymore... it is not in my 
> nature.
> 
I agree that Jacek is doing great.  Collectively we all make this work and all contributions great 
and small move us forward.
> 
>> I remember having discussion about a distinction between a committer 
>> and PMC member. Some believed there's none.
> 
> I'm not sure that there is (or should be) much difference.
> 
> 
>> It's not my decision to activate RTC, which as far as I understand has
>> never proven itself to be successful, but that's reality we need to 
>> live in.
> 
> If our community is self-governing and the bulk of the community is in 
> opposition to this rule, why then does that community need to live with it?
> 
See above about the Board and PMCs perspective of our community dynamics.
> BTW, that is my opinion... I have not performed any poll to see which 
> parts of our community actually is in favor of RTC.  I would suggest 
> that most folks agree that improved and more frequent communication is 
> desired... but I also suggest that RTC in its current incarnation is NOT 
> the best way to achieve those goals.
Its moved us back from where we were at.  Certainly past where we should be but I'm optimistic that 
we'll move back to the center.
> 
> 
>> I believe, though, that it won't kill the project, but strengthen.
> 
> That all depends on how long it goes not for...
> 
> IMO, the longer it does, the more chances are that the end-result will 
> be a more and more defunct community.
> 
>  * * *
> 
> Thanks for taking the time to respond.  I apologize if my comments stir 
> your frustration... but I felt and fell like I have to say something, to 
> play my part in this community.
> 
> --jason
> 
> 
> 
> 

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

> I second your opinions, but that's how we operate and I can't do much
> regarding this matter other than to spare some time and vote at least.
> I think I'm not alone thinking that RTC is very painful, but some see
> it as a remedy of our troublesome happenings in the past. We'll see
> how it work out. The only thing I can do is to do my best to speed it
> up a bit and be more active in RTCs (given my manager doesn't get me
> swamped with other daily tasks that took me away for the past weeks).
> Not mentioning there're lots of bugs reported.

I think that if the Apache Geronimo community is actually self- 
governing as I believed it was, then there is something that can be  
done about this.

You are definitely not alone in thinking that RTC is painful (and non- 
functional I would like to add).


>> I'm confused now... how can one send a RTC w/o having a patch or
>> patches for others to review?
>
> Yes, you might've been confused as it's Matt's statement nor mine and
> thus the origin of your confusion, isn't it?

Honestly... I don't know... but I am confused ;-)


> I have never been as active in open source projects (Apache Geronimo
> and OpenEJB in particular) as I should've been. I haven't been able to
> manage my daily workload wisely and  spare more time to work on these
> OSSes at nights. At this point I'm completely overwhelmed with other
> stuff meaning I don't have as much time as is required from me to
> contribute.

It happens... which is why we have a community of developers to help  
pick up the slack.  Unfortunately some decisions have been made which  
limit the abilities of the bulk of the community and force the  
minorities to play a much bigger part, which unfortunately most have  
not stepped up to do.


> I see it as a threat to me being a PMC member. Do you
> think I should step down having failed so often?

Not at all.  I don't believe that you should step down at all.  You  
are one of the few PMC folks that is actually trying to keep up with  
the RTC and I certainly don't want to see those numbers reduced.

As I mentioned before, I was not aiming my comments at anyone in  
particular.  I have just been quietly ignoring the situation for  
sometime, and feel that I can not do that anymore... it is not in my  
nature.


> I remember having discussion about a distinction between a  
> committer and PMC member. Some believed there's none.

I'm not sure that there is (or should be) much difference.


> It's not my decision to activate RTC, which as far as I understand has
> never proven itself to be successful, but that's reality we need to  
> live in.

If our community is self-governing and the bulk of the community is  
in opposition to this rule, why then does that community need to live  
with it?

BTW, that is my opinion... I have not performed any poll to see which  
parts of our community actually is in favor of RTC.  I would suggest  
that most folks agree that improved and more frequent communication  
is desired... but I also suggest that RTC in its current incarnation  
is NOT the best way to achieve those goals.


> I believe, though, that it won't kill the project, but strengthen.

That all depends on how long it goes not for...

IMO, the longer it does, the more chances are that the end-result  
will be a more and more defunct community.

  * * *

Thanks for taking the time to respond.  I apologize if my comments  
stir your frustration... but I felt and fell like I have to say  
something, to play my part in this community.

--jason

Re: [RTC] Clarification please from the PMC

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/29/06, Jason Dillon <ja...@planet57.com> 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...

I second your opinions, but that's how we operate and I can't do much
regarding this matter other than to spare some time and vote at least.
I think I'm not alone thinking that RTC is very painful, but some see
it as a remedy of our troublesome happenings in the past. We'll see
how it work out. The only thing I can do is to do my best to speed it
up a bit and be more active in RTCs (given my manager doesn't get me
swamped with other daily tasks that took me away for the past weeks).
Not mentioning there're lots of bugs reported.

> >> 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?

Yes, you might've been confused as it's Matt's statement nor mine and
thus the origin of your confusion, isn't it?

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

I have never been as active in open source projects (Apache Geronimo
and OpenEJB in particular) as I should've been. I haven't been able to
manage my daily workload wisely and  spare more time to work on these
OSSes at nights. At this point I'm completely overwhelmed with other
stuff meaning I don't have as much time as is required from me to
contribute. I see it as a threat to me being a PMC member. Do you
think I should step down having failed so often? I think it wouldn't
be forgiven at this point. I remember having discussion about a
distinction between a committer and PMC member. Some believed there's
none. Would you believe what might've happened once we introduced it.

When I made it to TSSJS in Barcelona, I spoke about it with others
(Dave, Matt, Aaron, James). Now, with a very few PMC members it's more
complicated to keep the pace as well as be forced to be more active in
Geronimo development when my time constraints have not changed. I'm
really, really frustrated (and even though you didn't mean to direct
your comments to anyone they're doing their job very well - many
thanks! ;-))

It's not my decision to activate RTC, which as far as I understand has
never proven itself to be successful, but that's reality we need to
live in. I believe, though, that it won't kill the project, but
strengthen.

On to my responsibilities as a
PMCer...testing...documenting...testing...testing...

> --jason

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl

Re: [RTC] Clarification please from the PMC

[Jason Dillon <ja...@planet57.com>]

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.


> We need to be very patient until more committers become PMC
> members and their votes are binding.

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.

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 ;-)


> 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

Re: [RTC] Clarification please from the PMC

[Jacek Laskowski <ja...@laskowski.net.pl>]

On 6/29/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> There is a lot of work going on to migrate from Maven 1 to Maven 2 in our build.  A question came up
> as to whether or not we needed [RTC] for that activity.  Please read an excerpt from David's e-mail
> on the topic...
>
> David Jencks wrote:
> > AFAIK no one is planning to try to get 1.1 to build with m2.  I
> > certainly don't feel like I have time to deal with the RTC process for
> > something that requires zillions of trivial changes to get to work.

I was not happy to have read so and if Dave loses his pasion to do the
work how else will do it? That's true and that needs to be changed. As
a PMC member I don't think it's that bad. We're improving and the
number of emails recently dramatically increased that surely impact
how people follow what's being done in Geronimo. Although RTC has
slowed down development a bit (or even more), it will pay off very
soon. We need to be very patient until more committers become PMC
members and their votes are binding. Painful, but in the end it might
boost development significantly.

AFAIUI, the whole point of RTC is to ensure communication through
dev/user mailing lists rather than in closed circles.

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

+1

> [RTC] M1 - M2 converstion e-mail sent to dev
> Developers review the "plan" (as not all changes are known) and they reach consensus about the
> significant change.  They get they're +1s from the group and begin their work.

+1

> They continue their work posting status e-mails to the group but are not required to get 3 +1s on
> every change but only changes where it would warrant some input (like changing directory layouts,
> etc.)   Even these I see as informative and normal communication and not an [RTC] thread.

Since people are all engaged in the process or are at least interested
in following it, why would that be hard to reach 3 +1s? I don't see
it. Are you saying that once the plan is approved (with 3 binding
votes) the following steps wouldn't be as much important and wouldn't
get their 3 +1s? I think I'm mistaken and didn't get the point of your
suggestion?

> I believe the goal of RTC is to improve communication which in many instances it has.  In the spirit
> of RTC we could complete the Maven 1 -> 2 conversion without large numbers of RTCs required.

Right, but at the end of the day at least 3 people are fully
aware/familiar with how it really works, which is a good thing. I
think once the migration is over we will improve our communication
skills and RTC will become obsolete.

> Recently I think Jeff requested an RTC to update the committers page which I think falls outside of
> the RTC requirement so based on these two examples I believe there is still come confusion.

My understanding is that only trunk needs RTC unless it's a bug fix.
Documentation changes don't need RTC - they do improve communication
about the product so no need to ask for 3 +1s.

> Matt

Jacek

-- 
Jacek Laskowski
http://www.laskowski.net.pl