Jesse Keating wrote:
> It's easier to get it into a freeze than it is to issue an update to the
> release...
>From a maintainer's perspective, it's actually not, and this is probably one
of the issues with our processes at hand here.
Freeze break: file a ticket with rel-eng, in an interface not explicitly
designed for package updates (which makes it clear you're talking to actual
humans and requires you to actually explain what you want in some form of
sentence), justify the change, explain why it doesn't break anything, wait
for 2 rel-eng members to explicitly approve it, and expect to be questioned
if your justifications are insufficient.
Update: fill it in in Bodhi, no explanation required at all (people file
updates even with blank descriptions and get away with it!), wait for the
next push. Only occasionally you or mschwendt will ask what the point of
the update is, or somebody (often mschwendt) will point out some broken
dependencies, and even in those cases it often ends up getting pushed
anyway. If nobody notices, it gets pushed by default (quite the opposite as
for the freeze breaks).
And no, I don't think requiring the same amount of bureaucracy for updates
as for freeze breaks will scale. (Updates already take too long to go out,
and I also think the workload would be too high for rel-eng.) I do think
blank or uninformative (e.g. "new upstream release") descriptions ought to
be banned though. Most likely a common process with some sort of middle
ground is needed, though I'm not sure how exactly it should look.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
