On Mon, Dec 28, 2009 at 08:26:51PM -0700, Colin Campbell wrote:
> Graham Percival wrote:
>> I don't think we should ask new contributors to do this. I've added
>> it to the CG as a responsibility for mentors to inform their
>> contributors if they'll need a make clean or make doc-clean.
>
> It see
Graham Percival wrote:
2009/12/29 John Mandereau :
Le mardi 29 décembre 2009 à 00:00 +, Graham Percival a écrit :
If "make" ever ends with an error, just send it to
lilypond-devel.
... and monitor -devel list for messages about infrastructure changes
where a developper explicitly request
2009/12/29 John Mandereau :
> Le mardi 29 décembre 2009 à 00:00 +, Graham Percival a écrit :
>> If "make" ever ends with an error, just send it to
>> lilypond-devel.
>
> ... and monitor -devel list for messages about infrastructure changes
> where a developper explicitly requests everybody to
Le mardi 29 décembre 2009 à 00:00 +, Graham Percival a écrit :
> It's _just_ possible that some change won't be picked up by "make" and
> will require a rebuild from scratch, but this only occurs once or
> twice a year.
True, "make" is known to be more robust than "make doc" in non-clean
build
On Mon, Dec 28, 2009 at 11:52 PM, Colin Campbell wrote:
> Carl Sorensen wrote:
>> If you're only working on docs (i.e. no code changes), there's no need to
>> run make before make doc, IIUC.
>
> Noob question: is it likely that a change in the binary, overlooked by not
> doing a make, would break
On Mon, Dec 28, 2009 at 11:46 PM, Colin Campbell wrote:
> Graham Percival wrote:
>
>
> A precis like this would be *gold* in the CG!
Heh, thanks. That's why I keep on arguing for a set of simple,
copy&pasteable commands.
Admittedly, the new lily-git does this already... say, have you tried
that
Carl Sorensen wrote:
If you're only working on docs (i.e. no code changes), there's no need to
run make before make doc, IIUC.
Carl
Noob question: is it likely that a change in the binary, overlooked by
not doing a make, would break the docs, in the sense of changing
documented behaviou
Graham Percival wrote:
Start: blindly copy&paste from:
- 1.1.2
- 1.1.3
Then, before you start working each day, you blindly copy&paste the
first item from
- 1.2.2
Then you edit whatever file with whatever editor you want (graphical,
command-line, raw manipulation of bits on the hard drive by h
Le lundi 28 décembre 2009 à 21:00 +, Graham Percival a écrit :
> If you want to figure out how to do this, go ahead. But I thought the
> general idea was to do the minimum amount of screwing with the old
> make system, and instead just to collect requests for the new build
> system?
Sure, for
2009/12/28 John Mandereau :
> Le lundi 28 décembre 2009 à 20:33 +, Graham Percival a écrit :
>> Ok, added.
>
> Better would be adding this in the right makefile.
If you want to figure out how to do this, go ahead. But I thought the
general idea was to do the minimum amount of screwing with th
Le lundi 28 décembre 2009 à 20:33 +, Graham Percival a écrit :
> Ok, added.
Better would be adding this in the right makefile.
> That said, as far as I know nobody's used EXTERNAL_BINARY in at least
> half a year, so it's probably broken by now. It would be nice if
> somebody tried it out b
2009/12/28 John Mandereau :
> Le lundi 28 décembre 2009 à 20:25 +, Graham Percival a écrit :
>> On Mon, Dec 28, 2009 at 09:15:50PM +0100, John Mandereau wrote:
>> > make -C scripts && make -C python
>>
>> Oh, it needs scripts? The CG only mentions make -C python.
>
> It has needed them since w
Le lundi 28 décembre 2009 à 20:25 +, Graham Percival a écrit :
> On Mon, Dec 28, 2009 at 09:15:50PM +0100, John Mandereau wrote:
> > make -C scripts && make -C python
>
> Oh, it needs scripts? The CG only mentions make -C python.
It has needed them since we started using build scripts in
scr
On Mon, Dec 28, 2009 at 09:15:50PM +0100, John Mandereau wrote:
> Le lundi 28 décembre 2009 à 19:07 +, Graham Percival a écrit :
> > If you do "make EXTERNAL_BINARY doc", then you don't need "make" at all.
>
> yes... except
>
> make -C scripts && make -C python
Oh, it needs scripts? The CG
Le lundi 28 décembre 2009 à 19:07 +, Graham Percival a écrit :
> If you do "make EXTERNAL_BINARY doc", then you don't need "make" at all.
yes... except
make -C scripts && make -C python
Best,
John
signature.asc
Description: Ceci est une partie de message numériquement signée
_
Graham Percival wrote:
> What about making 2.2 Getting source, then 2.3 basic
> procedures, etc ? That way, all the git stuff is still in
> the same chapter, but no section/subsection is
> unreasonably long.
You're proposing something like this?
1. Introduction to contributing
2. Working with so
Trevor Daniels wrote:
Carl Sorensen wrote Monday, December 28, 2009 5:25 AM
Oh, I agree that it would have the added benefit of a greater
audience, but
it would also cost more time for Mark to get it into the Git
documentation
instead of into the LilyPond documentation.
[...etc]
Many than
On Mon, Dec 28, 2009 at 5:43 PM, Colin Campbell wrote:
> A one of the newer of noobs, I can testify that the biggest problems I'm
> having with git are not seeing how git becomes aware of changes I might
> make: do I edit from within { git gui/gitk/lilycontrib } or use an external
> editor,
Start
On 12/28/09 11:22 AM, "Mark Polesky" wrote:
> Graham Percival wrote:
>> What about making 2.2 Getting source, then 2.3 basic
>> procedures, etc ? That way, all the git stuff is still in
>> the same chapter, but no section/subsection is
>> unreasonably long.
>
> You're proposing something lik
On Mon, Dec 28, 2009 at 6:22 PM, Mark Polesky wrote:
> You're proposing something like this?
>
> 1. Introduction to contributing
> 2. Working with source code
> 2.1 Using the `lilycontrib' GUI
> 2.2 Getting source with Git
> 2.2.1 [installing, configuring]
> 2.2.2 [downloading Lily
Carl Sorensen wrote Monday, December 28, 2009 5:25 AM
Oh, I agree that it would have the added benefit of a greater
audience, but
it would also cost more time for Mark to get it into the Git
documentation
instead of into the LilyPond documentation.
[...etc]
Many thanks, Carl. I had exactl
On 12/27/09 6:45 PM, "John Mandereau" wrote:
> Le dimanche 27 décembre 2009 à 18:20 -0700, Carl Sorensen a écrit :
>> And I don't see much of a maintenance headache; basic git isn't likely to
>> change much, and all we're using is basic git.
>
> This hasn't been true in the past, remember the
Le dimanche 27 décembre 2009 à 18:20 -0700, Carl Sorensen a écrit :
> And I don't see much of a maintenance headache; basic git isn't likely to
> change much, and all we're using is basic git.
This hasn't been true in the past, remember the merge of
git-update-index and git-add commands into git-a
On 12/27/09 6:09 PM, "John Mandereau" wrote:
> Le samedi 26 décembre 2009 à 21:25 -0700, Carl Sorensen a écrit :
>> But if you write what you would have liked to have had, then it will be
>> available for the next person like you. And whether it goes in an appendix
>> or in the body of the CG
Le samedi 26 décembre 2009 à 21:25 -0700, Carl Sorensen a écrit :
> But if you write what you would have liked to have had, then it will be
> available for the next person like you. And whether it goes in an appendix
> or in the body of the CG can be resolved later, IMO.
Whereas detailed explana
On Sat, Dec 26, 2009 at 06:14:22PM -0800, Mark Polesky wrote:
> I imagine that this would lead to an annoying web of
> cross-references, since someone new to Git who starts
> reading the chapter `Using Git' would need to go to the
> appendix for `Starting with Git', then back to the chapter
> for `
Trevor Daniels wrote:
> I see you still have the Windows section separate.
> Is it not feasible to integrate it? It's only
> separate because the early contributions were made
> independently.
It is feasible to integrate it, but this is a potentially
big task that I'm undertaking and I need to se
Carl Sorensen wrote Saturday, December 26, 2009 11:32 PM
On 12/26/09 3:57 PM, "Graham Percival"
wrote:
2009/12/26 John Mandereau :
Or just "lily-git" ? I don't follow the "porcelain" joke...?
In git terminology, porcelain is what the users interface with
(think of a
plumbing system, wi
Mark Polesky wrote Sunday, December 27, 2009 2:14 AM
Carl Sorensen wrote:
Have you considered whether "Using Git" should be an
appendix? To the extent that it's teaching about git,
rather than about LilyPond, it might belong in an
appendix.
Maybe there should be a chapter called something l
On 12/26/09 7:14 PM, "Mark Polesky" wrote:
> Carl Sorensen wrote:
>> Have you considered whether "Using Git" should be an
>> appendix? To the extent that it's teaching about git,
>> rather than about LilyPond, it might belong in an
>> appendix.
>>
>> Maybe there should be a chapter called so
Carl Sorensen wrote:
> Have you considered whether "Using Git" should be an
> appendix? To the extent that it's teaching about git,
> rather than about LilyPond, it might belong in an
> appendix.
>
> Maybe there should be a chapter called something like
> "Contributing patches" that mentions all t
> lily-git
> lily-git-gui
> lily-gitg
> lily-gitp
> lilygit
> lilylibrarian
> lilypond-git
> lilysourcesafe
> lysourcestore
> lycodemanager
Here are some more (I prefer `lilypatch'):
develypond
easiLY
easylily
lilyfix
lilypatch
lydev
simplily
simpLY
- Mark
On 12/26/09 3:57 PM, "Graham Percival" wrote:
> 2009/12/26 John Mandereau :
>> Le samedi 26 décembre 2009 à 12:27 -0700, Carl Sorensen a écrit :
>>> Shall we change the name to 'lilygit', or 'lilypond-git', or 'lily-git'?
>>>
>>> I think there *has* to be a better name than lilycontrib.
>>
>
2009/12/26 John Mandereau :
> Le samedi 26 décembre 2009 à 22:57 +, Graham Percival a écrit :
>> Or just "lily-git" ? I don't follow the "porcelain" joke...?
>
> This is not a joke, this is the official name for Git user front-ends.
I... see. A few minutes of googling shows that you're indee
Le samedi 26 décembre 2009 à 22:57 +, Graham Percival a écrit :
> Or just "lily-git" ? I don't follow the "porcelain" joke...?
This is not a joke, this is the official name for Git user front-ends.
Sorry for not joking :-)
John
signature.asc
Description: Ceci est une partie de message numé
2009/12/26 John Mandereau :
> Le samedi 26 décembre 2009 à 12:27 -0700, Carl Sorensen a écrit :
>> Shall we change the name to 'lilygit', or 'lilypond-git', or 'lily-git'?
>>
>> I think there *has* to be a better name than lilycontrib.
>
> What about lily-git-gui, lily-gitg, lily-gitp ("p" for porc
Le samedi 26 décembre 2009 à 12:27 -0700, Carl Sorensen a écrit :
> Shall we change the name to 'lilygit', or 'lilypond-git', or 'lily-git'?
>
> I think there *has* to be a better name than lilycontrib.
What about lily-git-gui, lily-gitg, lily-gitp ("p" for porcelain ;-)?
Best,
John
signature.
On 26/12/09 19:27, Carl Sorensen wrote:
Shall we change the name to 'lilygit', or 'lilypond-git', or 'lily-git'?
I think there *has* to be a better name than lilycontrib.
lilylibrarian, lilysourcesafe , lysourcestore, lycodemanager ?
Cheers,
Ian
__
On 12/26/09 10:30 AM, "Graham Percival" wrote:
> On Fri, Dec 25, 2009 at 07:13:32PM -0800, Mark Polesky wrote:
>
>> 2. Using the `lilycontrib' GUI
>> 3. Using Git
>
> I think these should be one chapter.
>
> 2. Source code
> 2.1 Using lilycontrib
> 2.2 Using git
Shall we change the name
On 12/26/09 10:18 AM, "Graham Percival" wrote:
> On Fri, Dec 25, 2009 at 09:04:29PM -0700, Carl Sorensen wrote:
>>
>> On 12/25/09 8:13 PM, "Mark Polesky" wrote:
>>
>>> Carl Sorensen wrote:> As I think more about this, I wonder if there should
>>> be
>>> a
short and sweet summary for ex
Graham Percival wrote Saturday, December 26, 2009 5:18 PM
I like this idea, but I'm not certain if we all have the same
idea. Here's the idea that I like:
1. introduction
1.1 help us: duplicate material from website
1.2 summary for unix developers: 2-3 paragraphs. We use git, the
docs are
On Fri, Dec 25, 2009 at 07:13:32PM -0800, Mark Polesky wrote:
> I feel that it has taken me longer than it should have to
> get familiar with some of the basics of compiling, so this
> text would ideally reduce the confusion time for new
> developers.
Based on all my experience at doc restructurin
On Fri, Dec 25, 2009 at 09:04:29PM -0700, Carl Sorensen wrote:
>
> On 12/25/09 8:13 PM, "Mark Polesky" wrote:
>
> > Carl Sorensen wrote:> As I think more about this, I wonder if there should
> > be
> > a
> >> short and sweet summary for experienced Linux developers,
> >> followed by a gentle (a
On 12/26/09 1:59 AM, "Trevor Daniels" wrote:
>
> I also find cherry-picking to be a useful alternative
> to rebasing, especially with the beautifully simple
> interface in gitk. Perhaps this could have a brief
> explanation, as the man pages are so confusing.
I typically do the following:
Mark Polesky wrote Saturday, December 26, 2009 3:13 AM
Carl Sorensen wrote:
As I think more about this, I wonder if there should be a
short and sweet summary for experienced Linux developers,
followed by a gentle (and longer) introduction for the
Windows guys.
Actually, I'm thinking there sh
On 12/25/09 8:13 PM, "Mark Polesky" wrote:
> Carl Sorensen wrote:> As I think more about this, I wonder if there should be
> a
>> short and sweet summary for experienced Linux developers,
>> followed by a gentle (and longer) introduction for the
>> Windows guys.
>
> Actually, I'm thinking the
Carl Sorensen wrote:> As I think more about this, I wonder if there should be a
> short and sweet summary for experienced Linux developers,
> followed by a gentle (and longer) introduction for the
> Windows guys.
Actually, I'm thinking there should be a short and sweet
summary for the GUI-based co
On 12/19/09 3:39 PM, "Mark Polesky" wrote:
> Okay...
>
> I'll just show you what I was thinking. I know this looks
> like a lot of work, but most of it would be shuffling stuff
> around to have a more logical order of presentation, and a
> more organized structure to facilitate referring to
On Sat, Dec 19, 2009 at 11:45:15PM -, Trevor Daniels wrote:
>
>> I just want to copy&paste, go get a coffee, then start editing
>> files.
>
> You might, but I don't agree this is a good attitude
> to encourage in contributors who might go on to
> write LilyPond code. We need contributors whose
Graham Percival wrote Saturday, December 19, 2009 9:37 PM
On Sat, Dec 19, 2009 at 02:16:19PM +, Ian Hulin wrote:
Trevor did a brilliant job with the Windows section and in some
respects
it's clearer and less forbidding than the material in 1.1 to 1.4.
It
also duplicates a lot of the mat
Okay...
I'll just show you what I was thinking. I know this looks
like a lot of work, but most of it would be shuffling stuff
around to have a more logical order of presentation, and a
more organized structure to facilitate referring to
specifics.
Some of it would entail adding text, but I'd be
On Sat, Dec 19, 2009 at 02:16:19PM +, Ian Hulin wrote:
> Trevor did a brilliant job with the Windows section and in some respects
> it's clearer and less forbidding than the material in 1.1 to 1.4. It
> also duplicates a lot of the material in those sections.
With respect, I disagree. Tr
On 12/18/09 11:35 PM, "Mark Polesky" wrote:
> Hey everyone.
>
> Without intending the slightest offence towards those of you
> who've already put a lot of work into the CG, I think it can
> still be clearer. I'm toying around with a bunch of new
> paragraphs over here, and I just wanted to l
Hi Mark, Graham,
On 19/12/09 10:49, Graham Percival wrote:
On Fri, Dec 18, 2009 at 10:35:28PM -0800, Mark Polesky wrote:
Without intending the slightest offence towards those of you
who've already put a lot of work into the CG, I think it can
still be clearer.
The only organization that's gon
On Fri, Dec 18, 2009 at 10:35:28PM -0800, Mark Polesky wrote:
> Without intending the slightest offence towards those of you
> who've already put a lot of work into the CG, I think it can
> still be clearer.
The only organization that's gone into the CG is putting stuff
into chapters. The section
Hey everyone.
Without intending the slightest offence towards those of you
who've already put a lot of work into the CG, I think it can
still be clearer. I'm toying around with a bunch of new
paragraphs over here, and I just wanted to let you guys
know, in case one of you is doing some big rework
56 matches
Mail list logo
