Hi, 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 > contribute. 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 are enough > 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, are unreasonable. - KB