On Fri, May 08, 2015 at 11:39:59AM +1200, Kent Fredric wrote: > > Ok, this is an OK starting point for me. Its not *my* ideal because there's > of course the audience who have PAUSE keys and not github accounts ( and > don't want them ), but thats more a side note at this moment ( And was > inherently a likely contribution limitation to my suggestion w/ other > repos, just not their own )
No one needs to register anywhere to contribute to a git repository: if they want to go the hard route, git format-patch and git send-email are their friends. > I like that its got aggregation options, and that it can pull from > different locations. > > So can we talk about layout and authorship concerns? The following represents what cpan.io does now. It was put together in half a day. It's open source, and I welcome pull requests. So it's flexible. We can modify it to suit whatever need we have. > 1. How often do aggregated repositories get sourced? every hour. > 2. How easy is it to stipulate adding more repositories? Send a pull request for updating cpanio.yml to http://github.com/book/CPANio > 3. What mechanism is there for restricting what an automated update pulls I've put a few restrictions in the form of 'include' (defaults to *), 'exclude' (defaults to nothing), and recurse (defaults to don't). > so that only "finalised" docs are published, and not drafts? it can pull from a named branch, so you could have a "final" branch for those documents. > 4. How exactly are the sourced documents layed out Simple template with basic HTML around. For now, only markdown format is supported, but I intend to support additional formats as needed. > 5. How are we going to optimise our policy layout so its clear which > policies are newest Docs are listed in the order the repositories are listed in the yaml file, and then by creation date. > 6. How are we going to optimise our policy layout so its clear when a > policy was last modified The bottom of each document has a "Last modified by" line, based on the last commit on that file. > 7. How are we going to optimise our policy layout so its clear from a users > perspective what changes have happened recently in any policy. > > Point 5 is easily solved by the numerical sequencing we covered earlier. > > Points 6 and 7 are hard, but are presently satisfied by metacpan. I suppose we could have the date in the table of content, or even a "last modified" page. Generating a RSS file is also possible. > Keep in mind I'm trying for a solution here that we can apply to cpan.io > that covers project policies like Moose/DBIC/Catalyst as well as author > policies like Author::RIBASUSHI. I'm not sure author policies would fit in CPAN.io, but I guess we need to see how this evolves. > With regards to the latter half, we may be interested in a system where an > author can ship to both CPAN and integrate with the cpan.io website, or do > only one of the two, using the same codebase. For now, the authors had nothing special to do to have their documents supported on CPAN.io. I would be nice if it could stay this way. I tested with toolchain-site to show up the Oslo and Lancaster consensus documents, and they showed up just fine. I don't foresee any special difficulty in publishing a set of pod documents living on CPAN. > Or they may wish to simply host their policies on their own somewhere. That's probably what most people do at the moment. > Either way, we should pave a path for interop to make it easy to do the > right thing. > > > I would probably also consider a JSON/YAML file being listed in each policy > root that acheives some of the above concerns: > - associates policies with tags > - define desired policy presentation order > - define visibility of policies at the top level ( ie: so that deprecated > policies don't list on the main lists ) > > etc. Good idea! This special config file should be optional, though. -- Philippe Bruhat (BooK) Sometimes only by losing the battle can you win the war. (Moral from Groo The Wanderer #117 (Epic))
