Am Freitag, den 28.12.2007, 15:25 -0400 schrieb Xavier Lamien:
2007/12/28, Christoph Wickert <christoph.wickert(a)nurfuerspam.de>:
Raleigh, we have a problem...
python-gammu, which is required by wammu, prevents users from
updating
to the latest gammu release for several days now. It has
already been
reported in Bugzilla, see
https://bugzilla.redhat.com/show_bug.cgi?id=426848 and - even
more
interesting -
https://bugzilla.redhat.com/show_bug.cgi?id=425831
I fallen on an broken deps on kernel-xen-devel during the update of my
F-8 release, why don't talk about too ?
Because I never was affected by this one and did not even hear of it
before. IMHO a devel package is not that important as an application.
Most users could simply remove the package without loosing
functionality, this is different with wammu.
BTW: Are you talking about an upgrade from F7 to F8 or about an update
during the release?
Its not the first time we have this kind of trouble.
Yes, and this is the reason why I wrote my mail. We NEED to look for
ways that this CANNOT happen, because it really is a showstopper that
frightens people to use Fedora. At least I have heard people complaining
about this over and over again, for example at fedoraforum.de
I Agree this should not happen but, ask first why there is a broken
deps on some packages and why this happen.
I guess most of the time it happens because of a lack of communication
and coordination. But if all packages are owned by the same person this
reason IMO is not valid.
This leads me to some questions:
1. Why is # 425831 still in status "New"? It has been
reported on Dec 16th and the maintainer already responded to
it.
2. What's so difficult to coordinate 2 (3 with wammu)
dependent packages? All are owned by the same packager. IMO
this should be done in one single update in bodhi.
It's not difficult, it's not my first update of gammu
collection/dependence package, and it's not the first time a upadte
depended release.
Then you should have known what happens... ;)
Once again: I'm not here to blame someone.
3. Do we need better training for our maintainers or
more
documentation in the wiki? The broken deps already
appeared in EPEL before they were in F8, so the maintainer
should have known that he's breaking something when he did the
gammu update in Fedora.
I think we should set up and automate or web_api to request repo tag
for package we wanted to build against fresh released one
to build other into koji/mock from repo
I agree that the current situation is not optimal for the packagers
because the required packages have to be added to buildroot manually by
rel-eng. But AFAIK we do have the possibility of chain-builds now.
4. When was the testing done? gammu-1.17.0-1.fc8 was
built on Dec. 22 11:22:28 MST [1] and hit the updates repo on
Dec. 23 22:50:08 [2]. This is less than 36 hours for testing.
For that, we could make a bodhi policy. Cause no rules say all package
Must go to testing-update before move to stable one.
You are right. I thought we already had policy for that but the wiki
says:
"If you feel that community testing is unnecessary for your update, you
can choose to push it straight to the stable fedora-updates repository
instead."
IMO this is wrong, it should only be allowed for security updates.
5. Why has gammu been pushed directly to updates and not
to
updates-testing? According to the changelog it was not
a
security update.
Why does only security update should go to stable ?
Because problems like this case most likely would have been realized in
testing before they annoy a large number of users. Pushing updates
directly to stable renders updates-testing useless.
Note that I don't want to blame a single person here. I think
this is just an example that we really NEED to think about how
to avoid such situations in the future? I know there are
people on vacation these days, but there are enough people
that offered help. Unfortunately they are not allowed to by
the ACLs.
I'm not here to blame anyone too but this thread should up many time
ago. on differente pacakge that broken yum udpate in the past, not
only this one.
Let's not talk about the past, let's talk about how to avoid this in the
future. There are several ways we could try to accomplish this: Some are
more strict policies, others are more technical, but most important I
think we should get rid of the "don't touch other peoples
packages"-attitude. If someone fixed that within one or two days I
wouldn't have written my previous mail.
Christoph