On Tue, Jun 2, 2015 at 2:47 AM, Václav Pavlín <vpavlin@xxxxxxxxxx> wrote: > Hi guys, > > I am sorry I missed the meeting yesterday - I had a training I completely > forgot about, but anyway, my comments to the topic(s) follow: > > Gathering of an information for the modularization proposal should surely be > a common effort of e&s and Base - as both WGs has edditions/spins as their > users > > From my pov Base should own intersection of the package set from (all?) > editions/spins/WGs. Thus if we agree on using scl for our modularization, > then yes, it should be in Base's hands to add it the core pkg set. But also > as jreznik said, we screwed up in generating requirements for such > minimal/common package set:). On the other hand whatever is optional and not > THE ONE technology we choose to support should be probably in hands of e&s > so that we don't add bloat to base system. > > 14:47:53 <langdon> msekleta, i guess i am making the argument that if e&s > says "this is how we do x, which relies on y" then e&s needs to work with > base to get y included in base for use by the editions (or other WGs in > general) > > If it is agreed upon that all editions will benefit from that "x and y", > then yes. But let's imagine Workstation decides to use xdg-apps and server > decides to use Docker for similar use cases - how do e&s or Base get > involved in here? By providing a common underlying OS platform layer, whether it be as a set of packages and comps groups, or an Atomic base image. E&S can further aid this by providing additional layers that help the WGs provide API compatibility through scl or whatever other mechanism. Your question is a good one, but xdg-apps and docker are pretty high on the layer stack. They are only one layer down from end user developer/app, so there are lots of things that they need to work well. Maybe Langdon can draw some awesome ascii art to illustrate the layers he's thinking about. I would try, but gmail would mess it up. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
