Re: Release Team meeting minutes - 2005-06-18
please keep the heat level low. You summarrized the result quite
> There's a need for change, this is for sure.
> I agree on waiting for the C++ ABI change
> completion before starting to move python stuff.
Nothing else has yet been discussed, except that I will speak with
Matthias at debconf (and mind you, I would probably speak with him even
without this meeting and me being member of the release team :). IMHO
(one of) the most important part(s) of that discussion will be "how do
we discuss about the changes so that the result pleases all", and all
members of the python team are quite important of course there. I think
the lead for that discussion will be in the python team's hands in the
There is a simple reason for discussing that topic in the release team
meeting: Our current RC policy makes any violation against the current
python policy an RC bug. At this meeting, we discussed what needs to be
changed in our RC policy list for etch in the opinion of the release
team, and the python policy is one place where a change would be nice in
the release teams view. It is of course the right of the python team to
disagree with the release team; it is not the task of the release team
to decide the python policy, but please understand that we wanted to go
through all issues in our release policy. (Please remember that there
are also other similar issues like the one that we want a newer LSB -
but that needs also coordination.)
Frankly speaking, the current level of heat makes me reconsider whether
publishing minutes should be done in future. Of course, _anything_ that
the release team agrees upon that has effect on other teams will be
discussed/published/[whatever appropriate] accordingly; nobody is forced
to read debian-release. However, writing of minutes happens first as we
can use them as basis for the other mails.
Finally, if the release team can't make a meeting and discuss about the
release teams opinion on issues connected with the release of the next
stable release of Debian without being toasted from (at least) two
sides, than there is something rotten in this state called Debian.