On Monday 14 March 2005 23:35, 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.
> 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
> announcement,
the announcement didn't really contain any explanation of the reasoning
behind the actions proposed (other then 'we think this will help realease')
> > 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.
er, saying "we've committed to this" really comes across as a 'fait a
compli' to a lot of people. Reading on I realize that's not what you
intended. The nybbles suffered from similar unfortunate phrasings
> > 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.
The combination of not including reasoning behind decisions and the rather
unfortunate phrasing used in the nybbles opens you[1] /wide/ up for abuse,
resentment, and acusations of being a cabal (a situation a doubt anybode
was looking for).
> 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,
> 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
> situation for non-release-track architectures. Certainly I think it'll
> be better for the Hurd than what we currently do, provided they can get
> their act back into gear and meet the qualifications for being in Debian
> at all.
again I'm missing why's here, it may be obvious to members of the release
team, but it's not obvious to me (nor it would seem a lot of other people
on the list), and an "I think" does not tell me anything.
> 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.
if you want a technical discussion instead of a political one it helps to
precisely lay out:
- the precise problems you're trying to fix as opposed to just assuming
everybody knows the exact problems.
- how you're proposal will adress those problems
Presenting the argument in whole (instead of just the result) tends to go a
long way in having a technical discussion, it keeps people from feeling
left out of the loop, and it accomodates and promotes a technical
discussion. It also avoids repeating arguments had in the "in person
meeting" with people on the list who weren't there.
So could somebody who was at the meating please post and explain the why's
behind each decision?
--
Cheers, cobaco (aka Bart Cornelis)
1. Encrypted mail preferred (GPG KeyID: 0x86624ABB)
2. Plain-text mail recommended since I move html and double
format mails to a low priority folder (they're mainly spam)
Attachment:
pgpUWKG8OZ4MS.pgp
Description: PGP signature