On 25 March 2014 06:14, David Crossley <cross...@apache.org> wrote: > 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.
However, there is lots of information in the status files that is not in podlings.xml, and some that is in podlings but not status. The overlap is currently very small compared with the total amount of information in both formats. The fields present in both are: * name * status (not always reflected in status page and very difficult to extract in any case) * description (not always the same) * mentors * start date (not easy to extract from status page) * end date (not easy to extract and is often not present) Podlings.xml only * sponsor * reporting details * resolution of graduated podlings * champion (might be in some status pages) * resource/resourceAliases Status page only * news * committer list * websites (may be more than one) * mailing lists (not necessarily derivable from data in podlings.xml) * bug tracker * link to source code (may be git, even svn URL not always obvious from podlings.xml, but perhaps could fix that) * links to incubation status reports * incubation work items For podlings that do make full use of their status file, it seems wrong to restrict the format unnecessarily. Which is why (if anything is to be done) I would favour having a way to import the podlings.xml data so the status file can easily make use of it. There may be one or two fields that could move into podlings.xml, but if it becomes too large it will become very difficult to edit. Imagine concatenating all the status files and editting that. > -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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
