I'm already doing a GitHub to prototype some of this. After some experiments, I will see what works best as a home for the full development.
I'm uncertain where the best place for the combination of materials and their documentation might be. - Dennis -----Original Message----- From: jan i [mailto:j...@apache.org] Sent: Sunday, June 21, 2015 08:14 To: dev@corinthia.incubator.apache.org; dennis.hamil...@acm.org Subject: Re: [DISCUSS] Corinthia Home for ODF Interoperability Assessment I too would prefer to have such documentation outside our source repo. If we need another git repo or svn repo, it is just a question of filing a jira, and we get it, so no need to make temporary repos. rgds jan i On Tuesday, June 16, 2015, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > Thanks Peter, > > Your questions and comments have led me to rethink this a little. > > 1. For temporary purposes, I am going to create a GitHub project that > carries some specimen and exemplary materials for a startup Document > Interop Assessment project. This is an easier place to demonstrate my > thinking and also not clutter up the Corinthia repo with material that will > go dead and should not clutter up the history. (For various reasons, I > would much rather have this be in an SVN repository because of how > repository-level versioning is handled automatically and how HTTP access > into SVN works well. I also have to satisfy myself about using Markdown > instead of HTML, since that creates more dependencies on any server housing > the materials. I think I'll check to see how HTML renders on web access to > a GitHub repository.) > > 2. The Interop Assessment material is not really something that is > produced in releases. There might be companion utilities that have > releasable source code and convenience binaries. However the Interop > Assessment material could become quite extensive and it makes no sense to > have there be some sort of overall release cadence. > I need to think what would be an appropriate place to house this that > is not tied to the release cadence of some project. > (I also think this is a matter for Corinthia itwself, in that there > are multiple components in what is a kind of suite of materials and having > an overall release of the code base might be a little peculiar. It seems > to be the wrong level for versioning of stuff.) > Perhaps it is better to think of this as a kind of library project, > where a big part of the library is a collection of data, documentation, and > instructions as well as a variety of (small?) utilities. Maybe code that > is developed for generic treatment of the material and assessment of > documents, conduct of tests, etc., is more appropriate for something like > Apache Commons. Then there are all the cases and their data. > > I am going to ask around Apache about this. Maybe some other places. > - Dennis > > -----Original Message----- > From: Peter Kelly [mailto:pmke...@apache.org <javascript:;>] > Sent: Monday, June 15, 2015 21:52 > To: dev@corinthia.incubator.apache.org <javascript:;> > Subject: Re: [DISCUSS] Corinthia Home for ODF Interoperability Assessment > > > On 16 Jun 2015, at 3:11 am, Dennis E. Hamilton <dennis.hamil...@acm.org > <javascript:;>> wrote: > > > > I want to start building specimen documents that fit the model of > interoperability assessment that is sketched (sketchily) at > > <https://cwiki.apache.org/confluence/display/Corinthia/ODF> under the > "ODF Conformance/Compliance Assurance helix." > > > > My thought is to create a branch having a folder, "InteropAssess" with > subfolder "ODF" to start a subtree of folders that develop specimens that > demonstrate particular aspects of ODF documents. These can be used as test > suites but are not intended to be the same as ad hoc tests created to > exercising particular Corinthia and DocFormats functions. Rather they are > addressed to the standards and any profiling of processors, with DocFormats > being only one. > > [ ... ] > > What sort of data volume do you think these are likely to consume? I’m > just thinking about repository size and keeping it manageable (to allow > people to quickly clone the repo if they want to build it). If it’s only a > few Mb or so, I’d say put them in the main repository, otherwise it might > be more appropriate to store these in a separate repository. Do you know if > Infra supports multiple repositories per project? > > > MY HESITATION > > > > I don't quite like putting these in a Git repository because it is > important and useful to cross-reference among the materials and I am not > clear how that can happen in a non-web repository system. I do know how to > make it work with a SubVersion repository because one can use the fact that > the SVN is part of a web site and can be navigated with a browser. One can > even put HTML pages in an SVN repository and use (relative) links to > cross-reference among the material. > > > > That is an extremely valuable way to do what I have in mind. > > > > Is this possible with the Corinthia Git repository? > > Yes - though with the caveat that it depends on there being a particular > server that contains a clone of the repository. For Corinthia, you can > access the files here: > > https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git > > And to reference a specific file: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-corinthia.git;a=blob_plain;f=DocFormats/CMakeLists.txt;hb=377421ecf076e553beedc075e2baef65a3e7e3b0 > > The main problem is that these URLs are not necessarily stable; > git-wip-us.apache.org will presumably become git-us.apache.org at some > point, and upon graduation our repository will be called corinthia instead > of incubator-corinthia. > > Another options - since our website is just static files, we could > alternatively host the files there (while still storing the documents in > the repository, and having a script which copies up the files to the site. > However this still has the problem of URL stability - > http://corinthia.incubator.apache.org would become > http://incubator.apache.org upon graduation. I’m not sure how important > URL stability is to you for this particular use case; if it’s not critical > then we should be ok with either of these options. > > Regarding the way in which the HTML structure on the website is done, this > would not have an impact, as the files could simply be placed in a separate > directory and be linked to from the main page. There’s nothing special or > abnormal that would need to be done here. > > — > Dr Peter M. Kelly > pmke...@apache.org <javascript:;> > > PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > > > -- Sent from My iPad, sorry for any misspellings.
