Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
On 7/4/06, Jason Dillon [EMAIL PROTECTED] wrote: 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 do you think our non-committers work? I think it's time to think about it and come up with a solution that would help them and us. Do you think it is the reason why there's so few contributions? I don't really have any idea how to improve it, really. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
On 7/4/06, John Sisson [EMAIL PROTECTED] 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. To make it easier for reviewers when a new version of a patch is generated, it would be worthwhile adding a comment on what has changed since the previous patch. Do the above patch vote negation guidelines sound reasonable to everyone? +1 John Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
John, if the ultimate goal of RTC is to ensure quality then I think the restart guidelines sound reasonable since they guarantee that the exact code being committed has been inspected multiple times and by independent sources. But if the goal of RTC is really just to ensure that the left hand knows what the right hand is doing then we may benefit from relaxing the definition of trivial to mean those changes which don't affect the core flow of the reviewed code. e.g. changes which improve readability, address minor oversights, or address edge cases would fall into this category. Actually, now that I think about it I wonder if allowing these types of changes to go in without restarting the review might actually improve quality because the contributor would otherwise be hesitant to make them. For example, if 3 PMC members review the code and two provide a +1 but a third suggests some trivial changes then the contributor is less likely to make them if it means restarting the review. Paul On 7/4/06, John Sisson [EMAIL PROTECTED] wrote: Jason Dillon wrote: So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm not exactly sure how that affects the current votes... or does adding a new version of the patch negate anything else voted upon. 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. To make it easier for reviewers when a new version of a patch is generated, it would be worthwhile adding a comment on what has changed since the previous patch. Do the above patch vote negation guidelines sound reasonable to everyone? Thanks, John
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
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
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
I think in general you are correct John. Although, from what I've seen the people that are reviewing the patches are working with the submitter and then when they're happy give they're +1. I believe the spirit of RTC is being met through the current process. Personally I'd prefer to not increase the bureaucracy unless there is concern that the current process is being abused. Jason Dillon wrote: 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
[DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
Jason Dillon wrote: So far 2+ days, several patches... one PMC +1, one non-PMC +1 (with caveat to ping JVZ)... now crazy problems with diff/patch.. which I'm not exactly sure how that affects the current votes... or does adding a new version of the patch negate anything else voted upon. 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. To make it easier for reviewers when a new version of a patch is generated, it would be worthwhile adding a comment on what has changed since the previous patch. Do the above patch vote negation guidelines sound reasonable to everyone? Thanks, John
