You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by John Sisson <jr...@gmail.com> on 2006/07/04 07:27:16 UTC
[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
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/4/06, John Sisson <jr...@gmail.com> 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)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
>
>
>
>
>
Re: [DISCUSS] Patch vote restart guidelines (was Re: [jira] Updated: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml)
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 7/4/06, Jason Dillon <ja...@planet57.com> 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)
Posted by Jason Dillon <ja...@planet57.com>.
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)
Posted by Paul McMahan <pa...@gmail.com>.
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 <jr...@gmail.com> 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
>
>