[tz] Using MediaWiki / Wikidata

Kevin Lyda kevin at ie.suberic.net
Wed Sep 11 08:57:23 UTC 2013


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 at 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/


More information about the tz mailing list