Re: Questions for the DPL candidates
On Tue, Mar 15, 2005 at 08:35:26AM +1000, Anthony Towns wrote:
> everyone), we chatted about the topic and came to the opinion that
> removing a bunch of architectures from being release candidates would be
> necessary -- for reasons I hope are adequately explained in the
> announcement, or that will be on -devel as people ask. As it turned out,
Thus far I follow, and don't have a major objection.
> when we got to the actual meeting the next day, this was more or less
> exactly what Steve was wanting to propose, and he seemed to be expecting
> most of the objections to come from James, Ryan and/or me. So instead of
> that, we then spent a fair while discussing criteria for what support
> architectures would/should receive.
And the result of this discussion is what leaves me with great concern.
Specifically, the proposal:
1) Provides no way for an arch to produce a stable release after the
initial set of archs have produced theirs;
2) Provides no way for such a stable release to be integrated into the
security build system;
3) Provides no rationale for the N<=2 buildd's requirement, other than
that long builds delay security updates, and that is a silly
rationale since initial updates could just be made without those
4) Harms the efforts of porters to get their fixes into proper Debian
source packages by causing brokenness on those archs to no longer
5) Harms the overall usefulness on Debian on the archs that are still
supported by making their stable environment no longer available
on other archs in the same organization.
By far, #1 and #2 are the most critical to me. It is hard for me to see
how this proposal is anything but "dropping 7 archs" given those two
problems. It seems almost a sham to present it as anything else, and to
think that unstable snapshots is a sufficient replacement for stable
releases. If that is the case, then why not use that instead of stable
releases for all archs?
> I don't think that's actually such a problem; in this case there really
> just aren't so many alternatives, and as frustrating as that is for the
It seems that there are plenty of simpler fixes for the individual
problems, for instance:
1) For the mirror space problems: not requiring all mirrors to carry all
2) For the security delay problem: not requiring all security builds to
be available at once
3) For the release problem: not requiring all archs to release at once
> que sera sera. And given the plan is to give porters fairly complete
> control over their architecture in unstable, rather than necessarily
> expecting it to be synced with i386; and to provide a snapshot facility
I think losing sync in unstable is a bad thing, and not desirable. Note
that I do not view any arch as being "synced with i386"; all archs
should be synced with each other, and not everyone uses i386 as their
> Personally, I'd much rather worry about the technical side of things and
> let the "But you didn't follow procedure / respect my feelings" side of
> thing slide; personally, I think the best way of feeling good when
> working on a technical project is to get the technology right.
Agreed. But like you said, this was handled sub-optimally and I'm not
surprised at the resulting reactions.