On Thu, Sep 10, 2015 at 10:43 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Thu, 2015-09-10 at 09:53 -0400, Stephen Gallagher wrote: >> I assume that subject line got your attention. >> >> I know this is a long-standing debate and that this thread is likely >> to turn into an incomprehensible flamewar filled with the same tired >> arguments, but I'm going to make a proposal and then attempt to >> respond to many of those known arguments up-front (in the hopes that >> we can try to keep the conversation on-track). Please keep the >> conversation on devel@xxxxxxxxxxxxxxxxxxxxxxx . I CCed packaging@ to >> make them aware of this discussion. >> >> >> >> Right now, we have a policy that essentially forbids source code from >> being bundled into a package. In technical terms, this means >> essentially that the packaging policies mandate that any code that >> appears more than once in the repository must be turned into a shared >> library and dynamically linked into any package that requires it. Any >> package that wants an exception to this must petition the Fedora >> Packaging Committee and get an explicit exemption from this policy. >> This process is heavyweight and sometimes inconsistent in how the >> decision is made. > > I'm in no way a fan of the current wording of our policies here - it's > extremely vague and, as you say, subject to various interpretations. > It's also known (though perhaps not by all?) that we are nowhere > *close* to actually meeting the policy as written, most obviously in > the area of webapps: I think every webapp in the distro still bundles > Javascript. There is/was an effort to try and unbundle JS; the current > state of play seems to be nicely encapsulated in > https://fedoraproject.org/wiki/Changes/jQuery , which is an F23 change > to unbundle a *single javascript library*, which appears to be stalled > or at least behind (viz the cheerful "Coming Early July!" messages). I > know of (and in at least one case am the maintainer of) various other > packages which have code that's clearly 'bundled', under a strict > reading of the existing guidelines. > > Writing a new policy is something that should be done very carefully, > though. > > To me there is a clear ecosystem angle on this. What's appropriate for > the core ecosystem of stuff written in non-bundly languages (C, > Python, Perl...) is not necessarily appropriate for Web 2.0-ish things > written in bundly languages (PHP (oh god PHP), Go...) > > To me this naturally ties in with the Fedora.next and 'rings' changes. > I'd suggest that a good direction to look in would be different > policies for different 'rings' (or however we wind up conceiving of > different areas of the distribution). I've argued before that it's > difficult to clearly delineate rings/layers of the distribution, but > it seems we are going to be trying to do so in some way, and so long > as that's going to happen, it seems natural to attach any change of > the bundling policy to that effort. > > I'd also suggest that we might still want to forbid bundling of *some* > things in layers where it's otherwise permitted. Your policy, for > instance, would allow us to package something which bundles glibc, if > it does not have "an existing mechanism to link against a shared > system [copy]". Do we really want to allow bundling of the things > which *do* play by The Old Rules - the core infrastructure stuff which > is still, by and large, developed according to those conventions? AdamW brings up a good point about different rules for different Rings, are the different Rings considered in the proposal at all? -AdamM > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
