On Wed, Oct 26, 2016 at 7:45 AM, Neal Gompa <ngomp...@gmail.com> wrote: > On Wed, Oct 26, 2016 at 7:33 AM, Florian Weimer <fwei...@redhat.com> 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).
This is directed at the whole thread, not Neal. Here is the problem with all of this. We have plenty of ideas, but nobody willing to do the work. So you can all continue to throw out ideas and question estimates, but until someone signs up to actually start coding things across whatever stacks are needed, nothing will change. If anyone is really interested in solving this problem, it's time to roll up your sleeves. We need code now, not ideas. josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
