On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote:
I think this will have an extremely debilitating and discouraging
effect on everyone involved: no one can commit their own code.
Yes, it doesn't sound very entertaining. I'll have to think about it again.
"No
code ownership" is fine, but IMO
On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Hey Jacek,
BTW, I apologize about the blessing of the final 3 +1s within the 18
hours period. I did not mean to go against your statement. I just
recalled an email about 3 +1s allowed it to happen and there was no need
to wait...that a -1 cou
On 7/7/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote:
> My point of view is that while there might be a minimum time needed
> in total for a vote, there is no need to wait after the 3rd +1 as
> long as that minumum time since the start of the vo
On 7/7/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
I'd rather not troll back through the postings, but I certainly
recall that the same guidelines -- there wasn't a minimum time period
for an RTC vote. Once you have 3 +1's you would be able to commit and
there can still be a -1 at any time (hope
On Jul 7, 2006, at 8:40 AM, Jeff Genender wrote:
Hey Jacek,
BTW, I apologize about the blessing of the final 3 +1s within the 18
hours period. I did not mean to go against your statement. I just
recalled an email about 3 +1s allowed it to happen and there was no
need
to wait...that a -1 c
Hey Jacek,
BTW, I apologize about the blessing of the final 3 +1s within the 18
hours period. I did not mean to go against your statement. I just
recalled an email about 3 +1s allowed it to happen and there was no need
to wait...that a -1 could be waged at anytime in the future. If I
stepped ov
On Jul 6, 2006, at 11:54 PM, Jacek Laskowski wrote:
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
This is applied.
:-)
Took longer than expected because I happened to switch to a terminal
that was set to use JDK 1.5 and I did not realize it... until a few
hours later after I was pulling
I do not believe that your suggestion to have the final voter commit
patches will improve collaboration. I see that by adding another
layer of process only adds to the chances that the overall process
will fail... and IMO taking too long is a failure.
I am open to ideas about how to improv
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
-1 to this and any other way ways to slow down progress.
We need to find more effective ways to work with RTC, not more ways
to put up road blocks.
-1 requires more than just a thought or doubt. I don't see how it
could slow down a process mo
I think it would be much better if the person who makes a change is
not the one who commits it to trunk, but the last PMCer who voted for
it. And a branch the change is built from is established. The solution
has such a good effect that the person who works on changes don't have
to worry about the
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
This is applied.
:-)
Took longer than expected because I happened to switch to a terminal
that was set to use JDK 1.5 and I did not realize it... until a few
hours later after I was pulling my hair out wondering why the patch
god hates me so mu
On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote:
My point of view is that while there might be a minimum time needed
in total for a vote, there is no need to wait after the 3rd +1 as
long as that minumum time since the start of the vote has elapsed.
This vote has been going on with additions f
This is applied.
:-)
Took longer than expected because I happened to switch to a terminal
that was set to use JDK 1.5 and I did not realize it... until a few
hours later after I was pulling my hair out wondering why the patch
god hates me so much.
--jason
On Jul 6, 2006, at 4:54 PM, Je
w00t!
--jason
On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote:
Consider it blessed. ;-)
Jason Dillon wrote:
On Jul 6, 2006, at 4:23 PM, David Jencks wrote:
My point of view is that while there might be a minimum time
needed in
total for a vote, there is no need to wait after the 3rd +1 as
Consider it blessed. ;-)
Jason Dillon wrote:
> On Jul 6, 2006, at 4:23 PM, David Jencks wrote:
>> My point of view is that while there might be a minimum time needed in
>> total for a vote, there is no need to wait after the 3rd +1 as long as
>> that minumum time since the start of the vote has el
On Jul 6, 2006, at 4:23 PM, David Jencks wrote:
My point of view is that while there might be a minimum time needed
in total for a vote, there is no need to wait after the 3rd +1 as
long as that minumum time since the start of the vote has elapsed.
This vote has been going on with additions
On Jul 6, 2006, at 2:09 PM, Jason Dillon wrote:
I don't recall Jacek +1'ing... before or after the restart.
* * *
But, I was more curious how long after the next +1 comes in I
should wait before applying this?
My point of view is that while there might be a minimum time needed
in total f
On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
IIUC, after this restart, we need one more +1 from a PMC member to
allow these changes to be committed to the trunk.
Assuming that another +1 comes in soonish, how long shall I wait
before applying?
+1 (I did review it only as I had troubles t
I don't recall Jacek +1'ing... before or after the restart.
* * *
But, I was more curious how long after the next +1 comes in I should
wait before applying this?
--jason
On Jul 6, 2006, at 2:08 PM, Jeff Genender wrote:
If Jacek +1d it (I don't recall if he did) you have 3 +1s.
Jeff
Ja
If Jacek +1d it (I don't recall if he did) you have 3 +1s.
Jeff
Jason Dillon wrote:
> IIUC, after this restart, we need one more +1 from a PMC member to allow
> these changes to be committed to the trunk.
>
> Assuming that another +1 comes in soonish, how long shall I wait before
> applying?
>
IIUC, after this restart, we need one more +1 from a PMC member to
allow these changes to be committed to the trunk.
Assuming that another +1 comes in soonish, how long shall I wait
before applying?
--jason
On Jul 6, 2006, at 6:57 AM, Matt Hogstrom wrote:
+1 to getting this patch in...
On 7/6/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:
> I wonder how the changes will be applied to trunk if patch doesn't
> work?
It is easy enough to apply the patch and then copy the files from the
svkmerge/m2migration branch manually to recreat
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:
On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
We need to understand why SVN is creating bad patches but this
shouldn't hold up the migration to M2
effort. This is not an issue with the current patch but a problem
with SVN we need to un
On Jul 6, 2006, at 9:13 AM, Jacek Laskowski wrote:
I wonder how the changes will be applied to trunk if patch doesn't
work?
It is easy enough to apply the patch and then copy the files from the
svkmerge/m2migration branch manually to recreate the complete v5
patch changes.
--jason
Jacek,
I agree that that it has been hard to install. We need to figure out why. That is another issue I
think.
Matt
Jacek Laskowski wrote:
On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
We need to understand why SVN is creating bad patches but this
shouldn't hold up the migration t
On 7/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
We need to understand why SVN is creating bad patches but this shouldn't hold
up the migration to M2
effort. This is not an issue with the current patch but a problem with SVN we
need to undestand.
Don't we have it behind us already? I tho
I get similar issues, but upon carefully reviewing the patch(es), I am
in full agreement. +1 to the patch.
Jeff
Matt Hogstrom wrote:
> +1 to getting this patch in...
>
> I spent some time working with Jason and Jacek last night on this
> patch. It is fairly large and reaching. There appears to
+1 to getting this patch in...
I spent some time working with Jason and Jacek last night on this patch. It is fairly large and
reaching. There appears to be an issue with SVN creating a bad patch file for several files but I
don't believe this is Jason's issue but rather with SVN.
There are
28 matches
Mail list logo
