Fedora.next in 2014 -- Big Picture and Themes
tom at compton.nu
Fri Jan 24 09:41:05 UTC 2014
On 23/01/14 18:48, Josh Boyer wrote:
> On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes <tom at compton.nu> wrote:
>> Even the formation of the working groups was odd - the original decision to
>> form them, as I read it, was that they were to explore the idea of doing
>> these three streams but within days it seemed that the question was no
>> longer whether to do them but rather how to do them.
> I can see how that would be confusing. I always understood it to be
> "these WGs will be formed and they will be tasked with figuring out
> how to create their respective products". Perhaps some lack of
> clarity in the proposal?
I've been digging back through the list archives and various other
sources trying to determine where my view of this was founded, but not
with a hug amount of success so far. The best I have come up with is
your report to the list of the board's decision:
Where we are told that the board "agree with the development of a
working group to describe an implementation proposal for the future of
Fedora" which sounds like the idea is to make a proposal for how to do
things in the future, which might then be accepted or rejected.
By the time Fesco is discussing the creation of those groups (for it has
now become multiple groups) a week or two later the proposal the groups
are being asked to create is not a proposal as to whether to change but
rather a proposal for the specific way to do the change.
In other words the question seems to have changed from "whether to do
it" to "how to do it".
Of course this is all reading a lot into that one initial sentence in
your email. I think there were probably other things that helped build
that view in my mind at the time but I can't find them right now.
>>>> That's why I got the feeing a lot of contributors are simply waiting
>>>> for more concrete details to emerge before deciding what to make of
>>>> Fedora.next; or they simply at all don't care to much what the higher
>>>> ups do, as getting involved on that level can cost quite a lot of time
>>>> and can be frustrating (that's not a complaint, that's simply how it
>>>> is often; wasn't much different in my days, but noticed that more when
>>>> I wasn't that active an more myself).
>>> If they are waiting, what are they waiting for? If they don't care,
>>> and they just want to maintain a package or 30 packages, is there
>>> anything that you see in Fedora.next that would prevent them from
>>> doing that? There will always be varied level of participation, and I
>>> think we need to have a development model that encourages that and
>>> allows for growth. I don't think Fedora.next gets in the way of that,
>>> but I would love to have other opinions.
>> To be honest my concerns are more with my user hat on than my contributor
>> hat - that we will lose the gold standard unified packaging standards and
>> single source and mechanism for installing packages.
> I haven't seen anything from any WG that would suggest a deviation
> from RPM packaging guidelines or using separate repositories. It is a
> valid concern and one we need to keep an eye on.
Once again the facts don't entirely seem to chime with my memory... My
memory was that each WG had been explicitly told that they could propose
alternative packaging guidelines for their products. In fact a review of
the original call for WG nominations suggests that only the end and
stacks group were given that freedom, specifically they were tasked:
"to work on policies and practices for software operating outside
of Fedora's traditional packaging model
Of course if you see env and stacks as sitting between base and the
three product groups then that effectively impacts on all the products
because if they start encouraging alternative packaging and policies
then the product groups may use that and render it effectively
impossible to run anything beyond a barebones system using the
traditional Fedora model.
A lot of the time I will have been reading all of these things coloured
by knowing that they derive from the original Fedora.next proposal which
appeared to be all about weakening packing guidelines and making it
easier to shove stuff in and to encourage use of various upstream
packaging systems in place of Fedora packaging. So there will have been
an assumption in my mind that the real agenda all the time is to do that.
Certainly that is still pretty much how I see the env and stacks group
and that is certainly where my major concerns lie.
>> The actual spins (or whatever you want to call them) aren't something that
>> bother me at all, as they are to my mind largely irrelevant for anybody
>> other than a new user. When I bring a new machine up I just want to get a
>> base OS on and access to the package repository and what packages are
>> installed by default doesn't really bother me.
> So... Fedora.next is essentially irrelevant to you? That's OK, it
> doesn't have to be relevant to everyone. And meeting the needs of
> existing users is definitely something that should be taken into
> account. Would you use e.g. Workstation as it's the most equivalent
> to the default Fedora install today? (I realize it's difficult to say
> for sure, given nothing actually exist yet so please allow a little
> latitude in the question.)
Well it's irrelevant until the perl stack in yum starts to bitrot
because everybody is now using CPAN and the ruby stack bitrots because
everybody is using gem and the node stack bitrots because everybody is
using npm and...
Other than that, and provided for example that the roles thing that the
server group are talking about, which I don't really see the point of,
doesn't get in my way when running a server; and that a split between
desktop and server doesn't make it hard to run my personal desktop that
also does server stuff then no, it probably won't matter too much to me.
In many ways the base group may be the most interesting to me, but I
know very little about what they're doing because I haven't managed to
figure out what mailing list they're using or what they're talking about.
Tom Hughes (tom at compton.nu)
More information about the devel