On Sat, Sep 24, 2016 at 03:44:55PM -0400, Ben Rosser wrote: > Let's suppose I submit this repository to consideration for inclusion in > Fedora Workstation, so that if someone searches for "Dwarf Fortress" and > consents to be shown nonfree, third-party software, they can optionally > enable my repository and install my RPMs. However, it does not meet the > guidelines for inclusion on other editions, and I'm not interested in > fixing that for whatever reason. But that's okay, because if someone > _really_ wants to run this game on another edition, they can run "dnf > thirdparty enable tc01/dwarffortress", or something like that, provided > they know the repository exists. So far, so good. I don't know if anyone is working on anything like the "dnf thirdparty" thing you suggest, but it seems reasonable enough. > Now let's suppose someone _else_ wants to package the same game, but for a > different edition. However, their package chooses to put game data in, say, > ~/.local/share/dwarffortress/, and ships with a slightly different set of > associated utilities. (Or perhaps different versions of said utilities). > Their repository is approved though, because it meets the guidelines for > the other edition. This is one of the reasons we didn't want significant overlap in the targets for the different editions. However, if we get into *spins* (where overlap is fair game!) approving external repos, I can see the potential for a mess developing. [...] > Now, possibly when the second person proposed the repository shipping the > same software for review, the reviewer _should_ have said "hey, Workstation > already signed off on a third-party repository for this software, why don't > you try to collaborate with them", and only approved the second repository > should there have been some fundamental reason that reconciling the two > repositories was impossible (differing package formats for each edition, > etc). Maybe that is what will happen, or perhaps this is a problem fixable > by some sort of repository review tool that doesn't need policy. But this The above seems like a decent policy if it turns out to be needed. -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ council-discuss mailing list -- council-discuss@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to council-discuss-leave@xxxxxxxxxxxxxxxxxxxxxxx
