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

Re: Release Team meeting minutes - 2005-06-18

* Josselin Mouette (joss@debian.org) [050619 22:17]:
> Le dimanche 19 juin 2005 à 21:45 +0200, Andreas Barth a écrit :
> > 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.)

> If the release team decides something, then says "we want things like
> this", you're putting people in front of a fait accompli. Even if people
> disagree with you, you get what the release team decided in the end, so
> that the release policy is matched.

You mean, if the release team has discussed about something, nothing in
the world can change it? Don't you think you see that a bit too
negative? For example, we let KDE 3.3 into sarge because the KDE team
convinced us that it was safe - though we had decided before that we
will release with KDE 3.2. There are far more examples that the release
team wants to work together with other people, and that we can be

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

> This "minutes" email was presented as a set of decisions taken.

I recommend you to stop reading debian-release. The minutes mail was a
mail that contained the minutes from the meeting, so that we don't
forget something we discussed. Nothing else.

> In the
> case of the python policy, the decision was apparently to discuss it
> privately.

Why are you reading the mail in the worst possible way? The decision was
to _discuss_ it. And it was postponed to some time where both Matthias
and I have both time.

> Things are much less likely to heat if you present them
> properly.

Ok, convinced. No more minutes to debian-release. If we want to present
properly, we need to take time to polish the mails.  Minutes will be
hidden in future to avoid misunderstandings. I hope that you'll be more
happy with that. I am desparate that this is necessary.

> You could have sent a short email to the debian-python mailing
> list, saying "we'd like to see this and that in the python policy",
> starting a constructive discussion. (Well, not all discussions become
> constructive, but you get a better chance this way.)

Hello? Didn't you read? Let me repeat: We will communicate with the
teams. With each one. The minutes were not meant for that, they were
only meant internally for the release team. Please read my last mail.

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

> I'd be the wrong person to criticize IRC meetings. However we're talking
> about a policy which affects hundreds of packages; that's not something
> you can discuss in private with a few selected people.

You mean, we're better of hiding discussions and results? Ok, your call.


Reply to: