Don Armstrong writes (Re: Redefining critical bug severity (was: how to deal
with a missed so bump already uploaded ?)):
I'm OK with either adding additional clarification or adopting this
language.
I agree with Manoj's point about the gap between Russ's wording and
the current one.
Would
Hi,
Ian Jackson:
Would adding totally (or utterly) before unrelated help perhaps ?
Or simply add a footnote stating that two packages are NOT unrelated
if one depends on the other.
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
Matthias Urlichs writes (Re: Redefining critical bug severity (was: how to
deal with a missed so bump already uploaded ?)):
Ian Jackson:
Would adding totally (or utterly) before unrelated help perhaps ?
Or simply add a footnote stating that two packages are NOT unrelated
if one depends
Hi,
Ian Jackson:
People often won't read a footnote unless they
are tripped up by something in the main text.
I have to agree.
s/footnote/remark/ (in the main text), then.
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Tue, May 20, 2014 at 01:39:39PM +0200, Matthias Urlichs wrote:
Or simply add a footnote stating that two packages are NOT unrelated
if one depends on the other.
Could someone explain why this is a useful distinction?
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Sat, May 17, 2014 at 08:46:20AM -0700, Russ Allbery wrote:
The confusion seems to always be around the unrelated software part of
that definition. The intended meaning is completely unrelated software on
the system, indicating a package that's mangling the system in some
fundamental way,
On Sat, 17 May 2014, Russ Allbery wrote:
I think defining critical as:
makes the entire system unusable, or causes serious data loss, or
introduces a security hole on systems where you install the package
is closer to how we actually use the severity, and would avoid some of
these
On Sat, May 17, 2014 at 01:18:29PM +0200, Julien Cristau wrote:
On Sat, May 17, 2014 at 12:42:10 +0200, Alessandro Ghedini wrote:
Note that e.g. haskell-zeromq4-haskell already requires zeromq 4.x to
build, and
others (python-zmq, hbro, ...) depend on libzmq3 = 4.0.1, so zeromq4
On Sat, May 17, 2014 at 07:33:04 +0200, Tobias Frost wrote:
IMHO the severity should be raised to critical as it breaks unrelated
software.
Reverse dependencies are anything but unrelated.
Cheers,
Julien
signature.asc
Description: Digital signature
On sab, mag 17, 2014 at 08:28:13 +, PICCA Frederic-Emmanuel wrote:
Reverse dependencies are anything but unrelated.
Hello julien, from the point of view of the release team.
What should be do now ?
to my opinion, all we have to do is to upload
zeromq3 with this ugly but necessary
On Sat, May 17, 2014 at 12:42:10 +0200, Alessandro Ghedini wrote:
Note that e.g. haskell-zeromq4-haskell already requires zeromq 4.x to build,
and
others (python-zmq, hbro, ...) depend on libzmq3 = 4.0.1, so zeromq4 should
be
packaged first, those packages updated to build depend on
Am 16.05.2014 22:56, schrieb PICCA Frederic-Emmanuel:
Hello,
the zeromq upstream forgot to do an so bump when releasing the 4.x series.
The breakage was discovers quite late so it is now in testing.
the package should be revert to the 3.2.4 version.
you can find all the information about
Julien Cristau jcris...@debian.org writes:
On Sat, May 17, 2014 at 07:33:04 +0200, Tobias Frost wrote:
IMHO the severity should be raised to critical as it breaks unrelated
software.
Reverse dependencies are anything but unrelated.
Over the years, I've seen endless confusion about the
Russ Allbery wrote:
Over the years, I've seen endless confusion about the current definition
of a critical bug severity:
makes unrelated software on the system (or the whole system) break, or
causes serious data loss, or introduces a security hole on systems
where you install
Hello,
the zeromq upstream forgot to do an so bump when releasing the 4.x series.
The breakage was discovers quite late so it is now in testing.
the package should be revert to the 3.2.4 version.
you can find all the information about this breakage in the bug #743508.
So my question is how to
On Fri, 2014-05-16 at 20:56 +, PICCA Frederic-Emmanuel wrote:
Hello,
the zeromq upstream forgot to do an so bump when releasing the 4.x series.
The breakage was discovers quite late so it is now in testing.
the package should be revert to the 3.2.4 version.
you can find all the
16 matches
Mail list logo
