On Thu, 2014-01-30 at 06:42 -0500, Josh Boyer wrote:
> jwb has tried to characterize this as an 'opportunity'
> really don't think that washes. It's much more a case of us dumping
> whole lot of extra work onto any who wants to maintain a spin:
> * Get a domain
> * Get a proper SSL cert for your domain
> * Figure out a build process - hack up some scripts which inevitably
> grow into a baroque horror? Deploy your own koji?
> * Figure out a QA process (we have provided a QA process for spins;
> cost us - well, me, personally - a few hours I was happy to spend
> several releases ago, and it's in place and it works)
> * Cover the costs of hosting, or convince someone to distribute your
> * Do all your own marketing
> * Somehow try to make sure that tools like liveusb-creator include
> I'm not sure I can imagine a spin maintainer who would be *happy*
> all this.
Your other reply said there is no burden for spins.
I said there was no extra *QA* burden. I did tentatively float an idea
that it wasn't a major burden for releng either, but I believe I
indicated I could hardly gainsay the releng folks on that.
Yet you list a bunch of things you classify as a whole lot of
work. Including QA.
Note the parenthesis:
"(we have provided a QA process for spins; this cost us - well, me,
personally - a few hours I was happy to spend several releases ago, and
it's in place and it works)"
We don't require ourselves to do any testing of spins, hence there is no
ongoing burden. Setting up the 'infrastructure' for spins QA was
trivial, because as long as spins are integrated with the main release
process, all we have to do is add a couple of extra tables to a wiki
Each time a TC or RC comes out, we create a new instance of that
template. We'd do that whether we have non-blocking spins or not,
because it's the same page used to test the blocking spins. So since the
whole process is integrated, we get a decent QA process for desktop
spins at basically no cost.
Non-desktop spins could have their own template pages, which adds a huge
extra five seconds or so of work for us at each TC/RC point.
I sometimes *choose* to do spin testing, because I happen to think it is
a good and valuable thing to send out working Xfce, MATE, LXDE etc. But
it's entirely optional.
Using lack of burden as a reason to keep it and extra burden as an
excuse not to have spin maintainers do the spins outside of Fedora
doesn't wash either.
When you put it *that* way...:)
So, let me pull the points together: so far as QA goes, having spins
does not impose extra required work on us. QA team members can choose to
help with spin testing if they think it's useful work, but nothing
requires the QA team to do any testing of non-blocking spins.
I will let releng speak for themselves on the question of what mandatory
ongoing work spins impose on them.
My other point is that by just being one part of a whole integrated
process, spins get a lot of useful things done for them in a fairly
efficient way, which if they were separated out from the main Fedora
process would not happen. This applies to the QA *infrastructure*; as I
indicated, providing the space for spins QA to occur is essentially free
for us, but if spins were no longer part of the main Fedora validation
process, that wouldn't be the case any more - spins would have to come
up with their own infrastructure, which would be rather more work. QA
wouldn't have to do that work, so from a selfish point of view I
shouldn't care, but *someone* would have to do it. It's inefficient.
The same also applies to the releng processes. As we have to build live
images anyway, we have a fairly good process for doing live builds
efficiently in place, and the spins are just 'more of the same'. Releng
folks seem to indicate that just having 'more of the same' can be a
problem for them in terms of resource availability, and that sucks - but
at least they don't have to keep re-inventing the processes. If we split
spins off, each spin is going to have to reinvent that process.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net