Le mercredi, 11 janvier 2017, 22.38:33 h CET Sam Hartman a écrit :
> I heard back from doko today. We can expect a reply tomorrow. We also
> talked briefly about the issue.
Good. Thanks for this work.
> Realistically, i cannot imagine the TC coming to any final decision on
> something like this in under three weeks. That timeline seems fairly
> aggressive actually.
Right. It implies that every involved party (Lisandro, the Release Team,
Matthias, and the TC members) can provide a high bandwidth to that issue.
> However, I think the TC could act much more quickly in an interim
> capacity.
Yes.
> I personally believe that having packages building is a better interim
> state than the status quo. There are risks to an interim measure. We
> could have packages in the archive that build but fail to function
> correctly.
Ack.
> Depending on what we do long term, we could end up replacing
> packges currently in Stretch with packages we can no longer rebuild.
The worst case is needing to rebootstrap mips' stretch either from jessie, or
in a cross-bootstrap situation, right ?
> I personally think that when I weigh those risks against my estimate of
> their probability, I think it makes sense to adopt an interim measure.
I agree.
> Roughly I propose to override the maintainer and permit an NMU to be
> made for this issue.
It would be much preferable if Matthias would accept that patch, or revert to
the previous working version. But if it needs an NMU, so be it.
( Mid-term, I want to understand how it can make sense to change Debian's
binutils' tracked branch (2.27→2.28) three days before the transition
freeze.
)
> The decision stands until the maintainer fixes the bug or Stretch
> releases, or another resolution is passed (presumably with a more
> permanent decision).
Absolutely.
> Yes, that means that the maintainer could reintroduce the bug and revert
> the NMU immediately on the release of Stretch.
Absolutely. I wouldn't support a resolution enforcing that NMU in unstable
forever. New release cycles are our reset button, really.
> I propose to be very agressive in calling for a vote on the following
> ballot.
> I plan to call for a vote in 24 hours if I get support from at least one
> TC member and no objections from within the TC or release team.
Let this mail be my support !
> Also, within that time, we should hear from doko. His input may change
> my thinking even for an interim measure.
Yes, absolutely. There was only one mail from Matthias on the #844227, only to
NAK the NMU, on an RC bug opened since November, his input is long overdue!
> ----------------------------------------
> In #850887, the Debian Technical Committee was asked to choose a
> solution for #840227, a bug that prevents a significant number of
> packages from building on the mips architecture. Given the upcoming
> Stretch freeze, this issue is urgent.
>
> As an interim measure, using its powers under section 6.1.4 of the
> Debian Constitution, the Technical Committee overrules Matthias
> Klose's decision to revert the NMU of binutils fixing #840227. The
> committee requests Lisandro Damián Nicanor Pérez Meyer to make a new
> NMU fixing #840227.
>
> The committee requests the release team to support the interim nature of
> this solution and if a permanent solution is adopted before the release of
> Stretch, to consider including that solution in Stretch even if the freeze
> criteria would not normally permit such consideration.
>
> In addition, the committee requests the stable release managers for Stretch
> to consider including the eventual upstream solution for this issue into a
> stretch update.
>
> This interim decision stands until the release of Stretch, until it is
> replaced by resolution, or until the binutils maintainer fixes #840227 in
> some other manner.
>
> ----------------------------------------
> Choice 1: Approve the Resolution (3:1 majority)
> Choice 2: Reject this Interim Measure
> Choice 3: Further Discussion
> ----------------------------------------
I agree with the ballot including Ian's suggestion, and think we should start
the vote as early as this week-end.
Cheers,
OdyXAttachment:
signature.asc
Description: This is a digitally signed message part.