[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
    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



Reply to: