emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* Thanks for Lilypond export (and minor comments)
@ 2011-07-07 16:38 Torsten Anders
  2011-07-07 20:01 ` Bastien
  0 siblings, 1 reply; 16+ messages in thread
From: Torsten Anders @ 2011-07-07 16:38 UTC (permalink / raw)
  To: emacs-orgmode

Dear Martyn Jago,

Congratulations to the Lilypond support included in the new Org version 7.6!  For someone who uses both Org-mode and Lilypond anyway (like me :), this is great to have!

Some brief comments. Support for additional languages like Lilypond and also awk should be celebrated by including them in the list of languages in the documentation (http://orgmode.org/org.html#Languages).

I first had to load dot support (because you are calling org-babel-expand-body:dot). If you want to also attract musicians (without Org-programming experience themselves) it might be a good idea to very clearly document this dependency (or to remove it).

Thank you! 

Best wishes,
Torsten

--
Dr Torsten Anders
Course Leader, Music Technology
University of Bedfordshire
Park Square, Room A315
http://strasheela.sourceforge.net
http://www.torsten-anders.de

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-07 16:38 Thanks for Lilypond export (and minor comments) Torsten Anders
@ 2011-07-07 20:01 ` Bastien
  2011-07-08  1:35   ` Eric Schulte
  0 siblings, 1 reply; 16+ messages in thread
From: Bastien @ 2011-07-07 20:01 UTC (permalink / raw)
  To: Torsten Anders; +Cc: emacs-orgmode

Hi Torsten,

Torsten Anders <torsten.anders@beds.ac.uk> writes:

> Some brief comments. Support for additional languages like Lilypond and
> also awk should be celebrated by including them in the list of languages in
> the documentation (http://orgmode.org/org.html#Languages).

Fixed in latest org.texi -- thanks!

> I first had to load dot support (because you are calling
> org-babel-expand-body:dot). If you want to also attract musicians (without
> Org-programming experience themselves) it might be a good idea to very
> clearly document this dependency (or to remove it).

I let Martyn or Eric put a stab at this.

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-07 20:01 ` Bastien
@ 2011-07-08  1:35   ` Eric Schulte
  2011-07-08  6:13     ` Bastien
  2011-07-08  7:56     ` Martyn Jago
  0 siblings, 2 replies; 16+ messages in thread
From: Eric Schulte @ 2011-07-08  1:35 UTC (permalink / raw)
  To: Bastien; +Cc: Torsten Anders, emacs-orgmode

Bastien <bzg@altern.org> writes:

> Hi Torsten,
>
> Torsten Anders <torsten.anders@beds.ac.uk> writes:
>
>> Some brief comments. Support for additional languages like Lilypond and
>> also awk should be celebrated by including them in the list of languages in
>> the documentation (http://orgmode.org/org.html#Languages).
>
> Fixed in latest org.texi -- thanks!
>
>> I first had to load dot support (because you are calling
>> org-babel-expand-body:dot). If you want to also attract musicians (without
>> Org-programming experience themselves) it might be a good idea to very
>> clearly document this dependency (or to remove it).
>
> I let Martyn or Eric put a stab at this.
>
> Thanks,

Thanks for finding this error Torsten!  I've just pushed up a fix.

Bastien,

is there a process for bug-fix commits like this one which should be
pushed through to Emacs24?  I'm thinking a branch (maintenance?) to
which this should be pushed or a special way to tag the commit?

Thanks -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  1:35   ` Eric Schulte
@ 2011-07-08  6:13     ` Bastien
  2011-07-08  7:00       ` Nick Dokos
  2011-07-08 21:00       ` Achim Gratz
  2011-07-08  7:56     ` Martyn Jago
  1 sibling, 2 replies; 16+ messages in thread
From: Bastien @ 2011-07-08  6:13 UTC (permalink / raw)
  To: Eric Schulte; +Cc: Torsten Anders, emacs-orgmode

Hi Eric,

Eric Schulte <schulte.eric@gmail.com> writes:

> Thanks for finding this error Torsten!  I've just pushed up a fix.

Thanks.

> Bastien,
>
> is there a process for bug-fix commits like this one which should be
> pushed through to Emacs24?  I'm thinking a branch (maintenance?) to
> which this should be pushed or a special way to tag the commit?

there is none for now -- I need to think about it.

As I will need a few hours more to create the ChangeLog between 7.5 
and 7.6 for Emacs (yeah!), I plan to make a minor release 7.6.1 that
will be the one we'll have in Emacs.  Probably tomorrow morning or 
sunday morning.

So this fix will go thru Emacs, then we can think about a better
process.  Detailed suggestions from git power users welcome!

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  6:13     ` Bastien
@ 2011-07-08  7:00       ` Nick Dokos
  2011-07-08  9:08         ` Bastien
  2011-07-08 21:00       ` Achim Gratz
  1 sibling, 1 reply; 16+ messages in thread
From: Nick Dokos @ 2011-07-08  7:00 UTC (permalink / raw)
  To: Bastien; +Cc: nicholas.dokos, Torsten Anders, emacs-orgmode

Bastien <bzg@altern.org> wrote:

> > is there a process for bug-fix commits like this one which should be
> > pushed through to Emacs24?  I'm thinking a branch (maintenance?) to
> > which this should be pushed or a special way to tag the commit?
> 
> there is none for now -- I need to think about it.
> 
> As I will need a few hours more to create the ChangeLog between 7.5 
> and 7.6 for Emacs (yeah!), I plan to make a minor release 7.6.1 that
> will be the one we'll have in Emacs.  Probably tomorrow morning or 
> sunday morning.
> 
> So this fix will go thru Emacs, then we can think about a better
> process.  Detailed suggestions from git power users welcome!
> 

I'm not sure whether I posted this before but if you haven't seen
it before, it's probably worth reading:

   http://nvie.com/posts/a-successful-git-branching-model/

There is a set of tools that supports this kind of workflow at

   https://github.com/nvie/gitflow

Nick

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  1:35   ` Eric Schulte
  2011-07-08  6:13     ` Bastien
@ 2011-07-08  7:56     ` Martyn Jago
  1 sibling, 0 replies; 16+ messages in thread
From: Martyn Jago @ 2011-07-08  7:56 UTC (permalink / raw)
  To: emacs-orgmode

Hi

>>> I first had to load dot support (because you are calling
>>> org-babel-expand-body:dot). If you want to also attract musicians (without

>Thanks for finding this error Torsten!  I've just pushed up a fix.


Thanks Torsten for the heads-up, and 
thanks Eric for the rapid response.

Regards

Martyn

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  7:00       ` Nick Dokos
@ 2011-07-08  9:08         ` Bastien
  2011-07-08 16:02           ` Suvayu Ali
  0 siblings, 1 reply; 16+ messages in thread
From: Bastien @ 2011-07-08  9:08 UTC (permalink / raw)
  To: nicholas.dokos; +Cc: Torsten Anders, emacs-orgmode

Hi Nick,

Nick Dokos <nicholas.dokos@hp.com> writes:

> I'm not sure whether I posted this before but if you haven't seen
> it before, it's probably worth reading:
>
>    http://nvie.com/posts/a-successful-git-branching-model/

Nice read -- thanks.

In fact, we *do* have a documented process for important fixes 
that need to go to the maint branch.  See README_maintainer:

,----[ Minor releases ]
| The release number for minor releases look like this:  =7.13.01=
| 
| Minor releases are small amends to main releases.  Usually they fix
| critical bugs discovered in a main release.  Minor bugs are not
| fixed - they will be adressed in the next main release.  Only the fix
| to the bug is bundled into a release, without the main development
| work going on in the master branch.  Since the bug fix will also be
| needed in the master branch, usually the fix is made in master and
| then cherry-picked into maint.  When this is done, a release is made
| from maint with this command:
| 
| : make fixrelease TAG=7.13.01
`----

So in the case Eric raised, I would ideally cherry-pick important fixes
from the master branch to the maint branch then make a release based on
this maint branch.

I think this makes sense when the master (development) branch is quite
unstable, with several untested features.

As long that I'm confident many testers use the latest master branch, 
I'm reluctant to go through the hassle of cherry-picking commits...  
and just release a minor release with all latest dev from master.

Call me lazy, but I'd rather keeping things simple here.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  9:08         ` Bastien
@ 2011-07-08 16:02           ` Suvayu Ali
  2011-07-09  8:44             ` Bastien
  0 siblings, 1 reply; 16+ messages in thread
From: Suvayu Ali @ 2011-07-08 16:02 UTC (permalink / raw)
  To: Bastien; +Cc: nicholas.dokos, emacs-orgmode, Torsten Anders

Hi Bastien,

On Fri, 08 Jul 2011 11:08:07 +0200
Bastien <bzg@altern.org> wrote:

> As long that I'm confident many testers use the latest master branch, 
> I'm reluctant to go through the hassle of cherry-picking commits...  
> and just release a minor release with all latest dev from master.
> 
> Call me lazy, but I'd rather keeping things simple here.

Maybe the development model followed by git itself would be a good
solution (merges instead of cherry-picking)? Although I fear org is a
much smaller project compared to git and it could be an overkill.

http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt

Hope this helps.

-- 
Suvayu

Open source is the future. It sets us free.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08  6:13     ` Bastien
  2011-07-08  7:00       ` Nick Dokos
@ 2011-07-08 21:00       ` Achim Gratz
  2011-07-09  8:46         ` Bastien
  1 sibling, 1 reply; 16+ messages in thread
From: Achim Gratz @ 2011-07-08 21:00 UTC (permalink / raw)
  To: emacs-orgmode

Bastien <bzg@altern.org> writes:
>> is there a process for bug-fix commits like this one which should be
>> pushed through to Emacs24?  I'm thinking a branch (maintenance?) to
>> which this should be pushed or a special way to tag the commit?
>
> there is none for now -- I need to think about it.

Pure fixes should probably be applied on top of maint and then merged
into master (not cherry-picked from master to maint, this would create
duplicate history).  On occasion this might produce a merge conflict,
but these instances should be rare.

That way maint would be a stable, but still regularly bugfixed branch
without having all the excitement of living on master and having old
features pulled from under you while the new features aren't quite there
yet.  If any larger bugs crop up, you can always tag a sub-release on
maint and create a package for anyone not using git.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08 16:02           ` Suvayu Ali
@ 2011-07-09  8:44             ` Bastien
  2011-07-10 16:50               ` Suvayu Ali
  0 siblings, 1 reply; 16+ messages in thread
From: Bastien @ 2011-07-09  8:44 UTC (permalink / raw)
  To: Suvayu Ali; +Cc: nicholas.dokos, emacs-orgmode, Torsten Anders

Hi Suvayu,

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> Maybe the development model followed by git itself would be a good
> solution (merges instead of cherry-picking)? Although I fear org is a
> much smaller project compared to git and it could be an overkill.
>
> http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt

Nice read, thanks.

I guess the relevance of such a development model mainly depends on how
many developers are trying to collaborate, and at what pace.

Let's see if a problem emerges from our current development model, and
how to fix it then.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-08 21:00       ` Achim Gratz
@ 2011-07-09  8:46         ` Bastien
  0 siblings, 0 replies; 16+ messages in thread
From: Bastien @ 2011-07-09  8:46 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-orgmode

Hi Achim,

Achim Gratz <Stromeko@nexgo.de> writes:

> Pure fixes should probably be applied on top of maint and then merged
> into master (not cherry-picked from master to maint, this would create
> duplicate history).  On occasion this might produce a merge conflict,
> but these instances should be rare.
>
> That way maint would be a stable, but still regularly bugfixed branch
> without having all the excitement of living on master and having old
> features pulled from under you while the new features aren't quite there
> yet.  If any larger bugs crop up, you can always tag a sub-release on
> maint and create a package for anyone not using git.

Yes, AFAIU that's what is described in README_maintainer.

I will try to stick to this process.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-09  8:44             ` Bastien
@ 2011-07-10 16:50               ` Suvayu Ali
  2011-07-11 16:50                 ` Bastien
  0 siblings, 1 reply; 16+ messages in thread
From: Suvayu Ali @ 2011-07-10 16:50 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

Hi Bastien,

On Sat, 09 Jul 2011 10:44:45 +0200
Bastien <bzg@altern.org> wrote:

> > http://www.kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt  
> 
> Nice read, thanks.
> 
> I guess the relevance of such a development model mainly depends on
> how many developers are trying to collaborate, and at what pace.
> 
> Let's see if a problem emerges from our current development model, and
> how to fix it then.

Of course. :)

A model based on Junio's notes just came to my mind and I thought maybe
I should share it just so that it stays in the archive for the future.

So far I think we can break down the development of org into certain
feature enhancements or new features and bug fixes. So maybe there
could be topic branches based on master for the various features
(lists, babel, latex export, odt export, any future attempt at code
refactoring and so on) and a bugfix branch based on maint.

Since usually a small set of devs work on each feature, it might be
easier to collaborate and be more adventurous (since its not a change
to master) during development. Also this would mean people interested
in a specific feature could simply pull in the HEAD of these branches
from time to time. And once the feature devs think the enhancements are
relatively stable, you could pull it into master (a simple two way
merge).

Now since the bugfix branch is based on maint, it will be a lot easier
to release critical fixes and could be merged into all branches (any
topic branch or master). This will let you release point releases very
easily (just fast-forward maint and tag). Master could host
documentation or other non-critical bug fixes.

For major releases you would need to do a few three-way merges (i.e.
pulling several topic branches into master or pulling the bugfix branch
into master) and finally make a commit changing the release tags and
version strings and merge into maint and tag it as release_<n+1>. Then
the bugfix branch could be fast-forwarded to the new release and the
process can start over again.

To summarise, the above is solely based on merges and no need for
tracking down individual commits (unless something goes wrong of
course :-p). This makes full use of git's capability of three way
merges and hopefully simplifies a lot of the maintainer tasks. :)

PS: On the downside this does imply you would have to understand the
various merge strategies git uses very well. :-p

-- 
Suvayu

Open source is the future. It sets us free.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-10 16:50               ` Suvayu Ali
@ 2011-07-11 16:50                 ` Bastien
  2011-07-11 17:50                   ` suvayu ali
  2011-07-19 12:29                   ` Bernt Hansen
  0 siblings, 2 replies; 16+ messages in thread
From: Bastien @ 2011-07-11 16:50 UTC (permalink / raw)
  To: Suvayu Ali; +Cc: emacs-orgmode

Hi Suvayu,

thanks for sharing this suggestion and to make it so clear.

I understand the model you describe and I see why it's appropriate for
projects like "git" -- as IIUC, your proposal is very close to the one
described by git's maintainer.

Let me summarize my ideas about how we should use git for Org.

I have three principles.

(1) git should reduce maintainer(s)'s work
(2) git should let more developers submit patches
(3) git should ease collaboration on fixes and new features

I put them here in priority order.

Yes, it means that I'm more interested in being lazy than in having more
patches, and in having more patches than in easing collaboration between
developers.

I think it works so far for three reasons:

- I'm not *that* lazy :)

- The latest git HEAD is stable enough so that many people live on it,
  and can send feedback on patches.

- Contributors rarely need to collaborate on fixes and features and when
  they do so, they collaborate by discussing on the mailing list.

More branches (master, maint, feature-1,...) means more _incompressible_
work for the maintainers, even when they are ninjas of the git Three Way
Merges.  This additional work is only worth undertaking when people are
*really* using the branches to collaborate -- which is quite unlikely to
happen given the three reasons above, and also given the fact that the
release pace of stable versions is quite fast.

Last but not least, sticking to the current usage of git (i.e. commit
into master as much as possible, commit only to maint for bugfixes that
need to be released independantly) doesn't prevent using public branches
from time to time -- we did it with Julien Danjou before.

Hope it helps understanding my approach!

It's all based on the idea "if it works, don't break it".

But I'm open to any change if (and when) we need it.

Best,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-11 16:50                 ` Bastien
@ 2011-07-11 17:50                   ` suvayu ali
  2011-07-19 12:29                   ` Bernt Hansen
  1 sibling, 0 replies; 16+ messages in thread
From: suvayu ali @ 2011-07-11 17:50 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

Hi Bastien,

On Mon, Jul 11, 2011 at 6:50 PM, Bastien <bzg@altern.org> wrote:
> This additional work is only worth undertaking when people are
> *really* using the branches to collaborate -- which is quite unlikely to
> happen given the three reasons above

I failed to consider the above bit of information when I wrote my
earlier email. Given the above, the present development model makes
good sense (simplicity being its _strongest_ point). :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-11 16:50                 ` Bastien
  2011-07-11 17:50                   ` suvayu ali
@ 2011-07-19 12:29                   ` Bernt Hansen
  2011-07-19 12:40                     ` suvayu ali
  1 sibling, 1 reply; 16+ messages in thread
From: Bernt Hansen @ 2011-07-19 12:29 UTC (permalink / raw)
  To: Bastien; +Cc: emacs-orgmode

Bastien <bzg@altern.org> writes:

> Hi Suvayu,
>
> thanks for sharing this suggestion and to make it so clear.
>
> I understand the model you describe and I see why it's appropriate for
> projects like "git" -- as IIUC, your proposal is very close to the one
> described by git's maintainer.
>

> - The latest git HEAD is stable enough so that many people live on it,
>   and can send feedback on patches.

> It's all based on the idea "if it works, don't break it".
>
> But I'm open to any change if (and when) we need it.

Here's my take on Suvayu's proposal.

Personally I don't think it makes sense to keep separate topic branches
in the public git repo for major parts of org-mode functionality since
that would require merging the branches to master to get all of the
functionality.  Topic branches (even for the git project) are generally
short-lived and for the developer's current set of patches until the
feature is merged into master.  At that point the developer normally
deletes the topic branch.

Junio (the git maintainer) keeps topic branches in his git development
repo for active topics which are merged to maint, master, next, and pu
integration branches.  Only the integration branches are normally pushed
to the public git repo that everyone clones.  When a topic branch is
merged to maint, or master it is normally deleted.

Lots of people use org-mode for different aspects of the functionality
it provides - I doubt anyone uses *all* of the features available in
org-mode - I know I don't.

The main advantage I see of keeping the current model is that people
(including me) run directly from the tip of the master branch - I
usually update at least weekly.  This has the advantage that users who
do this are testing the current development codebase and reporting
problems early as they are encountered.  This helps to fix problems
early before it's time to create a new release.

With Suvayu's model you would only merge for the release and that means
the new master won't have the same level of testing exposure before a
release is created.  We don't have full coverage of org-mode's features
in the ERT testing framework (far from it) and the more day-to-day
testing we get during development the better.

Regards,
-- 
Bernt

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: Thanks for Lilypond export (and minor comments)
  2011-07-19 12:29                   ` Bernt Hansen
@ 2011-07-19 12:40                     ` suvayu ali
  0 siblings, 0 replies; 16+ messages in thread
From: suvayu ali @ 2011-07-19 12:40 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: Bastien, emacs-orgmode

On Tue, Jul 19, 2011 at 2:29 PM, Bernt Hansen <bernt@norang.ca> wrote:
> With Suvayu's model you would only merge for the release and that means
> the new master won't have the same level of testing exposure before a
> release is created.  We don't have full coverage of org-mode's features
> in the ERT testing framework (far from it) and the more day-to-day
> testing we get during development the better.
>

Yes, this is the reason why in my original post I commented this model
might be better suited for larger and more complicated projects (where
a more stable master might be desirable). :)

In any case, I had proposed the model just as another (remote)
possibility. But I think we agreed the current model seems to work
best right now. :)

> Regards,
> --
> Bernt

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2011-07-19 12:41 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-07 16:38 Thanks for Lilypond export (and minor comments) Torsten Anders
2011-07-07 20:01 ` Bastien
2011-07-08  1:35   ` Eric Schulte
2011-07-08  6:13     ` Bastien
2011-07-08  7:00       ` Nick Dokos
2011-07-08  9:08         ` Bastien
2011-07-08 16:02           ` Suvayu Ali
2011-07-09  8:44             ` Bastien
2011-07-10 16:50               ` Suvayu Ali
2011-07-11 16:50                 ` Bastien
2011-07-11 17:50                   ` suvayu ali
2011-07-19 12:29                   ` Bernt Hansen
2011-07-19 12:40                     ` suvayu ali
2011-07-08 21:00       ` Achim Gratz
2011-07-09  8:46         ` Bastien
2011-07-08  7:56     ` Martyn Jago

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).