On Thu, Jul 19, 2018 at 11:19 AM Jeroen Demeyer wrote:
>
> On 2018-07-19 11:04, Sébastien Labbé wrote:
> > The definition of "blocker" ticket must be adapted to the release
> > calendar we choose to have.
>
> I really disagree with this. I think it's important that the calender is
> adjusted depen
On Thu, Jul 19, 2018 at 10:23 AM Volker Braun wrote:
>
> On Thursday, July 19, 2018 at 10:16:46 AM UTC+2, Erik Bray wrote:
>>
>> If there's a fix for a known issue there's no reason to exclude it
>> from a release.
>
>
> Look at it this way, we are delaying hundreds of tickets by a week to fix
>
On 2018-07-19 11:04, Sébastien Labbé wrote:
The definition of "blocker" ticket must be adapted to the release
calendar we choose to have.
I really disagree with this. I think it's important that the calender is
adjusted depending on blocker tickets, not the other way around.
--
You received
> We must be using different definitions of "blocker" then. Just
> because a bug doesn't prevent development from continuing does not
> mean it isn't a *release* blocker. Any bug that introduces
> regressions into the test suite should be a blocker if it means not
> being able to release a
On Thursday, July 19, 2018 at 10:16:46 AM UTC+2, Erik Bray wrote:
>
> If there's a fix for a known issue there's no reason to exclude it
> from a release.
>
Look at it this way, we are delaying hundreds of tickets by a week to fix
your pet bug 3 months earlier. Of course you can forever argue a
On Thu, Jul 19, 2018 at 12:07 AM Volker Braun wrote:
>
> On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>>
>> As I wrote previously, I made this fix back in April,
>> but tabled getting the fix directly into Sage since I thought it would
>> be no big deal to make a Cysignals rel
On Wed, Jul 18, 2018 at 11:53 PM Timo Kaufmann wrote:
>
> As one small data point I can say that I already upgraded cysignals in
> nixpkgs (tested Linux, although it could technically be used on other
> platforms too). I didn't run into any obvious issues.
>
> I also think we should merge that u
On Wed, Jul 18, 2018 at 11:44 PM Volker Braun wrote:
>
> On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>>
>> All that said, your claim that this is a "high-risk" upgrade is also
>> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1]
>> which contains a couple
On Wed, Jul 18, 2018 at 11:21 PM Jeroen Demeyer wrote:
>
> On 2018-07-18 13:34, Erik Bray wrote:
> > This is again specious, and needlessly disparaging and antagonistic.
> > I don't believe if takes 2 weeks to run CI tests
>
> Just replying on this point: the problem is that many things are not
>
On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>
> As I wrote previously, I made this fix back in April,
> but tabled getting the fix directly into Sage since I thought it would
> be no big deal to make a Cysignals release and update Sage's
> dependency on it
By definition,
Le mercredi 18 juillet 2018 23:44:33 UTC+2, Volker Braun:
>
> I haven't looked at the diff set, but we did have regressions
> from minor cysignals changes before. Its just that signal handlers,
> due to their asynchronous nature and interactions with the OS,
> are notoriously hard to reason about
As one small data point I can say that I already upgraded cysignals in nixpkgs
(tested Linux, although it could technically be used on other platforms too). I
didn't run into any obvious issues.
I also think we should merge that upgrade for 8.3. Erik put in a lot of work to
make that platform s
On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote:
>
> All that said, your claim that this is a "high-risk" upgrade is also
> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1]
> which contains a couple bug fixes, the most significant of which (in
> terms of pat
On 2018-07-18 13:34, Erik Bray wrote:
This is again specious, and needlessly disparaging and antagonistic.
I don't believe if takes 2 weeks to run CI tests
Just replying on this point: the problem is that many things are not
caught by CI, especially things related to the build system and porta
On Wed, Jul 18, 2018 at 12:13 AM Volker Braun wrote:
There's at least a few things I should say here.
> I do appreciate your hard work in making Cygwin work. But IMHO thats a rather
> high-risk upgrade with little reward. Nobody stops you from merging that
> ticket when building cygwin binarie
On Wednesday, July 18, 2018 at 5:46:35 AM UTC+2, Travis Scrimshaw wrote:
>
> unless you (Volker) can guarantee that the next full release will be fully
> ready by Monday morning Eastern US time. However, that is only because it
> would be more prudent for the SageDays.
>
Thats likely if we don't
On Wednesday, July 18, 2018 at 8:13:12 AM UTC+10, Volker Braun wrote:
>
> I do appreciate your hard work in making Cygwin work. But IMHO thats a
> rather high-risk upgrade with little reward. Nobody stops you from merging
> that ticket when building cygwin binaries. And realistically we don't h
I do appreciate your hard work in making Cygwin work. But IMHO thats a
rather high-risk upgrade with little reward. Nobody stops you from merging
that ticket when building cygwin binaries. And realistically we don't have
anyone developing on Cygwin only at this point.
[ ] I want to delay all
18 matches
Mail list logo
