On 03/08/2018 11:10 PM, Milan Crha wrote: > 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, yeah, but you would have even better workflow with a side tag. > 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)). Note that if you use KCM (now default) and it works (It has some bugs), you only need to enter your password once a week. Also note that it's much more industry standard, and its much harder to have someone just take your cert and do things as you. 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. Sure, with this proposal you would: * request a side tag * build a, wait for it to be added to the repo, build b, etc. You would not need to file overrides, just build them in the right order with wait-repo between them. > Anyway, could you enlighten what you call "if all is ok"? That's pretty > important measure. If all the tests we determine should gate packages pass. I'd like to see a 'no new broken deps' test/check... but we could change the tests over time. > > What do I do if it's not ok? Fix your package(s) and resubmit for new tests, or if you feel the test is wrong file a bug on it and waive the results. > 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? You request a side tag, build your new package in that, then tell all the dependent package maintainers to use that side tag to rebuild all their packages. Once everyone is done, you (or someone else) submits it for testing as a unit. > 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. yes. You can use dnf repoquery to tell what uses your package and needs rebuilding. All those people should be watching your package or at least easy to communicate to. sure, it might not be rawhide, it will be much more sane. > 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. Not sure what you mean here... yes, we could do a check right before a compose, but then you have a lag after you build your package until it gets kicked out before the compose. Much better to check it as soon as we can so you can know and act on it. > 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. As mentioned downstream the broken deps checking script was turned off because it doesn't understand rich deps. Also, we have had very few f28 or rawhide composes this last week. > > That's also another disadvantage of the gating. I recall seeing broken > dependencies messages for package I've no commit rights for for weeks. Yep. Or longer. > 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. You could ask for commit on those packages you need commit on. If those maintainers don't approve it, ask for unresponsive maintainer process and you will get commit rights. If they still don't show up, you could look at retiring those packages so they drop from the collection and don't bother you anymore. > > 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's been a long trail of things that needed to get worked out. it has nothing to do with availability. A number of people have been spending lots of time fixing things. I personally spent most of my week on this. Some of the issues: * new systemd landed in both rawhide and f28 right before freeze. It added a fsync call after writing/creating the /etc/machine-id file. However, in a installer chroot /proc isn't mounted so fsync fails to write the file, so systemd thinks /etc isn't writable and bind mounts /run/machine-id over /etc/machine-id, which results in lorax failing in a cp -alx command it uses to copy the install tree it just created. That was a fun one.. took up my wed tracking that down. * Modular composes have had a number of issues in pungi. First, adding a Modular compose made things take 36 hours or so because it was gathering modules and trying to sort them into non modular repos. Then that was fixed, but then module signing was messed up before there are no modules made for f29/rawhide at all (There's a module build service bug about that), so we needed to disable them there. Then pungi gathered incorrectly rpms and noarch rpms were not placed in the right repos. There are composes running now with fixes for all that (we hope). * Bodhi enablement was also this week... lots of issues around modules updating that were not figured since f27's fully modular approach, lots of signing issues around how to tell what module is part of what stream, etc. Probibly more things I am blanking out on now. ;) > > It would be very sad to turn Rawhide from 'package update' to 'people > hunt' task. Well, more communication is better. If people aren't responding we should know that and fix it, not just toss packages over a wall and wander off. > > Just my opinion. Thanks for the feedback! > Bye, > Milan > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > kevin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
