emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] Release 8.0


From: Carsten Dominik
Subject: Re: [O] Release 8.0
Date: Mon, 22 Apr 2013 22:06:23 +0200

On 22.4.2013, at 21:46, John Hendy <address@hidden> wrote:

> On Mon, Apr 22, 2013 at 1:32 PM, Carsten Dominik
> <address@hidden> wrote:
>> 
>> On 22.4.2013, at 19:17, Bastien <address@hidden> wrote:
>> 
>>> Hi Jay,
>>> 
>>> Jay Kerns <address@hidden> writes:
>>> 
>>>> On Sun, Apr 21, 2013 at 9:25 AM, Bastien <address@hidden> wrote:
>>>>> Hi Memnon,
>>>>> 
>>>>> Memnon Anon <address@hidden> 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.


Do you have commit access at the worg repository at orgmode.org?
Then it would be easiest to set it up there.  I could do it, but maybe you want 
to?

Basically:

You create a new branch in your repository:

$ git checkout -b worg-new-exporter

Then you push this new branch to the remote repository:

$ git push -u origin worg-new-exporter

Then you can work in this new branch and just push from this branch
whenever you want:

$ git push

Everybody else can hook onto this branch with

$ git checkout --track -b worg-new-exporter origin/worg-new-exporter

and then work in this branch and push it whenever they want.

> 
>> 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.

I agree, this would be easiest.  Organizing this would then mean
to announce to precise procedure on the mailing list and hope that people
hack away.

> 
>> 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.

Yes this is a good way.  Organizing then means to check for files
that have not been done and do them yourself or encourage other
directly to do it.

> 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.

Well, if you get everything working with the new exporter, we
will find a way to fix publishing if necessary.

> 
> 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.

We definitely do NOT stop to edit Worg in the mean time.  The master
branch can be edited in parallel.  This is git, so we can merge both
branches when the time comes.

It would be great if you can take a stab at this, John.

- Carsten

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]