Milan Crha wrote:
> 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.
+1
> 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 guess then you will need to fix whatever the gating is complaining about
and start all over again. :-(
> 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.
+1
> 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.
Broken dependency notifications are disabled because the scripts are broken:
they still use yum, which does not support the boolean dependencies. It is
sad that this was still not fixed after months. Instead of wasting their
time on annoyances such as update batching and now Rawhide gating, the
infrastructure team should instead spend it to fix the existing essential QA
tools.
> 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.
+1. As a provenpackager, I have other things to do than rebuilding packages
24/7 because everything blocks on the rebuild.
> By the way, why was the compose of rawhide broken for several days?
Because a broken dependency in ANY package included on ANY release-critical
deliverable now fails the ENTIRE compose process. It is clear that this does
not scale.
> 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.
And I have to +1 these last 2 paragraphs as well.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
