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.
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
> 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
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
> 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.
devel mailing list -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org