[CentOS-devel] Reality V/s Fantasy
mail-lists at karan.org
Fri Nov 26 14:00:57 EST 2010
This is constructive.. we should have had these conversations about 2
weeks back :/
On 11/26/2010 06:49 PM, Douglas McClendon wrote:
> A lack of a progress-bar. Or number. Or list in a wiki. If I thought
> I could 'go do something', and that work would translate in some
> progress-meter jumping from 2345/5000 to 2346/5000, I think I'd be much
> more likely to do it.
Fabian raised this issue in a different venue, am going to get some
content into the wiki - the details are there, its just not that easy to
get into ( eg: components in the CentOS-6 project on bugs.c.o map
directly to src.rpms ). I'll try and make the lists more visible.
> Another variant of that which would make the sense of contribution and
> accomplishment be more visceral, might be a publicly visible repository
> of just .el6.srpm's filling up, that theoretically I could build in the
> process that has been documented on this list, but not so much AFAICS on
> a centos6 wiki page (see Stefan's comments below about the still very
> thin centos6 documentation via wiki).
Therein lies the tricky bit. Were not going to publish anything, in
source or binary till we know the package contents are either
whitelisted or checked and patched. For this stage, and where we are -
its going to need to be people working against the sources at ftp.r.c -
however, the package lists going into the wiki should help a bit. It
would give you a clear idea of what's where, and what needs doing.
Remember each report that is filed, still needs someone else to verify
it - most of that would come from the QA team, but if anyone/everyone
wants to pitch in with reviews, no one is going to stop you. On the
other hand it would be much appreciated even.
> Another element (and I could have missed something - if so the issue is
> then prominence or obviousness -), is a lack of tangible examples for
> the format that such work would be required to be in. Yes, I can see
Bog standard patches for RPMS. In case of artwork replacement, just file
the request - no work needed. For content replacement, patches welcome.
> Now sure, I could just accept as my motivation, reward, and process
> letting some guru flag-holder, hold my hand, tell me what to do, and
> then pat me on the back. But that level of reward, especially with the
> STFU attitude I'm seeing from the flag-holder, does not induce me to
The hand holding, tutorial type format isnt easy to work on given the
extremely limited resources on hand: so the barrier to entry does get
limited to some extent; people who know rpm's and people who already are
familiar with CentOS as an idea. However, this does directly help in
solving the issue of resources. If we can get people in at this early
stage - we also retain the ability to rapidly change process without
impacting released / realising / tested code. It also helps create that
resource pool who could help then funnel down into these specific tasks,
like tutoring and review level formats.
> I.e, I've wondered, and even looked but can't find, exactly what the
> format of the work is. I.e. a standard patch to specfile and file-level
> diff of SOURCES I would presume?
ok, thats just you being lazy :) we've published sources for
centos-2.1/2/3/4 for a while now ! But yes, content payloads -> patches
with spec file mod's into bugs.c.o + For artwork, notes in the bugs.c.o
> I hope that explanation of why I personally haven't helped more is of
> help. And I admit it may still all be some rationalization where KS's
> vision of reality is still valid, and I may not have really done any
> work even if all those concerns were taken care of. Dunno...
I think its helpful, there is tangible feedback. None of which, imho,
More information about the CentOS-devel