On Mon, 11 May 2009 17:46:48 +0200, Ralf wrote: > >>>>>> (1) New package. > >>>>>> [cut] > >>>>> Is it a good practice to push a new package to stable? > >>> No. > >> I strongly disagree. Adding "stable" packages to stable is the primary > >> interest contributors are after. It's the #1 reason, why Fedora Extras > >> one had been launched. > > > > Cool down and slow down, at least a bit, please. > > Why should I? Because your reply above looks a lot as if you misunderstood the question. And in case you didn't, it doesn't become clear why "stable packages" should not spend 1-2 weeks in updates-testing? Why rush? What do we win by doing it? Impatient users can get the released (!) packages from the updates-testing repo. There's nothing wrong with disagreeing. I just see that skipping updates-testing leads to more problems. > * Fact is: In the overwhelming majority of all cases, testing is > effectively a delay queue, and a PITA to developers. > > * Fact also is: "Testing" doesn't help wrt. packagers doing a poor job. Depends on the level of poorness. Ignoring feedback in bodhi and ignoring negative karma in bodhi is bad, yes. Fortunately, there are only very few half-assed packagers who don't take -1 karma votes serious and who would show other PITA attitudes. > * Fact also is: "Testing" occasionally is the cause of broken package deps. How? Or, what do you mean? > > Fact is that one packager plus one reviewer are not enough > > to ensure that new packages really work good enough to call them "stable" > > for one or more dist targets. > So you are demanding for even more bureaucracy and for more @RH deitism? > This would be truely silly. If packagers, who try to maintain a hundred packages, are concerned about artificial hurdles and "bureaucracy", it's not my role to disagree with them. Voice your concerns as much as you like. I expect a committee of Fedora leaders to influence [or decide on] the road to take. It is beyond my energy to fight endlessly and with continuing intensity. It's easier to reduce activity and wish them luck. With F9, for example, I asked myself "why spend any time at all on running repository checking tools if some issues, such as broken deps or conflicts, won't be fixed?" In many cases I'm willing to compromise. A new Fedora dist release is made every six months. That's a rather short period. I don't see what we win by skipping updates-testing. Give the community what it deserves. If there's not a single user who gives positive feedback about a new package [or a version upgrade], then why rush and skip updates-testing? You may be confident enough to perform the necessary testing yourself and take responsibility for breakage. You may be competent enough to publish sane updates only. You may be experienced enough to avoid poor mistakes. Still, there are other packagers who release broken updates or who don't understand how to fix them. What can be done to increase the quality of updates? Maybe it needs a privilege bit like "provenpackager" to skip updates-testing? I don't know. I just wish some people would be more conservative (or "shy") in what they choose to push to multiple dists without any testing. > As far as I am concerned, it's this freaking freeze and run-down shape > the fedora repso currently is in, which is causing the mess. In case it's not known, I've never backed up the post-Core freeze process. The long time of inactivity in Rawhide, the growing pile of pending updates, the massive amount of zero-day updates, and the increasing number of unknown broken deps in the uninstallable FN+1 Rawhide have confused me and caused me to raise an eyebrow. Something's wrong with how package developers follow Rawhide/Alpha/Beta (or the Test releases previously) and when/how they start to prepare their packages for the next Fedora while Rawhide is frozen. The thing simply is, in a community of volunteers (with some Fedora staff being paid by Red Hat and a muddy situation with Red Hat developers who happen to maintain Fedora packages) I don't see any organisational structures and hierarchies that would be possible in a company. I can't tell any other Fedora person to do this or that, and I don't want to deal with -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
