On 4/20/06, PFJ <paul@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Which is why extras would be a better place for them. The extras push is > typically 12 hours after the rawhide one. I think addon kernel module packages should be in Extras for a number of reasons. 1)Extras has an established packaging guidelines for kernel modules now. GFS would be a very good test of those guidelines and the associated review process :-> 2)Community members can work with the primary maintainer to deal with daily rebuild sync issues. It will be a hell of a lot easier if multiple interested contributors were helping with making sure there was a daily extras-devel build to sync with rawhide. Even if it moved to Extras, without automation its still can't expect a single maintainer to be able to kick off a rebuild every single damn day. Right now the community contributors who care about GFS get to sit on their hands and be frustrated because "we" don't have access to the Core buildsystem to make this smoother. The only testing being done are by those people who are going out of their way to rebuild the srpms locally on their systems with every rawhide kernel.. which quite frankly is a waste of duplicated effort and quite limiting in terms of the potential testing base. And "we" in the community can't do anything but throw stones at the maintainer to fire off a build every once in a while... pointlessly. But lets be clear automated triggers would help if it moved to extras-development as well. 3The kernel modules are clearly addons since they arent in the kernel packages... that screams not Core to me. But lets me clear this is not a lack of "caring" on the maintainers part. The problems associated with the rawhide sync of gfs are dominated by the technical limitation of the Core buildsystem, the public push cycle of rawhide and the lack of access by interested community contributors who would like to help with the effort. And the same exact problems would happen for any standalone kernel module packages in Core. -jef -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list