On Sun, Feb 09, 2014 at 06:56:41PM +0100, Bill Nottingham wrote:
So, from a user perspective, what does this buy us? If (for example) the only reason it's not in the main repo is that it has bundled libs, what are we accomplishing by making the user have an extra checkbox?
If it's *just* bundled libs (or depending on your perspective, "just" bundled libs with scare quotes), not very much. In that case, I think it would just be a decision based on whether a new repo structure or allowing bundled libs mixed in would be less work overall.
But I'm thinking that there are probably a whole host of other things. So, it makes it at least a little more clear from a user perspective that this might be not as pretty. I'm not necessarily opposed to letting the idea be tried for a couple of releases as optional and if it's not destroying the world, enabling it by default. Possibly software installers could present visual cues based on repo policy level.
IOW, why not just restrict the super strict guidelines to the core product repos of Fedora, and have this repo be for things outside of that, which can include things that follow the guidelines, and things like chef that don't.
I think there are different levels here. If we keep the core reasonably small, we can more reasonably say things like "must be ported to systemd timer units" for that subset.
Also, I hear from a lot of Fedora developers who strongly believe that even if we allow messier software, improving the packaging quality is still important. The idea of calling this "staging" or "incubating" implies that packages at this level can be "in" easily but are expected to be polished over time, with the aim of graduating to the fully-FPG-compliant level.
(At the DevConf panel discussion, someone (Stephen, I think) made the suggestion that packages that aren't aiming for this could comfortably live in COPRs forever. Or, we *could* have both fedora-incubator and fedora-ugly, but I don't know how much value that gives.)