On Fri, Sep 23, 2011 at 11:40:19PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > dev/staging
>
> There you are.
Thanks, b4ff85a2416e4b80deb9eef8329cd230ee4dc944 built all the
docs on git master, so I've merged it with master.
Cheers,
- Graham
Graham Percival writes:
> On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote:
>> But we still need to find a solution where I have a chance of getting
>> work done.
>
> dev/staging
>
> I just realized that I forgot to add this to the proposal. I'll
> do that later tonight and send an
Graham Percival writes:
> On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote:
>> But we still need to find a solution where I have a chance of getting
>> work done.
>
> dev/staging
There you are.
--
David Kastrup
___
lilypond-devel maili
Graham Percival writes:
> On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote:
>> But we still need to find a solution where I have a chance of getting
>> work done.
>
> dev/staging
>
> I just realized that I forgot to add this to the proposal. I'll
> do that later tonight and send an
On Fri, Sep 23, 2011 at 03:03:46PM +0200, David Kastrup wrote:
> But we still need to find a solution where I have a chance of getting
> work done.
dev/staging
I just realized that I forgot to add this to the proposal. I'll
do that later tonight and send an updated version.
Or better yet -- dev
David Kastrup writes:
> Reinhold Kainhofer writes:
>
>> Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
>>
>>> It is a compromise between the damage and the good developers manage
>>> to do. The higher the number of developers, the more important it
>>> becomes to avoid damage, s
Reinhold Kainhofer writes:
> Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
>
>> It is a compromise between the damage and the good developers manage
>> to do. The higher the number of developers, the more important it
>> becomes to avoid damage, since damage blocks everybody, an
Am Friday, 23. September 2011, 11:17:32 schrieb David Kastrup:
> "Trevor Daniels" writes:
> > How would this code be reviewed? Do you envisage still
> > uploading to Reitfeld? Would this be before pushing to
> > dev/* or after? I still think this is a complication too far.
> > Certainly it need
"Trevor Daniels" writes:
> Graham Percival
>
>> Developers doing medium-large fixes: examples include beam
>> collisions, music function rewriting, Flag grobs, etc. All this
>> work should go on separate branches (e.g. dev/flag-grob,
>> dev/scheme-music-functions). Once the code is merged, the br
Graham Percival
Developers doing medium-large fixes: examples include beam
collisions, music function rewriting, Flag grobs, etc. All this
work should go on separate branches (e.g. dev/flag-grob,
dev/scheme-music-functions). Once the code is merged, the branch
should be removed. People can stil
sorry, I forgot to send this on Wednesday.
http://lilypond.org/~graham/gop/gop_12.html
** Proposal summary
Let’s keep git master in ready-to-release state all the time. In
particular, assume that git master could become the next major
stable release at any time. If that makes you pause and wonde
11 matches
Mail list logo
