On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > > Debian has a completely separate installation of its equivalent to Koji (the > dak part, the builders are separate from archive management). Nowadays, it's > source code is mostly up-to-date to what the main archive uses, but there > are still lingering data synchronization issues. That's a lot of work for not a lot of benefit. Our Koji system should be able to be extended to handle these extra use-cases. And as it is, we're trying to get rid of duplicate Koji instances. > > For Fedora, I would suggest to replicate the separate security archive with > its push mirrors. The way the Fedora updates repository is updated seems to > cause far more delays than what is lost due to build delays (the only part > the embargoed builders could improve). > There's no point to this, since our updateinfo metadata includes the classifications, and the Debian/Ubuntu approach means that the same package needs to be pushed to both the security repository and the regular updates one. This is not great for keeping things sane for mirrors. However, extending Koji to support "hidden builds" is certainly a good idea. From the SCM side, I'm not sure if gitolite supports making private branches. At least it should be possible to give each package a shadow git repository in a separate namespace (as mentioned earlier) that would be private for doing these kinds of builds and releases. Upon merge to the public repository, the builds could be marked public to Koji (since the commit hashes should remain the same post-merge anyway, we can track using that). -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
