Re: Questions for the DPL candidates
On Tue, Mar 15, 2005 at 08:35:26AM +1000, Anthony Towns wrote:
> Matthew Garrett wrote:
> >Steve Langasek <vorlon@debian.org> wrote:
> >> Andreas Schuldei (DPL candidate)
> >> Angus Lees (DPL candidate)
> >> Branden Robinson (DPL candidate)
> >> Jonathan Walther (DPL candidate)
> >Little advance public warning was given about this meeting, and the
> >scope of the discussions that would take place was not made clear
> >beforehand.
>
> Little advance /private/ warning was given too -- I picked up my ticket
> the day before I left, and only had my flight booked a week before that.
> Up until about a few weeks before that, the plan was no more specific
> than to have a meeting sometime between March and May.
>
> The agenda item for this issue, which was mailed out on the 3rd of
> March, was:
>
> ---
> how to improve the turnaround of bug fixes in testing
> [...]
> - decoupling ABI changes from RC bugfixes: brainstorm
>
> release criteria for candidate architectures
> - setting per-port release requirements (porter expectations) for etch
> - how to address per-port problems that remain for sarge
> ---
>
> As it happened, James and I were staying at Ryan's, and after dinner on
> Friday night (before the meeting proper started, but after we'd met
> 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
No, they are not. Again the eternal communication problem, but this was really
delivered in the worse way possible.
> announcement, or that will be on -devel as people ask. As it turned out,
> 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.
>
> Hopefully the above provides some useful specifics for people to talk about.
Thanks for the detailed info on this, i would have preffered full minutes of
the meeting, but well.
> >As a result, the rest of the project had little input into
> >the decision-making process.
>
> That's why it's posted on the lists now -- it never too late to get
> input into something in Debian; even after we've committed to something,
> we can almost always change our minds.
Well, the announcement was not the right way of getting people to discuss the
issue.
> >Do the other candidates believe that this
> >was the best that could be done in the circumstances, and if not how
> >would they avoid similiar situations (and the ensuing fallout) arising
> >in future?
>
> Really, I think this is a necessary consequence of having small meetings
> of the relevant people; the alternatives are to invite everyone -- which
> is more or less the same as just having the discussion on the lists,
> which has its own problems that I hope have adequately been covered
> elsewhere; or to have meetings that don't generate any conclusions --
> which strike me as a waste of time.
What about a meeting about this topic at debconf 5 in finnland, together with
an open and real discussion from now to july to prepare for it. This affects
the whole project, has repercussion to what we all believe debian is, and how
people outside perceive us, so it is only normal to discuss this in a wider
forum than a spur of the minute meeting of the inner team (err cabal or
whatever :).
> 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
> people who lose out, until there are some workable alternatives, well,
What are the exact problems anyway, and how do they correlate to the proposed
solutions.
> 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
> for doing releases, I think this is actually /better/ than the current
don't you think that doing random snapshot of unstable will have each
individual porters cover more work than what is needed for the whole archive
right now ? What do you think about my proposal to build the dropped arches
from testing instead, and have each arch have a proper per arch testing script
and input in case uploading to tier1-unstable is no solution ?
I would like your opinion as the testing script creator about this.
Also, why does this proposal not have support for having later stable release
of the non-tier1 arches in point releases, and an invitation of those arches
to join the security team for it ? The whole problem is that there is nothing
constructive offered the dropped arches porters, just that they are left to
work out their stuff alone.
I wonder also, do we still not have some sun donated sparc box running part of
our infrastructure ? How will that stay if we drop sparc support ?
Friendly,
Sven Luther
Reply to: