Hi Ritesh,

On 04/21/2015 02:34 PM, Ritesh Raj Sarraf wrote:
On Thursday 16 April 2015 07:56 PM, Serge Cohen wrote:
Is it possible to raise the severity level of this bug to make it RC, and is 
there a chance that both bugs (782487 and 782488) are solved before the release 
so that the installation on systems relying on multipath would not require 
workaround to be functional ?

Thanks for reporting the issue. But at this time, this will not make
into Jessie.

Yeah, that's certainly understandable.. specially* with a release date
this Saturday. :-)

I usually mention/ask for upload to Jessie just to signal the intention
to put it in the stable release (similarly to CC:sta...@vger.kernel.org
in LKML), although I sure enough understand and expect some constraints
(e.g., personal time, testing time, feasibility etc.) to sometimes make
things not the way some users want, but the way a majority of users may
benefit more, by at least following the right Debian process.

This is one gripe I have with Debian Enterprise users. I always get bug
reports at the very last minute. <...>

Ugh, yeah. I notice that too and feel unfortunate to be in that position
this time. It's really unfortunate timing in this occasion; something I,
personally, work to improve where I can, but sometimes, sadly, it still
happens.

> <...> What most users don't realize is that
many of us Debian Developers are really pure volunteers. :-)
We aren't paid by anyone to work on it, thus the commitment and reaction
to a bug report heavily depends on when I have the time.

For sure. Again, thanks a bunch for really looking at the patches/emails
I have been bugging (literally) you with. :) It's not always that way in
other packages/scenarios, and even non-volunteers (for workload or other
reasons).

Anyways... I'll be looking into packaging 1.40 soon. I don't like the
idea to introduce a new package, but then let me  check first.

Thanks.

If that helps, the rationale I adopted to decide to split the udev rules
out in a new package is a conservative one, based on these ideas:
- People that are used to install sg-utils just to get its binaries, so
will, rather than all of sudden have new udev rules/attributes for their
disks and a mysterious initramfs-update for no apparent/required reason.
- If there's no requirement for those udev rules until now, there isn't.
So, just put it in a small package that provides them, and let reverse-
dependencies exist where they are actually required.
- I also thought of following the existing convention of -boot suffix
(e.g., multipath-tools, kpartx) when there are changes to the initramfs,
but for some reason I preferred the -udev suffix, perhaps because that's
clear enough, but I don't recall right now :)

@Mauricio: Again, thank you. Your reports and patches are really helpful
to me.

Always glad to contribute, Ritesh. Again, thank you for your time and
effort on multipath-tools et al. :)

Best regards,

--
Mauricio Faria de Oliveira
IBM Linux Technology Center


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to