Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Hello everyone,
I hope no one minds me jumping in here. I've been talking to Carsten
privately about the debhelper freeze exception and the subsequent
discussion, orphaning, and so forth. I think everything went a little
too fast based on various assumptions about how other people would
react and therefore escalated more than was needed. I'm writing this
message with a mediator hat on to see if I can explain what happened
and reopen the discussion about where we should go at this point.
I'd like to see if we can find a better solution that doesn't result in
the package being orphaned and which results in a supported deborphan
package in squeeze.
Carsten doesn't believe that the current version of deborphan is useful
to release with squeeze and has been working for some months on a new
version. He's nearly done and thought he had a bit more time, so the
freeze caught him flat-footed (I'm sure you've heard this a lot) and
disrupted his existing plan for deborphan in squeeze. The new version
is a fairly comprehensive change which, among other things, adds support
for multiarch so that deborphan would not wrongly detect and remove
packages when users upgrade to squeeze+1. Carsten believes this support
is mandatory for a releasable deborphan (Bug #592068, which he originally
set to serious and which was downgraded by someone else).
Unfortunately, this nearly-completed rewrite is not a trivial change and
therefore isn't going to be an easily reviewable diff. deborphan was
rearchitected in the process to be more maintainable going forward and to
make it easier to add the new features. Highlights of the new release
are:
* Improve detection of orphaned packages:
- Add option to detect circular dependencies.
- Add option to recursively check for orphans.
* UI improvements in the dialog based deborphan frontend orphaner:
- Display short description of highlighted package.
- Display packages that are orphaned when only Suggests: are ignored, when
Suggests: and Recommends: are ignored and when none of these are
ignored in different colors to be able to distinguish them.
* Multiarch support:
- Strip :any dependencies.
- Fail and thus prevent bad things from happening if an other
dependency containing a colon is found.
His intention was to finish and upload this to unstable within the next
week or two and do extensive testing to ensure that it was of release
quality.
All of this work was explicitly targetted at squeeze. There has been a
lot of discussion of removing sections for the next release, which would
require significant changes again to deborphan. Uploading the new version
of deborphan and going through the testing work to ensure that it works
properly therefore doesn't seem worth it if the new version has no hope
of making it into squeeze. That was the motive behind deciding to orphan
it instead of moving on with work that Carsten was concerned could not be
considered for the next release.
This would definitely be an unusual exception in that the new version
is not a minimal change. If there's little or no hope that it would be
approved for squeeze, I don't think Carsten feels sufficient motivation
to invest the time into finishing it at this point. If there is a good
chance that it would be considered for squeeze, I think that would change
the situation.
The request is, therefore, not for an advance freeze exception (since
I know you'll want to look at the package as uploaded), but for an
indication of whether such a new release has a reasonable chance of being
accepted if it is finished and thoroughly tested quickly.
My goal in this is to have a supported deborphan in squeeze, and ideally
to maintain the enthusiasm and interest of the existing maintainer. Given
that there is a new release almost complete that the maintainer considers
supportable and has been working on explicitly targetting squeeze, and
given that deborphan is largely a leaf package and unlikely to cause
problems for any other package, would the release team be willing to
consider an unusual exception and review for this package? I realize that
this is outside the bounds of what you would normally grant a release
exception for; I think it falls into the more unusual case of:
| For packages which missed the freeze only for reasons outside of the
| control of the maintainers, we might be generous, but you need to
| contact us on your own, and you need to contact us soon.
In this case, the freeze timing and the timing of Carsten's work missed
each other by an unfortunate two weeks.
If this were not a leaf package (and Debian-native, and fairly low-risk
for causing problems for any other packages), I would have a hard time
arguing that you should consider this, but given the situation, I think
this may warrant a special exception.
Thank you for your time and
