Thoughts on Fedora Server lifecycle

Stephen Gallagher sgallagh at redhat.com
Mon Nov 4 15:19:58 UTC 2013


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

On 11/01/2013 05:53 PM, Miloslav Trmač wrote:
> On Fri, Nov 1, 2013 at 9:27 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>> On 11/01/2013 04:02 PM, Josh Boyer wrote:
>>> So, when Fedora Server 1.0 forks, that is maintained in addition
>>> to building towards Fedora Server 2.0 on the now unstable Base?
>>> This is essentially the idea that Spot pitched at FUDCon
>>> Blacksburg.  If the resources to pull it off are attainable, I
>>> think it will go a long way but the requirements to do this
>>> shouldn't be underestimated.
>>
>> Yes, agreed. I do think that this is a little more achievable than
>> Tom's original proposal though, since we're talking about a much
>> smaller version of the Fedora Project than he was. Here we're talking
>> about a highly-constrained set of packages that makes up the Server
>> default install, which we should be striving to keep as small as
>> possible.
> _Default_ install only?  What about the "500 applications" (to use
> Jóhann's terminology) that are a part of the wider server universe but
> not the default install?
> 
> Where do they live?  Are they released/maintained as part of Server
> N.{1,2}, only not part of the default install?  Or are they outside
> somewhere in the Commons (which would require both Base and Commons to
> follow the Server branching model, or at least to give ABI guarantees
> that track the Server branching model)?

I think we need to be involving the Base Design and Stacks in this
discussion. My *hope* from those projects is that they will be providing
a sensible solution for this. (And I'm not going to assert what that
solution is myself right now; I know it's going to have to become some
sort of balance between packaging purity and carrying the dependencies
an application/service needs).

I'd very much prefer the Fedora Server to be a tightly-integrated
operating system providing a few select services by default that are
REALLY well tested and work together. Beyond that, we should be a
platform for serving third-party services (and that means both Commons
and commercial).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ3ux4ACgkQeiVVYja6o6MqDgCeKEIPPqxtZ9413uC5fm3g94kl
PSYAnjcDMBOWfnlsS2qV0d0lJSzhxw0T
=pwby
-----END PGP SIGNATURE-----


More information about the server mailing list