Fedora.next in 2014 -- Big Picture and Themes

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/23/2014 06:13 PM, Matthew Miller wrote:
> On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote:
>> Read all the above sequentially. My point is that although you
>> are technically correct that no WG has proposed doing away with
>> the repos, the RPM format, or yum/dnf, their plans - under a
>> reasonable interpretation of the discussions so far - still
>> invalidate the assumptions he is currently making: he can no
>> longer assume that all he basically has to worry about is getting
>> 'Fedora' installed somehow and he can then install whatever he
>> likes. Broadly stated, it will no longer be valid to conceive of
>> Fedora as a large package repository with some installation
>> methods attached to it, whereas currently that's a pretty 
>> reasonable conceptual framework that I believe many people (not
>> just Tom) employ.
>> 
>> In other words, Tom was really correct. ;)
> 
> Well, maybe. It really is the case that nothing is finalized and
> it's a legitimate concern. This is why we (and here I'm using "we"
> not in the royal sense but because it really wasn't just _me_) have
> the Base Design, not just three separate product working groups. I
> share the trepidation about adding more bureaucracy, but also seems
> pretty important to keep a coherent shared base.
> 
> It's possible that eventually it'll be kind of hard to go from
> Fedora Workstation to Fedora Cloud, or from Fedora Cloud to Fedora
> Workstation -- but that's not _really_ so different from how it is
> now, where if you start from one of those and try to go to the
> other, you're going to have to tear down a bunch of things first.
> On the other hand, the Cloud WG made the ability to go from Fedora
> Cloud to Fedora Server an explicit goal.
> 
> Either way, I think it's pretty likely that someone who wants to
> start with the base and build up will be able to with, with varying
> possible degrees of difficulty. It may also end up that it's easier
> to make and share specific, lightweight remixes, so that while you
> don't necessarily build up in an install, you do it in a tool of
> some sort -- that was part of Stephen Gallagher's original
> "products" idea, if I'm remembering right.
> 

That was originally one of my moonshot ideas, yeah. I've subsequently
toned down on trying to push for that as I've been told from several
directions that this would put a significant strain on
release-engineering. I think it's still worth looking into way to
improve our existing tooling (and make spin-generation not suck so
that we could make it easier for spins to evolve to products), but
I've stopped trying to trumpet it as a primary objective.


>>> So yes, there may very well be different options.  That doesn't
>>> mean they can't also be the same if you choose not to use those
>>> different things.
>> Is that going to be a reasonably sustainable approach, though?
>> It's at least possible that it won't. What if the Desktop
>> 'product' starts caring much about shipping commonly-used desktop
>> applications as 'app bundles' rather than packages? What if the
>> Server 'product' implements Wordpress as a container image rather
>> than a package?
> 
> That might happen, although I would be shocked if anyone has
> anything near workable for F21 timeframe. Or F22. But, would it be
> so bad? People who are interested in packaging it in the
> traditional way still could... or, at least _I_ hope so -- that's
> been part of my version of the proposal since the beginning.
> 

For what it's worth, I still want (personally) for us to be deploying
using RPM for its other abilities (like maintaining a useful inventory
of software on the system). However, I'm not ruling out the
possibility that we might be willing to start shipping RPMs inside the
Fedora Repositories that contain inside them essentially a docker or
qcow image that we then deploy into an isolated environment to
actually implement the Role functionality.

Yes, this would be a big divergence from our current guidelines and
would need serious discussion on feasibility. No, I'm not asserting
this is the right way to do things, merely one possible approach to
consider.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLitJAACgkQeiVVYja6o6ONLQCgneb9p7asfW8t7Nc1nO4eYhyP
xlsAniHrICryRNJ4A/2NXP62BD8/eJaG
=3S7P
-----END PGP SIGNATURE-----