On Sat, Nov 14, 2009 at 5:30 AM, Doug Cutting wrote:
> Aidan Skinner wrote:
>>
>> I'd flip this around and look at it from the PoV of a
>> not-yet-committer. RTC means everybody goes through basically the same
>> process - (raise jira), hack, submit patch, patch gets reviewed, patch
>> gets commit
David Crossley wrote:
> Kevan Miller wrote:
> > Upayavira wrote:
> > >
> > >My question is, why is Clutch reporting the Aries developer list as
> > >being gene...@? Presumbaly this is something that the Aries developers
> > >should be fixing.
> >
> > So, if I'm interpreting clutch.py correctly, lo
Thanks Brett, I kept meaning to separate the maven project parts from
the common ones, and this is a good start.
--Brian (mobile)
On Nov 13, 2009, at 2:29 AM, Brett Porter wrote:
For unrelated reasons, I today split out the Apache-ness part of the
Maven release process (still syncing):
h
I agree with Joe.
thanks,
dims
On 11/13/2009 03:50 PM, Joe Schaefer wrote:
- Original Message
From: Greg Stein
To: general@incubator.apache.org
Sent: Fri, November 13, 2009 12:23:04 PM
Subject: Explanation of the extra pain (was: Two other issues to discuss for
Subversion)
Ok
Aidan Skinner wrote:
I'd flip this around and look at it from the PoV of a
not-yet-committer. RTC means everybody goes through basically the same
process - (raise jira), hack, submit patch, patch gets reviewed, patch
gets committed regardless of whether they have a commit bit or not.
+1 With RT
Justin Erenkrantz wrote:
As I understood Owen's "Intro to Hadoop" talk at AC, Hadoop has
changed their methodology lately to CTR and found it to work far
better. (Duh.) -- justin
Hadoop uses RTC.
Doug
-
To unsubscribe, e-ma
- Original Message
> From: Greg Stein
> To: general@incubator.apache.org
> Sent: Fri, November 13, 2009 12:23:04 PM
> Subject: Explanation of the extra pain (was: Two other issues to discuss for
> Subversion)
> Okay. I *think* that is pretty much the background/rationale (please
>
In reference to Gilles' question about why we normally ask podling to
take on a bit of pain for double-migration, I think Leo answered that
very well [on this other thread]. That the reason focuses mostly
around making representations to users. "this is an Incubator project,
not a full Apache proje
> I expect very few projects to ask for this special treatment.
Place your bets ...
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
Robert Burrell Donkin wrote:
> IMHO a podling should know how to cut an ASF release
> the easiest way to demonstrate this knowledge is to cut a release
> but it's not the only way.
I don't have an argument with any of those three points.
I also suggest that there is a difference between preparin
On Fri, Nov 13, 2009 at 6:27 PM, Noel J. Bergman wrote:
> Greg Stein wrote:
>
>> > IIRC, Martijn has offered a proper legal review in the place of a
> "release".
>> > This sounded pretty reasonable to me. I would agree to that.
>
>> Yup. I've already stated that I have no problems with running RAT
Greg Stein wrote:
> > IIRC, Martijn has offered a proper legal review in the place of a
"release".
> > This sounded pretty reasonable to me. I would agree to that.
> Yup. I've already stated that I have no problems with running RAT and
> working through those issues. Might have been hard to see i
> > 1) PPMC must vote for the release according to their rules (which
> > should at least match the 3 +1 / majority rule requirements)
> > 2) at least one PMC member must vote +1 (usually the mentor)
> Well.. let's call this the "expedited" form of release. It leaves the
> PPMC a bit more self-suf
On Fri, Nov 13, 2009 at 12:06, Jukka Zitting wrote:
> Hi,
>
> On Fri, Nov 13, 2009 at 6:51 AM, Greg Stein wrote:
>> But your above paragraph is some conflation of release practices,
>> legal review, and how this fits into graduation requirements. And I
>> just got done with a frustrating several
Hi,
On Fri, Nov 13, 2009 at 6:51 AM, Greg Stein wrote:
> But your above paragraph is some conflation of release practices,
> legal review, and how this fits into graduation requirements. And I
> just got done with a frustrating several days on that issue. What do
> you want?
Sorry, I must have b
On Nov 11, 2009, at 5:35 PM, Davanum Srinivas wrote:
> Dan,
>
> "It's up to each project to get their releases correct" - Yes. But not
> everyone hangs out on the d...@maven or gene...@incubator. Hence the request
> to broadcast.
>
> I really don't understand the "why?" - No one is trying to
With a few days of additional information now available, I'll stick my
finger into the soup again.
What the incubator wants/needs/requires is that the community
understand how to make and vote on a release,
and that the release conforms to Apache legal standards.
I would be happy to split
No objection from me for creating mailing lists and svn repo in the
expected final place.
It's a bit of a pain for podlings to face a double move of both their
repositories and mailing lists when arriving at Apache. The rationale
for doing it has many aspects that IMHO don't apply to the S
Same remark here than for the svn migration.
As this is unusual for the incubating project, it might be eductive for the
future poddling to describe why the incubator wants normaly to have
incubator mailing list and why this rational is not applicable to
subversion.
Gilles Scokart
2009/11/13 G
As this is unusual for the incubating project, it might be eductive for the
future poddling to describe why the incubator wants normaly to to have the
project under /incubator/ and why this rational is not applicable to
subversion.
Don't misunderstand me, I think it is good to have such exception
On Fri, Nov 13, 2009 at 12:59 AM, Greg Stein wrote:
> Joe Schaefer asked if he could set up the mailing lists this weekend.
> The discussion seemed to end, with no particular opposition, so I
> filed an Infrastructure ticket to track the creation of the mailing
> lists:
> https://issues.apache.or
21 matches
Mail list logo
