A few more questions: - Who is going to write/maintain this plugin? :)
- How do you plan on making sure everyone using EPEL is using the plugin? Have a Requires in epel-release? That strikes me as pretty ugly. - Who is going to update all the compose/build tools/scripts to handle this metadata. - How is the metadata added? By maintainer? What if they don't update it? - What are the metadata keywords? * Breakable = excluding this update because it needs intervention * Insecure = this package is no longer updated and insecure ? - How do you handle trains of updates? foo-1.0-1 pushes out to stable <time passes> foo-2.0-1 pushes out, marked 'breakable' because you have to manually update configs. <time passes> foo-3.0-1 comes out, it's compatible with 2.0-1, no changes needed. Does someone still on 1.0-1 get upgraded to 3.0-1 since it's not incompatible marked? kevin
signature.asc
Description: PGP signature
_______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
