On 11/26/2010 01:00 PM, Karanbir Singh wrote:
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.
(IMHO...)
It has to be a progress-meter (or several visible on a single webpage). Also a list on a single (big) page, that I could scan through to find my next target. Also at least several paragraphs in the wiki describing the process of the work. I'll describe a bit more what I'd like to see below.
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.
I get this, or its essence. But I think the visceral accomplishment from seeing the absolute minimal round1 packages becoming visible is vital to motivating people.
I think an important distinction exists between the work the QA team does to make the packages 'centos quality', versus 'legally publishable'. In other words, I think there should be a wiki page, few paragraphs at least, outlining the requirements for what it takes to convert an upstream srpm, into one that is legally publishable. And I think the most immediate milestone should be getting round1 legally publishable packages visible. Not because they'd be usable as parts of a distro so much, as because their visibility would be motivating to contributors.
From what I understand, and my knowledge of upstream. Specifically your/someones comments about how this needn't be a flawless endeavor and that branding fixes can slip and be fixed later without being legally catastrophic (upstream has a reputation in FOSS to maintain, and don't seem remotely inclined to go scorched-earth if centos is clearly making a good-faith effort).
Given that, to get a package published, I don't see that it needs to get past any significant (time consuming) involvement from limited QA. It seems to me just getting 2-3 contributors to sign off, and maybe a cursory blessing from QA or the core team, should be enough.
I.e. I'd love to see a wiki, with the full list, and in the status column, a status of
- not looked at - candiate package ready and blessed by 1 (name here) - candidate package ready and blessed by 2nd (name here) - round1 package blessed by QA/Core and round1 .el.srpm available here
Which now begs the question, how does 2nd person get to see package if it can't yet be legally published? I'd almost say that as soon as it is blessed by 1 person it should be legally publishable, as that is necessary for an open fast development process, and seems entirely within the realm of good-faith that upstream should have no problem with. But if that name1 has to be a link to a wiki-profile with someone's email and you have to email the person for that package, that seems ok as well, though still throttling the process perhaps unnecessarily.
Likewise, I think then those first publically available round1 srpms should go through the build system and be publically available in binary form ASAP. Again, if for no utility reason other than the visceral satisfaction and motivation they give the initial brand-strippers and blessers.
Also, I think the bar should be set very, very, very low for the brand-stripping on round1 packages. It should be ok to very sloppily replace strings and images with simple blank images. The emphasis being on get the round1 package out, and let the much slower QA process for true quality happen after a round1 package is out.
(remember, the IMHO at top applies to all of this)
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 am lazy, and maybe it applies here, but...
What isn't clear to me is how your deltas from upstream are maintained. Do you have a system that where the delta is encoded somehow, such that when updates come from upstream, the reapplying of the delta, if no new delta is needed, is automated?
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.
Thanks, and you seem reasonable here as well. Maybe I don't know some history on the other thread, but if so, you should realize that other new comers to the community don't know the history, and will perhaps come to the same conclusions I did. Centos is valuable, I appreciate it, and you are in a position to be as much of an ass as you like and the threshold before someone forks is very very high. But seriously, the world would be much better if tried not to come off as STFU. And you did resort to personal attacks that were completely uncalled for (accusations of paranoia, blabla... theres too much of that bullshit tactic everywhere else in the world...)
-dmc
- KB
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel