Re: Release 8.0

[John Hendy <jw.hendy@gmail.com>]

On Mon, Apr 22, 2013 at 1:32 PM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
>
> On 22.4.2013, at 19:17, Bastien <bzg@gnu.org> wrote:
>
>> Hi Jay,
>>
>> Jay Kerns <gjkernsysu@gmail.com> writes:
>>
>>> On Sun, Apr 21, 2013 at 9:25 AM, Bastien <bzg@gnu.org> wrote:
>>>> Hi Memnon,
>>>>
>>>> Memnon Anon <gegendosenfleisch@googlemail.com> writes:
>>>
>>> [ snip ]
>>>
>>> Quick question: is it true, now that Org 8.0 has been released, that
>>> the engine which publishes Worg is now Org 8.0, too?
>>
>> No, not yet.
>>
>>> In other words, is it now safe to publish to Worg all of that stuff
>>> which was written compatible with the new exporter, without breaking
>>> Worg in the process?
>>
>> No.  Someone needs to carefully check he can exports his local clone
>> of worg.git with the new exporter, fix the wrong syntax, then commit
>> it.  This surely deserves a public branch of Worg, which people can
>> hack together.
>
>
> Thanks Bastien, I was about to write about this.
>
> We need a volunteer who is willing to coordinate the conversion
> of Worg to the new exporter.  This is an important task.  Dogfooding
> Worg to the new exporter will be a good way to find remaining bugs
> in the parser/exporter setup.
>
> This task would entail:
>
> 1. Creating a public branch of Worg for this work.

Can I just update my clone and push to github? If so, sure. I'd just
use my own github account (unpaid). If there's a better location,
suggest it or someone else can volunteer to host/create the clone if
they have better tools/access for this.

> 2. Creating and maintaining a file that contains a site map of Worg,
>    with all files that need publishing

I could take a stab at this, but it won't be instantaneous. If someone
has the time and energy to do this in the short term (< 1 week),
they'd be better. If a week or so is acceptable, I can take this one
as well, at least the creation part. I'm assuming it will be a big
todo list? From there, it would be much easier if editors updated it
themselves.

> 3. Organizing contributors who will look at one page after the other
>    and implementing any changes needed to make the page export (not yet
>    publish) cleanly with the new exporter.  In this way we need to walk
>    through all Worg files, and someone needs to keep the tabs on this.

Not sure we totally need to organize this. I'm wondering about
something like an "editor" property in the file from #2. Contributors
could self-assign by adding their name to that property in the tracker
file and then push. Perhaps an agenda view or simply column view could
quickly show who is assigned to what file?

> 4. When all this is done, see what changes have to be made to the
>    publishing setup to fix the automatic publishing.

I'd be really bad at this as I've never actually set up publishing. I
can definitely help with some of the #+attr_backend and general syntax
stuff, but I never got heavy into the site publishing features and
have never even looked at Worg's setup for this.

If this is the process... how does the public Worg get updated in the
mean time? I'm pretty new to git and only do basic stuff. Diffs have
always been intimidating (and I've found them to really stink even for
really, really small changes I've had). How will we maintain the
public site and then re-combine with the public one down the road?
Editing on the public one needs to happen in old syntax; public repo
for upgrade hacking needs to be in the new syntax.

Should we freeze Worg for the time being and direct editing to happen
at the other one?


Best regards,
John

>
> Any takers?
>
> Once we are done with this, we also need the orgmode.org website, but
> that contains fewer pages, so it should be a lot simpler.
>
> - Carsten
>
>