On Thu, Dec 13, 2018 at 11:04:47AM -0800, Kevin Fenzi wrote:
How does this play off available resources? If say someone came
along
and wanted to make a solution where a bunch of the resources would need
to be created (code, test plans, content), it would be up to that group
wanting the solution to provide the work to do that? ie, some resources
are much easier to hand over (disk space, cpu) and others are a lot of
work (code, test plans, docs). I guess this is up to the resource
provider how much they want to provide and at what point they say
"sorry, you need to write that yourself"?
Yeah, I think that last thing is pretty much how it should work. After all,
you can't create resources for work just by wishing for them (oh, if I
could!), and you can't make a volunteer community volunteer. What we'd like
to see is for service providers to provide a set menu of options, and for
each option give a set of requirements. For example, perhaps Mindshare will
fund release parties up to $150 for the release of *any* formally defined
solution, but offer $500 for solutions with a user base above NNN as
determined by Fedora metrics. Websites might offer a pre-canned website to
anyone with downloadable release artifacts (isos or qcows or whatever), and
offer some customization services to solution teams with an organized team
which meets at least every other week.
We'd actually started to more formally define some pre-set labels and
example services, but that fell into "naming things is hard" pretty quickly.
And, we don't necessarily want to give the impression that there's a
hierarchy that all solutions need to climb. For some things, serving a niche
use case very well is exactly right.
This all sounds fine to me, but is pretty abstract. Also, how are
disputes handled? I guess they come to the council? If say, releng was
happy with a 6 month cadence, but developers wanted faster?
There's a separate assumption that we want release engineering to allow
people to release their own solutions pretty much at will. There will be a
base Fedora OS release -- possibly a "base OS" smaller than current
all-the-RPMs -- which will have an underlying cadence (probably still six
months), and that's a fundamental we expect a lot of solutions to build on.
This is stuff for the Lifecycle objective to figure out.
Would it be possible to work up an 'example team' showing how to
document this or perhaps someone could write up what the _current_
blocks and solutions and elements are for the existing teams? I'd guess
each team would have to write up something and each 'solution' would
also need to write up something with all this spelled out? And solutions
would use elements, a, b, c, and make their own d, e, f? Or could they
only use existing elements?
Yes, that's definitely the idea. Providing an example is a good suggestion.
In fact, the Council could do this for some of the things we do directly,
like providing Hackfest funding.
I'm somewhat at a loss how to do this for the two teams I am
most
involved with (infrastructure and releng). More guidance would be nice.
*nod*
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader