Hi,
Keith, somehow i had overlooked this part of your email:
On Wed, Jun 27, 2012 at 7:33 AM, Keith OHara wrote:
> For any changed test then, it is probably worth reading the header, to
> see if a subtle change that looks harmless happens to be the point of
> the test (and would presumably cause
On Sat, Jul 14, 2012 at 6:31 AM, Graham Percival
wrote:
> On Wed, Jul 11, 2012 at 05:48:48PM +0200, Janek Warchoł wrote:
>> On Tue, Jun 26, 2012 at 10:55 PM, Graham Percival
>> wrote:
>> > To avoid slowing down programming to a crawl, I figure that we’ll
>> > identify some subset of these regtest
y adopt a policy of aiming to have a stable
> release each 3 months, which should help with that.
I definitely think we should have stable releases much faster,
although I'd target 3-4 rather than simply every 3 months. But
that won't happen until/unless the regression tests have mu
don't think that makes much sense. It means that regressions become
> important _after_ stable releases.
Well, this isn't what i meant to be the "spirit" of my proposal.
My idea for the "spirit" of the new policy is:
"Regressions are bad, we cannot ignore them - we
he release
>> that would be deemed critical on the current definition. That
>> would seriously degrade the quality of our stable releases.
>
> This is a valid concern.
> What about something like this:
> when a regression against latest stable is found, it's not ma
f the only criterion is that the release compiles
> the (extended) regtests satisfactorily, then I doubt that adequate
> attention will be directed to bugs discovered after the release
> that would be deemed critical on the current definition. That
> would seriously degrade the quality of
dequate
attention will be directed to bugs discovered after the release
that would be deemed critical on the current definition. That
would seriously degrade the quality of our stable releases.
2. To complete the discussion David and I were having about
the possibility of using revert as an option
On Wed, Jun 27, 2012 at 05:33:47AM +, Keith OHara wrote:
> Graham Percival percival-music.ca> writes:
> > -any regression test which fails to compile or shows incorrect
> > output.
>
> For any changed test then, it is probably worth reading the header, to
> see if a subtle change that l
bel would be come more important, because we will
want to keep track of and fix regressions before too many stable
releases go by. For this purpose, I guess a regression would be
failure of something that worked on purpose in /any/ stable release.
> -any regression test which fails to compile
Not quite up to the ideal standard of GOP proposals, but there's a
lot of interest and this should be enough to see what way the wind
is blowing.
html-formatted version:
http://lilypond.org/~graham/gop/gop_3.html
*** Summary
Let’s drop the “any unintended change” thing, and go totally with
the
On Jan 17, 2012, at 10:01 AM, Werner LEMBERG wrote:
>>> Normally, a route to a stable release means a code freeze, applying
>>> only fixes to problems within the code. This also means that no
>>> new bug fixes get applied. Are we going to do the same?
>>
>> I don't understand the difference bet
>> Normally, a route to a stable release means a code freeze, applying
>> only fixes to problems within the code. This also means that no
>> new bug fixes get applied. Are we going to do the same?
>
> I don't understand the difference between the two - wouldn't a bug
> be a problem within the co
On Jan 17, 2012, at 9:45 AM, Werner LEMBERG wrote:
>
>>> So, with this idea in mind, I'd like to kick off a discussion about
>>> the next stable release. Assuming that we can fix all the critical
>>> issues (I think that's possible, but may be a month out or so),
>>> what else should we plan to
>> So, with this idea in mind, I'd like to kick off a discussion about
>> the next stable release. Assuming that we can fix all the critical
>> issues (I think that's possible, but may be a month out or so),
>> what else should we plan to have part of the next stable?
Normally, a route to a stab
2012/1/16 Carl Sorensen :
> I've been thinking more about the previous conversation about stable
> releases and coordinating work.
>
> David seemed unhappy with the idea of a stable release happening once we
> got to zero critical issues. My interpretation of his comments wa
2012/1/16 Carl Sorensen :
> I've been thinking more about the previous conversation about stable
> releases and coordinating work.
>
> David seemed unhappy with the idea of a stable release happening once we
> got to zero critical issues. My interpretation of his comments wa
David Kastrup writes:
> "m...@apollinemike.com" writes:
>
>> I think that the major deciding factor will be Guile 2.0 integration.
>
> We have had no code that has been able to survive basic testing. I
> don't think it makes sense to bank on a major feature for an _imminent_
> _stable_ release
"m...@apollinemike.com" writes:
> I think that the major deciding factor will be Guile 2.0 integration.
We have had no code that has been able to survive basic testing. I
don't think it makes sense to bank on a major feature for an _imminent_
_stable_ release when it has not even made it into a
Graham Percival writes:
> On Mon, Jan 16, 2012 at 08:07:25PM +, Carl Sorensen wrote:
>> I'm open to hearing everybody's opinion. If we can get consensus it might
>> be a powerful motivation for moving to 2.16.
>
> My position is well-known: version numbers ar
On Mon, Jan 16, 2012 at 08:07:25PM +, Carl Sorensen wrote:
> I'm open to hearing everybody's opinion. If we can get consensus it might
> be a powerful motivation for moving to 2.16.
My position is well-known: version numbers are cheap, stable
releases gets new features and b
Carl Sorensen writes:
> So, with this idea in mind, I'd like to kick off a discussion about
> the next stable release. Assuming that we can fix all the critical
> issues (I think that's possible, but may be a month out or so), what
> else should we plan to have part of the next stable? Is there
On Jan 16, 2012, at 9:07 PM, Carl Sorensen wrote:
>
> I'm open to hearing everybody's opinion. If we can get consensus it might
> be a powerful motivation for moving to 2.16.
>
> Thanks,
>
> Carl
I think that the major deciding factor will be Guile 2.0 integration. If Ian
is confident that
I've been thinking more about the previous conversation about stable
releases and coordinating work.
David seemed unhappy with the idea of a stable release happening once we
got to zero critical issues. My interpretation of his comments was that,
while zero critical issues may be a nece
> We've had a few people with problems with the Mandrke Cooker 1.7.9
> rpm... I wonder if the Mandrake guys know that the 1.7.x version is
> a development version, rather than a stable version. Do you think it
> might be worth asking them if they know about the stable/unstable thing,
> and perhaps
24 matches
Mail list logo
