On Fri, Aug 01, 2014 at 01:24:18PM +0200, Allan Day wrote: > Olav Vitters <[email protected]> wrote: > ... > > I've currently made two (unannounced except r-t; also not fully ready > > yet!) changes: > ... > > 4 Automatic "about" page: > > - Based on the DOAP file > > description, mailing lists, bugzilla link, weblinks, developer > > names (no email, for that there's bugzilla), screenshots, > > programming languages it is written in > > - Maybe only if enough interesting fields are in the doap file > > - Eventually auto link to latest tarball releases > > so tarball release needs to trigger a recreation of the about page > ... > > This all sounds awesome. > > > #4 might totally replicate the things in the Wiki. Further, I have no > > idea how to nicely show this. Especially once automated. Thoughts? > > I think the key question is whether we want a separate page or > web-site that lists our modules (by moduleset). We previously had > projects.gnome.org, and that was retired because it didn't get a huge > amount of attention, and because our own focus tends to be on the > wiki.
Release team used to list these per GNOME release. See e.g. https://wiki.gnome.org/TwoPointFifteen First priority is ensuring that git.gnome.org is showing the categories correctly. This will take a bit of time to sort out the details. This as we also have dependencies on git.gnome.org. This should either be added to "Core" or maybe added in a "Core deps" or something. I need to discuss with r-t members (there is already some discussion). I also want something to ensure that we don't ever have mismatches between what we release and the doap files. For that I'm planning to expand our release-team scripts and add a cross check in there. It already has some checks. I ran it yesterday and it seems we overlooked some of the output as it already warns about a few things. > Thinking in terms of objectives, my personal priority for us as a > project is to have a clearly identified moduleset listing that our > contributors are exposed to. Another issue with a dedicated page or Totally agree. You have two things: 1. The current moduleset 2. Historic modulesets (what is in GNOME 3.8) Latter is very annoying. I think #1 is very important. #2 can maybe be partly manual and slightly less integrated. > site that lists projects is that it would likely be separate from the > regular workflows of contributors. One of the issues with > projects.gnome.org was that people didn't use it a huge amount - since > we're mostly on the wiki, Bugzilla or git.gnome.org anyway. > > So, my suggestion would be to: > > 1. Ensure that Bugzilla and git.gnome.org are sorted according to the > modulesets - so that contributors are exposed to the modulesets within > their typical workflows, and to avoid creating yet another website. I'll work on Bugzilla as well. Each time you tackle another thing the details are annoying. Regarding Bugzilla: 1. The git link at the moment is totally unreliable (it just does a git.gnome.org/browse/$BUGZILLA_PRODUCT_NAME 2. Multiple doap files might point to the same Bugzilla product 3. Could be that these doap files have different categories 4. I don't want to touch the Bugzilla code, just focus first on ensuring the categories are right 5. There way to show things on Bugzilla might require changes in the doap files (e.g. additional categories, etc) Because of that I first want to get git.gnome.org right and only then fix Bugzilla, otherwise I go mad :-P. But it is part of the plan. > 2. Use this data in the various development websites, so they are more > interconnected. Each of the product pages in Bugzilla points to the > relevant git module, but it doesn't link to mailing lists. Likewise, > the summary page for each module on git.gnome.org could have outgoing > links to Bugzilla product pages, mailing lists, or wiki pages. What I want with this "about" page generated from doap is the following: http://git.zx2c4.com/cgit/about/ That's cgit (code behind https://git.gnome.org/browse/) upstream. We could auto generate this from the doap files rather easily. This "about" feature in cgit can even do subpages: http://git.zx2c4.com/cgit/about/faq However, that quickly becomes messy: I don't want random HTML on git.gnome.org and lots of other potential issues (too much to write down for now). DOAP spec allows a lot btw: https://github.com/edumbill/doap/blob/master/schema/doap.rdf It has a specific thing for a wiki link. So the auto generated "about" page would be a slightly nicer than just a boring list of links. -- Regards, Olav _______________________________________________ engagement-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/engagement-list
