Conflicts pushed

[tschaub]

It looks like this commit was committed/pushed without resolving merge conflicts. While I think forced pushes are Very Bad Practice on shared repositories, at this point, I'd be in favor of doing a hard reset to be82b46 and starting over with discussion on the recently closed pull requests (#1, #2, #3).

Alternatively, those commits could be reverted with another commit.

I'd also like to establish what gets edited and what gets generated. I'd be in favor of having only a single set of sources in the master branch. We could use a gh-pages branch for built artifacts (see #5).

If people are in favor, I'll do a hard reset to be82b46, and we can start over with #1, #2, and #3.

[sthagen]

I am a bit concerned, if we will end up doing the same edits twice or more often, when we discuss in so many places plus the mailing list partly overlapping aspects. My proposal would be more, to continue with the current revision.

Discussing the individual pull requests on a per request basis should be feasible though, as it is very little text we are talking about, right?

[tschaub]

As @sgillies commented, starting from 8543af5 makes sense.

Pull request #2 needs discussion, this is clear - the pull request was supposed to initiate discussion. And I don't think it makes sense to push commits with conflicts (and I mean git conflicts not philosophical ones).

As mentioned in the comments, pull request #3 is better addressed by removing the text about polygon validity (instead of just changing it so it is more correct).

[tschaub]

Thanks for any review. Will merge if this looks good to others.

Some notes:

• I didn't do a hard reset and force push. Instead we have the full history for posterity.
• There wasn't a clean way to tease apart the "merges" in 61b8374 and df367f7, so I created new commits.
• I didn't touch the built docs (xml, txt, html, etc) because I think those should be addressed separately (see Use gh-pages branch for built docs #5). So those are out of date. Will update if people think we should have built docs in master.

[tschaub]

@sgillies and @sdrees - any comment here? It makes sense to me to at least remove the existing conflicts. I'll add the other formats if that would make this more complete (they also have evidence of the conflicts).

[sgillies]

@tschaub +1 from me. @sdrees?

[sthagen]

Am 16.05.13 21:30, schrieb Sean Gillies:

@tschaub https://github.com/tschaub +1 from me. @sdrees
https://github.com/sdrees?

—
Reply to this email directly or view it on GitHub
#4 (comment).

just go ahead and I could clone afterwards in an empty folder, rebuild
the generated stuff once, push upstream and based on that Tim might
start the Travis based refactoring.

All the best,
Stefan.

[tschaub]

@sdrees I'm not able to build the docs, so I'll take you up on that offer.

I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
-:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
                  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
                                                                           ^
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
-:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
                  "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
                                                                           ^
ERROR: Unable to validate the XML document: template.xml
 template.xml: Line 96: Element back content does not follow the DTD, expecting (references* , section*), got (references references t t section section section section section section section section )

I'm assuming the first two I/O errors are due to pandoc2rfc calling xsltproc --nonet. The validation error looks to be choking on the &pandocBack; entity in template.xml. Not sure how that is supposed to work.

Anyway, I still think it makes sense to have us edit just the markdown. It seems easiest to me to have people issue pull requests for changes just to middle.mkd and back.mkd.

If you can provide any hints on overcoming the validation error, I'd like to try building the docs again. If you do it, my preference would be to see them go in the gh-pages branch.

git checkout -b gh-pages master
pandoc2rfc ...
git add .
git commit -m 'Adding built docs'
git push origin gh-pages

After that, we can merge from master into gh-pages after merging pull requests and rebuild the docs.

[sthagen]

Hi Tim,

I rebuilt the target sources and pushed upstream all in branch gh-pages.

Note: There seem to be still traces of the initial April date inside the
current master template.xml I guess.
But as everyone is happy issuing pull requests, I think this might be
cleaned up by someone else :-)

Please advice what the next steps are to have directly visible draft.txt
and draft.html so I can support and I know with what to update the links
in my stub repo (as these URLs
are archived in the mailing list archive).

If and when I get notified by new pulls/merges, I will always rebuilt in
branch gh-pages and push upstream.

All the best,
Stefan.

Am 17.05.13 02:01, schrieb Tim Schaub:

@sdrees https://github.com/sdrees I'm not able to build the docs, so
I'll take you up on that offer.

|I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
-:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
^
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd
-:3: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
^
ERROR: Unable to validate the XML document: template.xml
template.xml: Line 96: Element back content does not follow the DTD, expecting (references* , section*), got (references references t t section section section section section section section section )
|

I'm assuming the first two I/O errors are due to pandoc2rfc calling
|xsltproc --nonet|. The validation error looks to be choking on the
|&pandocBack;| entity in |template.xml|. Not sure how that is supposed
to work.

Anyway, I still think it makes sense to have us edit just the
markdown. It seems easiest to me to have people issue pull requests
for changes just to |middle.mkd| and |back.mkd|.

If you can provide any hints on overcoming the validation error, I'd
like to try building the docs again. If you do it, my preference would
be to see them go in the |gh-pages| branch.

|git checkout -b gh-pages master
pandoc2rfc ...
git add .
git commit -m 'Adding built docs'
git push origin gh-pages
|

After that, we can merge from |master| into |gh-pages| after merging
pull requests and rebuild the docs.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[tschaub]

Thanks @sdrees. I appreciate all the work you've done putting this together. I'm not sure I understand you correctly, but if you're looking for the hosted drafts, see http://geojsonwg.github.io/draft-geojson/draft.html et al.

Out of curiosity, do you have any hints on how I can get around the validation issues with template.xml?

[sthagen]

Thanks @tschaub that was the missing link. If you look e.g.. at the archived mail http://lists.geojson.org/pipermail/geojson-geojson.org/2013-April/000731.html it has links pointing to https://raw.github.com/sdrees/geojson/master/draft.txt (among others) and I just want to not have people strand on HTTP 404s or rotten bits, when following links that are only about two weeks old ;-)
So now, they find a text (as promised by ".txt" that states: "Working copy moved on 2013-04-30. Current URL:
http://geojsonwg.github.io/draft-geojson/draft.txt". I am happy.

I will look into providing a recipe for the funny convoluted procedure of generating text from text going a looong way. I had to patch the tools to get them working for me, but if you have no time, you do not also document, right :-?)
What I remember was, that the naive use of (ba)sh variables eg. in the Makefile of pandoc2rfc made me a bit nervous about the overall quality, but then the results after adapting a bit or two were fully sufficient and open enough. Sample from Makefile: mkdir -p $(DESTDIR)/usr/bin shiver.
Promised, will support there, but maybe after the long weekend. Ok?