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
archs;
4) Harms the efforts of porters to get their fixes into proper Debian
source packages by causing brokenness on those archs to no longer
be RC;
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
archs
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
development platform.
> 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.
-- John
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
