Johannes Schindelin escreveu:
Hi,
On Mon, 23 Oct 2006, Han-Wen Nienhuys wrote:
I have some more clues now; some of the time stamps in the CVS repo are
messed up; eg revision 1.2 of flower/include/GNUmakefile lists 2002 as
the year which is clearly wrong.
Most definitely this would trigger a
Hi,
On Mon, 23 Oct 2006, Han-Wen Nienhuys wrote:
> I have some more clues now; some of the time stamps in the CVS repo are
> messed up; eg revision 1.2 of flower/include/GNUmakefile lists 2002 as
> the year which is clearly wrong.
Most definitely this would trigger a "bug" in cvsps. I say "bug
Johannes Schindelin escreveu:
Hi,
On Mon, 23 Oct 2006, Han-Wen Nienhuys wrote:
Interested parties can get the darcs repo at
http://lilypond.org/~hanwen/gub-git/
Well, I cannot. As I stated earlier, I gave up on darcs.
You can simply wget the directory, which will give you a runnable
Johannes Schindelin escreveu:
I am tracking the current lilypond repository with git. I could donate
this git repository (it is ca. 60MB at the moment).
I prefer git over the other alternatives: it is blazingly fast, *very*
portable (I gave up on porting darcs after a fruitless day), and
br
Hi,
On Mon, 23 Oct 2006, Han-Wen Nienhuys wrote:
> Interested parties can get the darcs repo at
> http://lilypond.org/~hanwen/gub-git/
Well, I cannot. As I stated earlier, I gave up on darcs.
> however, I seem to have some trouble with importing the CVS repo into
> Git. My attempt is at
>
Graham Percival wrote:
>
> On 8-Apr-06, at 4:01 AM, Cameron Horsburgh wrote:
>
>> Graham Percival wrote:
>>
>>> manual, I'll be doing them all at once, so I won't miss anything. I
>>> think we still have features introduced in 2.2 that haven't made it into
>>> the manual (I'll be calling for a v
On 8-Apr-06, at 4:01 AM, Cameron Horsburgh wrote:
Graham Percival wrote:
manual, I'll be doing them all at once, so I won't miss anything. I
think we still have features introduced in 2.2 that haven't made it
into
the manual (I'll be calling for a volunteer to do this soon).
I'll have a
Graham Percival wrote:
> 4. For the first half of the development cycle, don't include new
> features in the manual. New things get listed in NEWS, but only there.
> I favor this solution. At first glance, it might suggest that new
> features won't get documented well, but it should have the o
Hi,
On Wed, 5 Apr 2006, Han-Wen Nienhuys wrote:
> Pedro Kröger wrote:
> > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> >
> > > Hmmm; part of the problem might also stem from using CVS, which
> > > doesn't have good cherry-picking for patches.
> >
> > would it be a solution to use darcs only f
On 5-Apr-06, at 5:23 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
In addition, if Erik's music streams are in place in 2.10, then users
who don't want to manually upgrade syntax on old completed files have
the option of using the streams (which is the whole point of them,
right?) If
Han-Wen Nienhuys wrote:
If we go this route, we could better do it right immediately, and setup
a bzr/darcs/monotone/git/etc. based infrastructure rightaway.
I mean, for the entire lilypond repository.
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
LilyPond Software
Pedro Kröger wrote:
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
Hmmm; part of the problem might also stem from using CVS, which
doesn't have good cherry-picking for patches.
would it be a solution to use darcs only for the manual? I know there
are some ways of syncing darcs and cvs, so maybe
Graham Percival wrote:
In addition, if Erik's music streams are in place in 2.10, then users
who don't want to manually upgrade syntax on old completed files have
the option of using the streams (which is the whole point of them,
right?) If you look at it that way, wouldn't we be absolutely c
On 5-Apr-06, at 4:49 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
If the hackers are fine with this, I'm certainly happy with this
solution. I take it that we're still in the bug-fixing stage?
(since 0 recently came out, we have a lot of new interest, finding
more bugs, pointing out
Han-Wen Nienhuys <[EMAIL PROTECTED]> writes:
> Hmmm; part of the problem might also stem from using CVS, which
> doesn't have good cherry-picking for patches.
would it be a solution to use darcs only for the manual? I know there
are some ways of syncing darcs and cvs, so maybe the doc stays in cv
Graham Percival <[EMAIL PROTECTED]> writes:
>> 5. Provide a unified documentation and mark features with a version
>>number, say,
> I suppose that this is possible... but IMO this would completely
> clutter the manual with unnecessary info.
I think that a compromise would work. Instead of ha
Graham Percival wrote:
2. -> we've been trying to do this for ages, and for the 2.8 it's
almost worked (9 months).
The real problem is that all hackers should agree on a single period
were nothing but bugfixing happens. It might be a good thing to just
use the Linux 2.6 model, where we have
On 5-Apr-06, at 2:51 AM, Han-Wen Nienhuys wrote:
Graham Percival wrote:
2. Much shorter devel periods (say, four months). New users still
get confused and ask questions about things which I've already
clarified,
3. Once a month, somebody goes through the tiresome process of
sifting thro
Graham Percival wrote:
2. Much shorter devel periods (say, four months). New users still get
confused and ask questions about things which I've already clarified,
3. Once a month, somebody goes through the tiresome process of sifting
through differences between the devel and stable manuals
On 5-Apr-06, at 12:45 AM, Werner LEMBERG wrote:
5. Provide a unified documentation and mark features with a version
number, say,
This feature appeared in version 2.7.38.
Ideally, such things belong into the margin, but...
I suppose that this is possible... but IMO this would comp
> 4. For the first half of the development cycle, don't include new
> features in the manual. New things get listed in NEWS, but only there.
> I favor this solution. At first glance, it might suggest that new
> features won't get documented well, but it should have the opposite
> effect:
Hi all,
In the past, there have been periods of half a year (or more) when Mats
and I suggest that users should read the development manual instead of
the stable manual. Most of the changes I make to the manual apply to
the stable branch as well, but due to technical and time
considerations,
22 matches
Mail list logo
