Hi, On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote: > 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. well, it's not better, it's worse. I could not just run one command and let the computers do the task on their own, I just check from time to time whether anything broken, but I'd be supposed to babysit whole build process with the packages from the "chain-build"? That's truly worse, needs more of my time, while the koji can do it on its own. Computers are here to help people, right? :) By the way, I just successfully ran chain-build from an f28 branch. https://koji.fedoraproject.org/koji/taskinfo?taskID=25654934 That surprised me, I expected to be kicked of, as it used to do, but it didn't do it (it used to kick me off in the past, especially after branching/bodhi activation point). I wanted to try whether chain-build with --target would make the trick, it also used to work. > I'd like to see a 'no new broken deps' test/check... but we could > change the tests over time. Yeah, that's it, without such test you just make obstacles to packagers with no gain at all (if broken deps are recognized only after pushing the side tag into the Rawhide, then it's really only about unneeded obstacles). > You request a side tag, Who is going to respond to it? Will it be automated, with no specific people being involved? Automated side tags sound wrong, from my point of view. Hunting for people in different timezones to let me do my duty sounds even worse. > build your new package in that, then tell all the dependent package > maintainers to use that side tag to rebuild all their packages. Oh, having multi-process synchronization is kind of unsolvable problem (if I recall my college study properly), how you'd like to synchronize the process between people in various countries and time zones in practice, while limiting the delay to a minimum? > All those people should be watching your package or at > least easy to communicate to. Watching a package and/or have commit rights usually brings in tons of unrelated stuff in your Inbox. Yes, there are settings, but I cannot decide which changes are relevant to my package and which not unless I read the info about the change. After some time one can just ignore most of the messages anyway (people do lack of time, the more those volunteers in the community). > > 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. Definitely, and it's the main point against gating Rawhide. If people cannot react in the timely manner right now, with already working infrastructure, how is the gating going to help and address this problem at the first place? The gating will help to have buildable composes all the time. That's its main purpose, right? Then it'll help with what? What is it good for to have buildable composes, when they are using outdated software? All the QA work will be wasted on those composes, because of delay of some package update due to the gating. > 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. Maybe they have a reason why they want to have as less people on the package as they can. Or they can miss some notification from "pkgdb" (I know, it's not pkgdb these days) or have it lost in the spam folder... And it's a bad idea to expect that other people have time to work on Fedora just at the moment when I decide to push in some giant API change, not talking that many of the packagers just do "proxies" for upstream, they possibly never touched the upstream code to be able to fix anything in the code, thus they rely on response from the upstream, which can add even more delay in some cases. Not talking that unresponsive maintainer process should be started only after some time of inactivity of the package maintainer. > 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. Oh, I'd not like to go that far, for basically the same reasons as in the previous paragraph. > 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 see, that's understandable. How is rawhide gating going to help with this in practice? (Search for 'outdated software' above.) There will be still needed some people looking into the issue and spend their time on it, maybe they will be in less pressure, but I'm afraid it'll be just a feeling. Nobody should expect infrastructure folks understand each package (like you mentioned systemd here), at least I do not expect it, thus I'd expect you had some coordination with systemd package maintainer and its upstream to find out the root cause of the problem. Was it any smooth? Did it even happen? Might each maintainer of a crit- path package (or a package which has some users (libraries)) do the same round trip as you did for the last week? > * Bodhi enablement was also this week... Yeah, I've been always wondering why the timing with Beta freeze and Bodhi activation is so bad. There is a GNOME stable release this Wednesday, the 3.28.0 version, and GNOME is the desktop environment of Fedora Workstation, still these two schedules collide in a way that the Beta contains development version of packages which turned into stable only few days after Beta freeze/Bodhi activation (I've here similar concerns as with 'outdated software' usage above). Anyway, I do not want to change subject of this (sub-)thread, there are other places where it had been discussed in the past, all of this only reminded me of it. > 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. Yes, definitely, though there are still legitimate cases when people do not have time and nobody can do with it anything. That's just life. Bye, Milan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
