Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 33146 invoked from network); 16 Oct 2010 16:23:29 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Oct 2010 16:23:29 -0000 Received: (qmail 62891 invoked by uid 500); 16 Oct 2010 16:23:29 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 62765 invoked by uid 500); 16 Oct 2010 16:23:28 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 62757 invoked by uid 99); 16 Oct 2010 16:23:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Oct 2010 16:23:28 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of niall.pemberton@gmail.com designates 209.85.214.43 as permitted sender) Received: from [209.85.214.43] (HELO mail-bw0-f43.google.com) (209.85.214.43) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 16 Oct 2010 16:23:23 +0000 Received: by bwz20 with SMTP id 20so2393489bwz.30 for ; Sat, 16 Oct 2010 09:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=d+Jsoyf7QkQOeoW/YM7HsCdaBSGHFFlOCuK0z2gUm8g=; b=EYAhtdAwPoIZW5t6t/G0xuPD83uyfftMsDyP8qv/5CFFUqsKtyoHETxKmMTo24daG1 Lah4UU2vcwpxAV2z0XUjklFIDxcpWswmcTADW6hsMz8mwodaGqF5LRDIBrhlRoJ0NFok 6MnZ3dqki1Xy6cDoDJqBkurMpnuNMVI5BXzOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=rRqypDFj+SsDYQw0Liz89wYyFNcpoCUd7gEJ101CDEbXkmDwgKIZwYaT+kfLnZ8Rj5 3IHQaVYKeoEb3cGdWEIffF5HwTPlaCinZHz/mx9lNcXe06rt3rV+wV/hoeE0Iy07CF4q lXgptkjv1i8aI1QxIcUcCwE5JaI0Xs2uPV+cg= MIME-Version: 1.0 Received: by 10.204.114.205 with SMTP id f13mr2220177bkq.86.1287246182228; Sat, 16 Oct 2010 09:23:02 -0700 (PDT) Received: by 10.204.70.145 with HTTP; Sat, 16 Oct 2010 09:23:02 -0700 (PDT) In-Reply-To: References: <4CB8CA05.8060308@apache.org> <4CB9AEF9.5080208@apache.org> <4CB9B4DD.5060901@gmail.com> Date: Sat, 16 Oct 2010 17:23:02 +0100 Message-ID: Subject: Re: [pool] time to move groupId? From: Niall Pemberton To: Commons Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Oct 16, 2010 at 4:02 PM, James Carman wrote: > On Sat, Oct 16, 2010 at 10:34 AM, Niall Pemberton > wrote: >> >> +1 to what Dennis says. Changing the artifactId doesn't accompilsh >> anything additional if the groupId is changing. >> > > Other than keeping things consistent. =A0But, apparently folks around > here aren't as concerned with that as I am, because we have this > argument every time we bring this stuff up. =A0I keep saying "consistent > consistent" and other folks just say "it's up to the project to do > whatever they want" or "why do we have to do that" or "we can just > change the group id" or whatever. Consistency is good, but deciding something based purely on *consistency* rather than the merits of the situation is mindless. On top of that sometimes its not possible to get unified agreement by a large diverse group of developers. We are a federation of components here in Commons which is unlike most ASF projects - in other projects its necessary to decide single approaches because people are working on the same code base. Here the code bases and developers are often unrelated and its divisive for people to start dictating to a component they don't work on. IMO one of the main ASF principles is the people who do the work make the decisions. Commons wide *rules* should be kept to a minimum. We should promote consistency, but at the same time not get hung up on it. > Apache Commons should try to do things in a consistent fashion. =A0If > not, then why don't we just promote all subprojects to TLPs and be > done with it. =A0There's no reason for them to be under one umbrella. The vast majority of these components would never work as a TLP because they don't individually have enough developers. Commons is a community of people interested in developing small components and prepared to help each other out to provide the necessary oversight so that collectively we can function here at the ASF. Its important to tolerate the differences between components rather than trying to impose a *one-rule-to-rule-them-all* type approach. Niall --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org