On Tue, 25 Mar 2014, at 01:14 PM, sebb wrote: > On 25 March 2014 01:46, Marvin Humphrey <mar...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
