geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
Date Tue, 04 Jul 2006 06:16:54 GMT
On Jul 3, 2006, at 10:27 PM, John Sisson wrote:
> IMO, a vote for a patch would be need to be restarted if the  
> changes between the previous patch and the newer version of the  
> patch are not trivial.  Trival meaning:
>
> * documentation changes
> * non-controversial non-semantic style changes such as fixing  
> indentation and adding comments.
> Trivial changes do not include code changes or changes that affect  
> the operation of the build.

In general I agree with you... but I'm not sure that this should  
apply to what is going on for m2 work (or other similar types of work).

If we tried to follow this, then almost everyday the latest patch  
needs to be reapplied and re-approved by everyone.  Its been hard  
enough to get people to apply any version of the patch.  I do not  
think, for this work, that requiring folks to reapply/revalidate for  
every revision for the RTC to complete is going to be effective.

I am making significant progress on the m2 build and I really would  
rather not wait for (days, weeks) for one patch to get approved  
before continuing to work on the next steps.  I can also not really  
split up these into incremental patches.

I might have a different opinion of this entire situation if there  
were more PMC members that were actually looking at these patches...  
say one a day.  If I pump out an average of 1/2+ a patch a day, then...

After 2 days, 2 PMC would have reviewed (and lets just say were +1),  
but I have gotten further and have a new version of the patch now, so  
now they need to do it again... and probably won't until tomorrow.

After 3 days, the 3rd PMC got to the v2 patch and +1

After 4 days, another PMC + 1, but another version is out... so  
scratch the votes and start over.

The only chance in this example is for 1-2 PMC members to review  
apply each day.  If 1 on the first, then must be 2 on the second or  
visa-versa.  Given the current PMC member activity, I don't believe  
it will ever be possible (following this example) to every get  
anything approved.

  * * *

How on earth is this going to work?  In this example I was being  
optimistic about one +1 per day by a PMC member, but based on the  
current status of GERONIMO-2161 it looks more like one +1 every 2 or  
3 days.

The alternative is to slow down... make less changes, waiting the  
time for PMC members to vote on a single revision.  So, one +1 every  
2 or 3 days turns into 6 to 9 days of idle time waiting for PMC  
members to review/vote.  And since I have made 2 (almost 3 from  
todays work) significant additions to the patch, that means about 18  
to 27 days to get the *additional* changes I have made in the past  
few days voted in to be committed.

The end result is a month+ has gone by, very little progress was  
actually committed to the codebase to migrate to Maven 2.  At that  
rate, maybe by this time next year we will have something ready.  Or,  
lets say that the numbers are off... by 50% or so... well then it  
will only take more months to implement the transition to m2.

So if it takes 6mo to a year to transition to a new build system...  
how long is it going to take to actually build features that are  
users want?!  I'm not including any of the time spent so far with the  
m2 conversion... but from what I gather its already been in progress  
for several months.  This is work that should be easily completed in  
a week or so, given that there are people actively working on it.

  * * *

Maybe I have been smoking too much crack or popped one to many crazy  
pills, but this really seems like a whacked-out impossible situation...

--jason



Mime
View raw message