From general-return-44417-apmail-incubator-general-archive=incubator.apache.org@incubator.apache.org Tue Mar 25 01:47:35 2014 Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id CB4AE10361 for ; Tue, 25 Mar 2014 01:47:35 +0000 (UTC) Received: (qmail 73657 invoked by uid 500); 25 Mar 2014 01:47:18 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 73366 invoked by uid 500); 25 Mar 2014 01:47:18 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 73357 invoked by uid 99); 25 Mar 2014 01:47:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2014 01:47:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.128.174] (HELO mail-ve0-f174.google.com) (209.85.128.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2014 01:47:11 +0000 Received: by mail-ve0-f174.google.com with SMTP id oz11so6522502veb.19 for ; Mon, 24 Mar 2014 18:46:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=r49dkuUEQ0XZ4IkkJo+edlB20MoYAa6sOUvW2cTnVt8=; b=UhiMEo4AtoxvOrBrBIN+31sFAmqHLFJT5qKjLsRwNiRXbn9HvTMDtK3lVf4jQbdnfd Hl/NQ3TbOjD37SFePoQQ4vyOzDj7U4kVzy39ZmnQJBI97ncQx2A2FhVyICQ98+J7uvcP DBudlMGsSwPtMvOZk33gkweTHWuqJA47PhjRoYqL0Kvpkz5ZG6yLK49ztjob2p+f4/gT BbB9OXjzJh/sz9/jy3rf8LPn2nIgeIXHKM7kWMB9umsmWgjyx+/gSZN3NnApqOfwLTu2 WaABu8DbdgjAl/2LfK0u5RD/ukpeSKhg/z0OxbADMDUiAQC9bF5FS0XjzgD2rVoe75JW P7qQ== X-Gm-Message-State: ALoCoQkbtEHdFixlugUnCHUjLc/zKuh5zhNKlthw7LtX6/uroEF929XBheRfR5g6qvB89SnlR2rs MIME-Version: 1.0 X-Received: by 10.220.99.72 with SMTP id t8mr53340042vcn.10.1395712009235; Mon, 24 Mar 2014 18:46:49 -0700 (PDT) Received: by 10.58.156.102 with HTTP; Mon, 24 Mar 2014 18:46:49 -0700 (PDT) X-Originating-IP: [206.190.64.2] In-Reply-To: References: <1395710292.1302.98451013.1B7431F7@webmail.messagingengine.com> Date: Mon, 24 Mar 2014 18:46:49 -0700 Message-ID: Subject: Re: Rearrange the "Project List" into multiple pages? From: Marvin Humphrey To: "general@incubator.apache.org" Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org sebb: > Not always, for example > > OpenOffice.org => ooo > > The usecase for the resourcename (perhaps resourceAlias) is to access SVN Repositories are linked from the podling status page, though it is admittedly not as convenient to get there in two hops. Many recent podlings use Git -- often multiple repositories -- so linking to SVN is of limited use. If you really really want this I'm not going to object but I think it should be acknowledged that it's often inappropriate. David Crossley: > Also for poor Clutch to try to keep up with the inconsistency of project > names. Definitely the resource name is important for that purpose -- I'm simply questioning how much benefit we get from dedicating a field to it on the podling listing page. sebb once again: > >> > As for breaking things up into three pages... it may not be necessary once > >> > the rows shrink. > > The idea was not to lose all the existing data, most of which I think > is only displayed on that page currently. Everything on that page is also duplicated on the podling status pages. If certain values are not in sync, I think we should acknowledge that and fix our DRY problems rather than add more duplication. > The idea was to provide a summary in addition to the individual more > detailed sections. Hmm. To be honest, I don't think that's justified. I think it's too many resources providing slightly different views of the same information. Another option would be to add JavaScript show/hide to the podling index page, where clicking on a podling reveals expanded data. I'm not in favor of that (too much work) but I mention it as another alternative to creating new web pages. Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org For additional commands, e-mail: general-help@incubator.apache.org