Re: Schedule for Wednesday's FESCo Meeting (2013-08-14)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/14/2013 03:51 PM, Matthew Miller wrote:
<snip>
Would we be defaulting and or recommending one application over
>another in "Fedora server" for example openldap vs 389ds, kvm vs
>xen, postgresql vs mariadb if so why?
Ideally, we avoid tying ourselves down, but I think any such recommendations
would be based on the level of support we're able to give to those things,
and, again, how how they fit the goals we define.

As I see it both the labels of "default" and "recommendations" cannot be apply to a community which provides multiple application and solutions and "best effort" in maintaining that by an fluctuating number of any given contributors at any given time.



>Given that the above proposal are not direct products of SIG's who's
>in control of what goes in and what goes out of the Fedora
>Workstation, Fedora Server, and Fedora Cloud and their target
>audience ?
I think it's reasonable to have more formally-structured Fedora teams for
each of these things. What do you think?

What I think in that regard is that the SIG or sub-community already have established an governing structure around themselves,their target audience and the product they have decided to deliver to their target audience so adding an additional layer on top of that will have negative effects on the ecosystem they have established for themselves and live in.

>As I see it the above part of the proposal only splits the "default"
>product into three different "products" without actually solving
>anything.
These particular suggestions came from looking at some of the different
requirements the project has overall, and concluding that no single default
really addresses them well, but that these three areas cover important
areas, each worth investing resources in.

Which areas are of importance is in the hand of the beholder.

In other words each sub-community and what they are doing is important to them and those "three" areas by no means cover all the sub-communities that currently exist and might exist in the future of the project thus from my perspective this proposal thus is flawed and not future proof as the community continues to expand.

With regards to resources investment pulling resources from one aspect of the project to put them into another will only cause imbalance within the overall existing ecosystem but you have to be a bit more clearer what you mean by "each worth investing resources in" as in where are those resources coming from or taken from and what are they?


>Since I dont see how that you propose addresses and or solves any of
>the issues we are faced with I argue the way forward for us should
>be that Fedora "products" are the results/publication of each
>sub-community but not creation of whom releng/fesco/board specific
>Fedora individual or as an whole Fedora Workstation, Fedora Server,
>and Fedora Cloud SIG?
Can you rephrase this? I'm not sure I understand. If you can articulate what
you mean by "issues we are faced with", that would help, too.

We have competing projects,products or application if you will in the project that are aiming at and competing for the same user base.

Putting one of those at a higher level by default, by recommendation or even just by placing it on the front web page puts the others at disadvantage and will hinder growth and participation in the relevant sub-communities which will result in worse product and in turn will have negative outcome for the project in whole. At least that is how I see it.

JBG
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux