Sourceforge is still there. I clone my projects to it (and to github, bitbucket, google and gitorious). The joys of a DVCS. It's very simple to turn markdown into html and host that on IANA's page. Access control really isn't that hard when you have pull requests and the like. I do think Paul would want the ability to review all changes, but that doesn't preclude a tiered model where a few others might be trusted lieutenants whom n00bs like me might send changes to; which, once cleaned up, might then get sent to Paul. And doing it as a separate repo is cool too, though do note that github exports it's wiki as a repo as well. What might be interesting would be if IANA started using something like gitlab to host projects as its wiki system is similar to github's. As an aside, I have the following defined under [alias] in my ~/.gitconfig: dist = "!bash -c 'for r in $(git remote); do echo \"Pushing to $r\"; git push --all \"$r\"; git push --tags \"$r\"; done'" That allows me to push everything to every remote site I have defined with 'git dist'. So in Paul's case, he could push out his changes to a collection of code repos so end users could get tzinfo even if one or more are down (for those obsessed with availability). The wiki side is trickier as only some code hosting sites do wiki's as repos and even then have tighter restrictions than github on format (google uses it's own and I think bitbucket does as well). Kevin On Wed, Sep 11, 2013 at 8:19 AM, Lester Caine <lester@lsces.co.uk> wrote:
Kevin Lyda wrote:
Your experimental github repo comes with a wiki. You can make changes in the same way you do code changes.
It wouldn't be hugely difficult to render that into HTML to also be hosted at IANA.
I was waiting on someone saying that ;)
The problem with the github wiki and the sourceforge and other code management site wiki's is that they don't allow the sort of control that is needed to maintain what will be essentially a reference document to the decisions on data in the tz database itself. DVCS is good at managing packages of material making up a software project, but documents need a fine grain control, which the history mechanism does partially address, but access to update needs a different access model.
Personally I would still like to see a PAIR of DVCS repos, one with the tz data and a separate repo with the software. This will allow management of releases of the data along with a complete historic record which can then be used by alternate packages of software. In github terms, this repo could have an attached wiki that can be used to store submissions of evidence to the currently well know holes in the data. But the 'published' documents need to be a little more locked down?
At this stage I'm just saying that using's Paul's github account is not the right venue for a production repository and moving forward is reliance on a third party system a good idea? Remember sourceforge? Why are we not using that nowadays.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
-- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/