-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 14.1.2015 v 15:53 Dennis Gilmore napsal(a): > On Wed, 14 Jan 2015 10:48:16 +0100 > Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > Dne 14.1.2015 v 00:24 Dennis Gilmore napsal(a): > >> On Tue, 13 Jan 2015 15:58:51 -0700 > >> Kevin Fenzi <kevin@xxxxxxxxx> wrote: > >> > >>> On Tue, 13 Jan 2015 15:50:06 -0700 > >>> Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > >> > >>>> You forgot "too many packages?" There are 15842 packages in > >>>> Fedora 21 and 16230 in Rawhide. That is a lot of packages that > >>>> have to be rebuilt possibly multiple times due to FTBFS, multiple > >>>> architectures, etc. > >>>> > >>>> 2.5 weeks is 25200 minutes. That means a mass rebuild is doing > >>>> 0.6 packages a minute across 3 architectures. That is pretty > >>>> darn fast > >> > >>> The Fedora 21 mass rebuild took about 40 hours. ;) > >> > >>> That's really not the reason for more time, its the fallout from > >>> that. When the mass rebuild is tagged in, sometimes there's > >>> things broken in the build root, those need humans to look at and > >>> fix. Then, there are all the packages that didn't build for > >>> whatever reason, those need humans to look at them and fix them > >>> up. The ones with broken deps need fixing, etc. > >> > >>> So, while the mass rebuild itself is less than 2 days, it takes a > >>> while to stablize things after that. If we branched right after > >>> the mass rebuild we would have to then stablize both rawhide and > >>> f22. > >> > >>> It's hard to say how much time we really need there... it depends > >>> on how much stuff got broken, how hard it is to fix and how much > >>> time maintainers have to fix things. > >> > >> right. in the past the building took around a week or a bit more, we > >> have gotten that down. which is why I said we could drop the 4 > >> weeks to 3. the time consuming part is the cleanup and fixing of > >> issues. that needs people. If everything is perfect a week could > >> well be sufficient. Ideally we want secondary arches to be done in > >> the window as well. just to make sure that there is no fallout on > >> them requiring a second rebuild. which could also happen on > >> primary. we have had ABI issues etc in the past on all arches. > >> > >> Dennis > > > What I would love to see is to leave out the packages which are build > > in side tag from mass rebuild. > > > E.g. if I have side tag for Ruby, I rebuild every package in the side > > tag in two weeks before mass rebuild, I can hardly see any > > justification to build them once again (unless there lands gcc in the > > man time or something like this). So if you could exclude the > > packages which are already build in side tag from mass rebuild, it > > would help you with following merge and it would give me additional > > time to rebuild Ruby packages. > > > Is something like this feasible? > > It really depends on a lot of things. like does gcc 5 land after you > have started your builds? we can go about excluding things viaa few > different means. but it all really depends on a bunch of currently > unknown factors. > > Dennis Yes sure, depends on precise timing. It could be also solved by sidetag mini-mass rebuild ... Vít -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUto6kAAoJEAzgnueZF7h8CEYQAIVjaHhx6MxII4XaRLygGEoB iJqiH1D0b2FWmPwwAVMQ0Lzqibj19VbyLqm9+3FsxZcSs4X2uJ4oACKJlAAfv4Yc imK4oMQiB4iSnOpxk5IFQpDvm1yU+1yl6S7O3CA/R/sLOzXuM+nd7iqWwkVYYG2V 1vvilhLKcwm51wDJ+HlIvmIWFjR0yRy1Q8LFybdveKR3XlJHIPhAY+F8BHRM8SfI tcQ46lS/YOQYZa0VDxO3x6pY6759OOHEI02DQG7agU3KT15Vk6Cg4qw9HUXoJDvM IN35Wnr/nFKfwwxRYyQWYBNnfXnK1KM8UONNG+wQ/ieXTQet7/DWLWLzfr4Dccz0 FZ30tirxhX7UDinKgk6sYytxjxbQGOdb8NB3KO+/ddmFQN5FMnWhiEWQGitHt221 vHil3HV6FaUQ71c7hBWWQftOIDbRIUaz4oH3NCzw0tnilQzq2CWmVekYip0zQ+/u c1HoMUu1B+JddklZJ+a6Ad92eKEZiJCsZESJDxN71SNgWTpy1DOXPAiIUsFQBdJp X+Lr9SMc515UME1uvEBC7RO5ufC7cWoCq1KkCm1J5xViX3UR5KTcbMuVVdqPgegM 7taueRHcn2HX3+8LcC5ZTgTWaPX26IXwWZQ3y86Yd/oIqTwC6obJY4g9GcBodFdx sQxIvjcwJSBYsVSUBEbo =B71B -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
