On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote: > * CI/automated tests run on it, and if all is ok goes out in the next > rawhide compose. > * If not ok, you could wave the results or build more things/edit the > update until it passes. Hi, so it looks like you are going to remove chain-build from fedpkg, right? It's kind of pain it doesn't work for stable, but if you want to get rid of it for rawhide too, or add some unnecessary obstacles for its usage, then it's a downgrade like the kerberos usage (it's a pain to write my password all the time when I want to do something in packaging, with compare of once-per-year replace of the certificate, but that's another story, which only adds to the feeling of making process more and more painful instead of simpler (I heard some time ago something like this "security by obscurity", with which I fully agree)). I chain-build like this "A : B : C D", which means in stable that I build A, then fill override, then I build B, then fill an override, the I build C and D and then I fill the update. I hope the difference in stable and chain-build usage is obvious. Anyway, could you enlighten what you call "if all is ok"? That's pretty important measure. What do I do if it's not ok? I do maintain a package which is in critpath. I'm not a proven packager, thus I cannot touch anyone's package (I hesitate to do it anyway, even there are cases where are not many other options). If my critpath package changes API and soname versions, then other packages, for which I do not have commit rights, will be broken by that update, but the update as such will build and look just fine. What do I do now? Will I hunt for respective maintainers and co-maintainers kindly asking them to do something about it? The paper work around this (finding who it is, their email addresses, writing them a mail) would be a pain on its own, but more painful would be the delay in the delivery. It will not be rawhide anymore, from my point of view. I'd rather prefer to have detected issues in updates early (though it's understandable that doing API/ABI checks after each package update is not doable at least due to resource requirements - thus you'd not detect it with the gating too, right?), or at least like once a day. I did a soname version bump in one of my packages recently and announced it, with a list of "possibly affected packages". I know my work flow is wrong in this regard, but I kind of rely on the notifications of broken dependencies to rebuild what is really needed to be rebuilt, because the packages sometimes requires something bigger in the build time, which is not actually used in the run time (just my feeling, no prove available). I didn't receive any single notification of broken dependencies this time. While it's possible someone was just quicker than me, I believe it's highly unlikely. I also believe I didn't filter out any such "broken dependencies" mail notifications from my notification settings, they used to come in the past. That's also another disadvantage of the gating. I recall seeing broken dependencies messages for package I've no commit rights for for weeks. Either the maintainer (or co-maintainer) didn't receive those messages similar like me, or they just didn't care. How would I force them to rebuild/correct (I am definitely willing to help to correct the packages when an API change requires it) their packages, when they already ignore/filter out broken dependencies notifications? Should I hunt for a proven packager to move things forward, thus other packages can rely on the provided change? Proven packagers have their own work to do to, they cannot be disrupted from their work every other day by hundreds of packages to help with the packages their update broke. By the way, why was the compose of rawhide broken for several days? Corresponding people/packagers not being available? It looks to me that you just want to move the issue to a slightly upper level, but then you'll have working rawhide compose, which will not use the recent/bleeding code. It is, from my point of view, the main credit of Rawhide, to be on the bleeding edge. It would be very sad to turn Rawhide from 'package update' to 'people hunt' task. Just my opinion. Bye, Milan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
