incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: Rearrange the "Project List" into multiple pages?
Date Tue, 25 Mar 2014 06:14:21 GMT
On Tue, 25 Mar 2014, at 01:14 PM, sebb wrote:
> On 25 March 2014 01:46, Marvin Humphrey <marvin@rectangular.com> wrote:
> > 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.
> 
> I think that's not the case.
> 
> > If certain values are not in sync, I think we should acknowledge that and fix
> > our DRY problems rather than add more duplication.
>
> podlings.xml was introduced because the status pages don't include the
> data in a usable fashion for automated processing.
> It's also useful to have the basic information in a single file which
> can be subject to DTDs etc.
> The status files are free-form xml/xhtml

Also the podlings.xml was introduced because projects
do not keep their status pages up-to-date.

Being more concise it should be easier to manage,
and tools can verify it and utilise it.

> Maybe it would be possible to automate the inclusion of the relevant
> bits from podlings.xml into the individual status files.
> But that seems like a lot of work for not much reward.

The last time that we went through this, there was a suggestion to
trim the status page template to just provide links to the various bits
of summary information that are generated from podlings.xml file.

-David

> >> 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.
> 
> The problem is that the current page has useful information but has
> become unwieldy.
> Rather than just split it 3, I think a summary would be useful.
> There's no full alphabetical listing of all podling names currently so
> this provides a useful additional resource.
> 
> > 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


Mime
View raw message