>>>>> "CP" == Christian Perrier <[email protected]> writes:
CP> The duty of the Debian maintainer is to smooth down impacts from
CP> upstream changes. One of the recognized qualities of Debian is
CP> such stability. So, we need to prepare our stable releases to
CP> avoid such breakages.
CP> Another is probably bringing feedback to upstream that such
CP> changes are very unwished by their users.
This is not the first time .css format change has happened. And yes, it
was reported and discussed upstream in the past. They are willing to
avoid such changes but it may not always be easy. More pressure
(i.e. from more users) on the upstream maintainers may or may not
improve things. The .css format is generally not considered as very
fixed, e.g. it's not portable across architectures after all.
There were other upgrade problems in the past. For instance, I
personally don't simply believe .crm scripts from the last version work
with a new one without changes and I always test that crm114 still works
after the upgrade. I'd say that backward compatibility is not a crm114
feature and one must expect problems when upgrading crm114 to a new
version. Of course, a user may not think about crm114 when typing
`apt-get upgrade'. This wouldn't be a big problem if crm114 wasn't
typically used for things like e-mail delivery.
So the primary problem is how to _warn_ users that crm114 gets upgraded
with higher than casual risk of breaking things. The current practice
of warning about important changes in NEWS.Debian seemed to work well so
far. But I agree it may not be enough and I'm open to suggestions how
to improve it.
CP> But, at least, I expect my problems to benefit other users and
CP> particularly to avoid what I consider to be enhanced to enter
CP> testing and then break much more setups.
Sure, you brave unstable users get hit by such problems and by reporting
them you prevent wider impacts.
CP> At the very minimum, a critical priority debconf note displayed
CP> when upgrading from a pre-20090423 version would be a good way
CP> to try your best preventing the problem to appear. Debconf notes
CP> are discouraged but I think that, here, we have a case where it
CP> would be better having it than nothing.
Right now, I like this suggestion better than the binary package name
changes. Some might not like it, but I may just try to add it and we'll
see what happens.
CP> I also came back on the NEWS.Debian entry and I think it is not
CP> alarming enough as it mentions "on some architectures" (which a
CP> careless reader would translate to "probably not on the most
CP> common ones") and it just mentions that CRM114 might not work
CP> but not that....mails piped through it will vanish.
Good remark.
CP> Maybe more people will come up with better suggestions.
If no applicable precedent in other Debian packages is presented here,
I'll probably discuss the problem on debian-mentors.
CP> I really think that this bug should remain release critical so
CP> that it gets the deserved attention by both you and other
CP> developers (I bet that many use crm114 and many clever people
CP> can come up with good suggestions....this is also what RC bugs
CP> are about).
Of course, I don't get rid of RC bugs without discussing them first.
CP> Please accept some forms of apologies for showing up my "rage"
CP> in the bug report (I admit I was) but also please don't take the
CP> RC bug as a personal attack but more as a way to help you to
CP> provide the best possible package for that software.
There is no need to apologize. I just missed identification of the
_Debian package_ problem in your initial report and you've fixed it
now. :-) Thanks for the report.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
