Hi Florian,
On 11/26/2010 10:41 AM, Florian La Roche wrote:
you should make sure to grow the CentOS development to a bigger group and make it more stable. AKAIK this is the goal of this list and there should be plenty of work to distribute and get done.
I am not sure where that came from - there is some level of fantasy that some of you guys seem to live with. Lets take for example the request for help with branding and trademark searches in the el6 source base. Then look at the people who really did anything to help, take the usual suspects out of the loop, and then see what the number reduces to..
Consider this : the distro was ready to QA in 72 hrs from when upstream dropped all srpms into the right places. I actually requested the 'usual suspects'[1] to not get involved with the branding issues, we all have quite a bit going on and adding onto that at release time usually means slowing down or dropping other efforts; the intention was to not do that, and to bring in a larger user base who can help cover issues that don't need specific centos resources. Also, the QA effort tends to be exceptionally manic, with things changing on an hourly basis, and some of us pushing for testing, results quite aggressively.
Besides that, new release, new buildsys, new repo structure and new process meant that this would be fantastic time for a larger number of people to get involved, and stay involved. Starting from the root of what we do, and having a good understanding of context around it, why its a big deal and appreciate it in specific terms by working on it.
The original email asking for help on this was posted on the 12th Nov. Its the 26th now. Check https://bugs.centos.org/ to see what level of participation has been forthcoming.
Lots of people will argue that open source works in a way where people do what they want to do, so you cant tell them what needs doing - and they will do what they want, when they want. Its what many imagine is the 'fun' in the open source way. Fortunately, or unfortunately we dont have that luxury. What comes down the pipe needs to be addressed, sometimes its what we want to do - and sometimes its what needs doing because that's the issue on hand. The process we have in place is mostly finite, with a specified origin and a specified delivery expectation. We need to join those dots. And if people don't want to help with that joining-the-dots effort, they are never going to be a part of the process.
So when people imply that there are lots of potential-contributers who would want to get involved and help etc : What fantasy world are they looking at ? I, or one, would like to get in on that action please.
No fights please, CentOS has such a wonderful source base to extend upon...
If we cant get traction to get on with just doing what our primary aim is, extending the code base looks to be a bit of another fantasy world.
Slightly frustrating ? Absolutely.
- KB
[1]: The usual suspects being the people already doing quite a bit, the core/dev team, the qa guys, artwork effort. And I am truly grateful for their support.
Am Freitag, den 26.11.2010, 11:41 +0000 schrieb Karanbir Singh:
I am not sure where that came from - there is some level of fantasy that some of you guys seem to live with. Lets take for example the request for help with branding and trademark searches in the el6 source base.
Karanbir, as this is a fairly new Process, not documented anywhere, how would you expect the masses to help you out?
the intention was to not do that, and to bring in a larger user base who can help cover issues that don't need specific centos resources. Also, the QA effort tends to be exceptionally manic, with things changing on an hourly basis, and some of us pushing for testing, results quite aggressively.
Even if i look at the site you sugested to us, clearly, it states:
<snip>
webapp for people to suggest patches and branding changes : http://url ( coming soon : this will visible and usable by anyone, not just the QaTeam )
</snip>
So this webapp is now bugs.centos.org? Fine, then please state it there. Else maybe some of us where waiting for that webapp to come to glory.
The original email asking for help on this was posted on the 12th Nov. Its the 26th now. Check https://bugs.centos.org/ to see what level of participation has been forthcoming.
See above.
And if people don't want to help with that joining-the-dots effort, they are never going to be a part of the process.
Maybe the people are willing to help but do not know how?
How they get the RHEL Beta, where to look in the rpms? What must be reported?
Slightly frustrating ? Absolutely.
Indeed.
Hi,
On 11/26/2010 06:21 PM, Stefan Held wrote:
Karanbir, as this is a fairly new Process, not documented anywhere, how would you expect the masses to help you out?
If there are questions, ask them. If there is something not clear, ask about them. Dont wait for everyone else to just give up before coming up with the questions.
So this webapp is now bugs.centos.org? Fine, then please state it there. Else maybe some of us where waiting for that webapp to come to glory.
That was mentioned in the original email of the 12th, everyone was pointed at that email.
Maybe the people are willing to help but do not know how?
whatever is not clear, bring it up and will be addressed.
How they get the RHEL Beta, where to look in the rpms?
first hit on google for 'rhel 6 beta' - click the BIG red button that says DOWNLOAD. If you dont know even this level of stuff, I honestly feel you need to spend a bit more time with the platform and get to know about it before you can be productive in this process.
What must be reported?
Read the content mentioned, it clearly states what to look for - and what to do with it. w.r.t the interface, yes - use bugs.c.o; there are even a bunch of issues reported there now.
- KB
On 11/26/2010 12:21 PM, Stefan Held wrote:
Am Freitag, den 26.11.2010, 11:41 +0000 schrieb Karanbir Singh:
I am not sure where that came from - there is some level of fantasy that some of you guys seem to live with. Lets take for example the request for help with branding and trademark searches in the el6 source base.
Karanbir, as this is a fairly new Process, not documented anywhere, how would you expect the masses to help you out?
+1, and to the rest of Stefan's reply.
Specifically, as an observer who has the interest, skillset, and time to help, I considered this thread and the best answer I can come up with for why I haven't been more motivated to try and help is-
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.
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).
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 the filing of bugs, but filing of bugs doesn't give the sense of satisfaction of the 2345->2346/5000 tick, or a new file appearing in a directory, the end of the road of that population or progress-meter being a new milestone of completeness of centos6.
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.
Give us a progressbar, and publically visible examples, and maybe (seriously, maybe, I could be wrong), you might see more community contribution.
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?
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...
-dmc
the intention was to not do that, and to bring in a larger user base who can help cover issues that don't need specific centos resources. Also, the QA effort tends to be exceptionally manic, with things changing on an hourly basis, and some of us pushing for testing, results quite aggressively.
Even if i look at the site you sugested to us, clearly, it states:
<snip>
webapp for people to suggest patches and branding changes : http://url ( coming soon : this will visible and usable by anyone, not just the QaTeam )
</snip>
So this webapp is now bugs.centos.org? Fine, then please state it there. Else maybe some of us where waiting for that webapp to come to glory.
The original email asking for help on this was posted on the 12th Nov. Its the 26th now. Check https://bugs.centos.org/ to see what level of participation has been forthcoming.
See above.
And if people don't want to help with that joining-the-dots effort, they are never going to be a part of the process.
Maybe the people are willing to help but do not know how?
How they get the RHEL Beta, where to look in the rpms? What must be reported?
Slightly frustrating ? Absolutely.
Indeed.
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
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
On 11/26/2010 08:04 PM, Douglas McClendon wrote:
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.
Round1 packages are never public visible. They wont be this time either.
I think an important distinction exists between the work the QA team does to make the packages 'centos quality', versus 'legally publishable'.
humm. no.To be fair you did say you were new to CentOS :)
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
what bits are missing from the page already there ?
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).
this is about as far away from the truth as can be, so do tell me where you saw this or who's comments made you think that it was ok for us to release some stuff, in whatever state, and take remedy later - specially when it comes to legal and trademark stuff. if you believe that, you are about as far away from CentOS as can be.
- 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
you don't need whitelisted srpms published by centos, you can get them directly at ftp.r.c; for the rest, http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put together yesterday, I will try and get it finished up in a few hours time.
Which now begs the question, how does 2nd person get to see package if it can't yet be legally published?
You lost me there, whats wrong with the ftp.r.c site ? remember its the 'source' that needs auditing, not the binary. Usually we would have had a centos-6/beta in the public but in this case upstream put a beta out directly.
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.
No, that's a serious waste of time and effort. the first set of binaries are released to the qa team, and qateam only - once they have cleared it out we move to pretty much release.
Most people would rather see release in 10 days, rather than a beta for 2 weeks, followed by release in a further 10 days. Besides this is a onetime effort. from here on all point releases are just rolling builds with no beta's etc.
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.
I completely disagree. In our context that sort of a process will just not work. If there were 100+ contributors and 24+ qa people, we can think of something like that. But for now, it needs to be people who know what they are doing and can help in a constructive manner.
What isn't clear to me is how your deltas from upstream are maintained.
in srpms. Whats so hard to understand about that ?
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.
erm, winning popularity contests is way lower on the agenda than doing the right thing.
- KB
On 11/29/2010 06:50 AM, Karanbir Singh wrote:
On 11/26/2010 08:04 PM, Douglas McClendon wrote:
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.
Round1 packages are never public visible. They wont be this time either.
I think an important distinction exists between the work the QA team does to make the packages 'centos quality', versus 'legally publishable'.
humm. no.To be fair you did say you were new to CentOS :)
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
what bits are missing from the page already there ?
Just looked at the SanityTests page, which either wasn't on the Round1 page before, or I was lazy and didn't click through to it. Looks good.
From what I understand, and my knowledge of upstream. Specificallyyour/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).
this is about as far away from the truth as can be, so do tell me where you saw this or who's comments made you think that it was ok for us to release some stuff, in whatever state, and take remedy later - specially when it comes to legal and trademark stuff. if you believe that, you are about as far away from CentOS as can be.
Ok, to quote you from 5 days ago where my impression stems from-
" And you can still file such issues against centos-5, its an ongoing effort not a open/shut situation. So we can still fix stuff in the next version "
Note my very intentional use of the phrase "good-faith". It's as legaleze as I get, but I think that is the heart of it.
- 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
you don't need whitelisted srpms published by centos, you can get them directly at ftp.r.c; for the rest, http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put together yesterday, I will try and get it finished up in a few hours time.
Looks good, though as with the method of gleaming the progress-meter number via the bug system, it is the closed section of that list that I would get excited about seeing growing day by day.
Which now begs the question, how does 2nd person get to see package if it can't yet be legally published?
You lost me there, whats wrong with the ftp.r.c site ? remember its the 'source' that needs auditing, not the binary. Usually we would have had a centos-6/beta in the public but in this case upstream put a beta out directly.
Here, as below, there is some disconnect, and it is probably me completely oblivious to some obvious piece of centos development infrastructure. Your srpm specfiles, for c5, (c6?)- are they in a source control tree somewhere? Or I'm just being stupid and lazy and for the majority of cases your srpms are literally renames of binary srpms that have no branding to strip even in the specfile because that all gets added to the binary rpm during build.
But even so, I think you weren't seeing that I was talking about going beyond auditing, and toward fixing. I.e. someones first pass at a fix needs to be visible to a second person to do a second check of it.
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.
No, that's a serious waste of time and effort. the first set of binaries are released to the qa team, and qateam only - once they have cleared it out we move to pretty much release.
I guess seems odd asking for work from contributors, and giving them less 'inside access' than the qa team. I posit that perhaps your opinion of it being wasted effort, and your opinion that there are surprisingly few people who both want to help and then actually help, are related. But I admit I'm probably just wasting your and everyone's time with this conversation, and as mentioned I do have ulterior motives for having early access to the packages that probably color my logic. Though after 2 or 3 weeks RH did finally get me my 30day trial, though I still would rather use (and therefore test) your earliest first pass build.
Most people would rather see release in 10 days, rather than a beta for 2 weeks, followed by release in a further 10 days. Besides this is a onetime effort. from here on all point releases are just rolling builds with no beta's etc.
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.
I completely disagree. In our context that sort of a process will just not work. If there were 100+ contributors and 24+ qa people, we can think of something like that. But for now, it needs to be people who know what they are doing and can help in a constructive manner.
I can accept that, it makes sense in the present context.
What isn't clear to me is how your deltas from upstream are maintained.
in srpms. Whats so hard to understand about that ?
so all you have in source control is srpms?
are many of them 100% unmodified from upstream other than renaming the file (if that)?
If these questions are answered by a wiki page, by all means point me to where I should have seen the answer if I'd done my homework.
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.
erm, winning popularity contests is way lower on the agenda than doing the right thing.
Sometimes the right thing is being less pedantic, and more agreeable and constructive. IMO. (and I say this feeling personally guilty about having in the past, and still falling on I suspect the wrong side this fence)
-dmc
On 11/30/2010 02:33 AM, Douglas McClendon wrote:
"And you can still file such issues against centos-5, its an ongoing effort not a open/shut situation. So we can still fix stuff in the next version" Note my very intentional use of the phrase "good-faith". It's as legaleze as I get, but I think that is the heart of it.
ah ok, what I meant to say was that if someone finds an issue even after release, we would try and fix that right away. Didnt mean to imply that we're lax or dont take the initial audit seriously.
http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put together yesterday, I will try and get it finished up in a few hours time.
Looks good, though as with the method of gleaming the progress-meter number via the bug system, it is the closed section of that list that I would get excited about seeing growing day by day.
There are a few more additions to the page i need to roll out, will try and do that in the morning.
source control tree somewhere? Or I'm just being stupid and lazy and for the majority of cases your srpms are literally renames of binary srpms that have no branding to strip even in the specfile because that all gets added to the binary rpm during build.
not at all sure what you mean by 'srpms are literally renames of binary srpms'. I did read it a few times :)
Think about this :
Patches for branding issues need to be done at the srpm payload level, and not as a patch in the .spec
But even so, I think you weren't seeing that I was talking about going beyond auditing, and toward fixing. I.e. someones first pass at a fix needs to be visible to a second person to do a second check of it.
but isnt all that public in the bugs.c.o interface ? We just havent had too many patches :)
I guess seems odd asking for work from contributors, and giving them less 'inside access' than the qa team. I posit that perhaps your
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds. Also the QA team are small, perhaps 10 people in all. Which means we find the main issues quickly and can work on very basic communication means.
so all you have in source control is srpms?
pretty much
are many of them 100% unmodified from upstream other than renaming the file (if that)?
renaming what file ?
- KB
On 12/01/2010 08:29 PM, Karanbir Singh wrote:
On 11/30/2010 02:33 AM, Douglas McClendon wrote:
"And you can still file such issues against centos-5, its an ongoing effort not a open/shut situation. So we can still fix stuff in the next version" Note my very intentional use of the phrase "good-faith". It's as legaleze as I get, but I think that is the heart of it.
ah ok, what I meant to say was that if someone finds an issue even after release, we would try and fix that right away. Didnt mean to imply that we're lax or dont take the initial audit seriously.
And that's what I thought you meant, and what I meant as well. Perhaps the illustration of our disagreement, is my belief that upstream legal would indeed be more forgiving of packages 'published' to the development community, as development packages, versus packages published as a product for end users. I.e. that it is not necessary for legal purposes to keep development behind closed doors _as long as a good-faith effort is made_.
http://wiki.centos.org/QaWiki/6/AuditStatus is a brief report I put together yesterday, I will try and get it finished up in a few hours time.
Looks good, though as with the method of gleaming the progress-meter number via the bug system, it is the closed section of that list that I would get excited about seeing growing day by day.
There are a few more additions to the page i need to roll out, will try and do that in the morning.
Ok. What I couldn't understand before (and now), is whether or not a package being on the closed list (which is currently still at 0/XXXX) can be inferred from a state in the bug system. I.e. was a single bug created by default for every package?
source control tree somewhere? Or I'm just being stupid and lazy and for the majority of cases your srpms are literally renames of binary srpms that have no branding to strip even in the specfile because that all gets added to the binary rpm during build.
not at all sure what you mean by 'srpms are literally renames of binary srpms'. I did read it a few times :)
Think about this :
Patches for branding issues need to be done at the srpm payload level, and not as a patch in the .spec
Yeah I could have been clearer. I understand this. My question would be- Suppose package xyz requires 3 text changes to the specfile, 2 images removed from the srpm payload, 2 images added to the srpm payload, and 1 extra patch to source with accompanying specfile application. That set of things is the delta from upstream. Is that set of things stored in source control? Or is the only place it is stored in the srpm that you publish in your repository?
As a person with an esoteric interest in forking of distros, I've often considered such systems. I.e. I imagine it might be useful to encode the above in a kind of .dsrpm, i.e. 'delta srpm', which could be applied to an srpm, and then in the best case, when an upstream update comes to that srpm, can be trivially reapplied via some utility, as opposed to a person doing a manual rpm -i .srpm, commands on commandline, rpmbuild -bs ...
But even so, I think you weren't seeing that I was talking about going beyond auditing, and toward fixing. I.e. someones first pass at a fix needs to be visible to a second person to do a second check of it.
but isnt all that public in the bugs.c.o interface ? We just havent had too many patches :)
Where/how would one submit a candidate package? And continuing what I said above, it seems it would be better to submit some kind of standardized delta instead of a package. Realize I do know how noob those questions sound. And how passive-agressive that sounds. I guess what is missing is the wiki walkthrough description of how brandstripping one example package goes. And you've mentioned I think why you don't want to invest time in such a tutorial, though I suspect you've wasted more time discussing it with me already :)
I guess seems odd asking for work from contributors, and giving them less 'inside access' than the qa team. I posit that perhaps your
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds.
Right there you draw a conclusion in the second sentence from the first. But I don't follow the reasoning. I would even reach the opposite conclusion, but I do defer to your authority and experience.
Also
the QA team are small, perhaps 10 people in all. Which means we find the main issues quickly and can work on very basic communication means.
so all you have in source control is srpms?
pretty much
are many of them 100% unmodified from upstream other than renaming the file (if that)?
renaming what file ?
Again, a noob question.
(from rhel5server) anaconda-11.1.2.209-1.src.rpm to (centos5) anaconda-11.1.2.209-1.el5.centos.src.rpm
i.e. in what percent of these instances, do these two files not contain identical bits? My first presumption would have been 0%, but then I started thinking maybe it was 90%. (obviously anaconda would have brand to strip, or at least I strongly presume so)
-dmc
On Wed, 2010-12-01 at 22:02 -0600, Douglas McClendon wrote:
Where/how would one submit a candidate package? And continuing what I said above, it seems it would be better to submit some kind of standardized delta instead of a package. Realize I do know how noob those questions sound. And how passive-agressive that sounds. I guess what is missing is the wiki walkthrough description of how brandstripping one example package goes. And you've mentioned I think why you don't want to invest time in such a tutorial, though I suspect you've wasted more time discussing it with me already :)
You would file a bug report against that package here [1] under the CentOS 6 Section. You really do not need to upload the source rpm. All you need to do is file the report with what needs changing and where at or along with the needed patch. If the patch needs to be done in specific order say so. Maybe the spec file when also providing patches.
There are some sources I have looked at that really only Karanbir would know what is need because they deal with internal centos infrastructure.
John
help me Zimbra install On CentOS DNS ALSO
On Thu, Dec 2, 2010 at 10:27 AM, JohnS jses27@gmail.com wrote:
On Wed, 2010-12-01 at 22:02 -0600, Douglas McClendon wrote:
Where/how would one submit a candidate package? And continuing what I said above, it seems it would be better to submit some kind of standardized delta instead of a package. Realize I do know how noob those questions sound. And how passive-agressive that sounds. I guess what is missing is the wiki walkthrough description of how brandstripping one example package goes. And you've mentioned I think why you don't want to invest time in such a tutorial, though I suspect you've wasted more time discussing it with me already :)
You would file a bug report against that package here [1] under the CentOS 6 Section. You really do not need to upload the source rpm. All you need to do is file the report with what needs changing and where at or along with the needed patch. If the patch needs to be done in specific order say so. Maybe the spec file when also providing patches.
There are some sources I have looked at that really only Karanbir would know what is need because they deal with internal centos infrastructure.
John
[1] http://bugs.centos.org/my_view_page.php
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hello KB,
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds. Also
Red Hat distributes the source without restrictions and e.g. kernel.org is mirroring it out on all its mirror systems, so there is no requirement to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
I agree that binaries should maybe be kept until the branding and major patching items are resolved, but clearly all this is a chicken-egg situation on how to grow the participation for CentOS, right?
regards,
Florian La Roche
Am 02.12.10 10:31, schrieb Florian La Roche:
Hello KB,
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds. Also
Red Hat distributes the source without restrictions and e.g. kernel.org is mirroring it out on all its mirror systems, so there is no requirement to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
Hmmm. They are redistributing RH code. We try to do that as a different project. So yes, you might be right, but I'd really like to not step onto someone's toes inadvertently :)
Regards,
Ralph
Am 02.12.2010 22:54, schrieb Ralph Angenendt:
Am 02.12.10 10:31, schrieb Florian La Roche:
Hello KB,
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds. Also
Red Hat distributes the source without restrictions and e.g. kernel.org is mirroring it out on all its mirror systems, so there is no requirement to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
Hmmm. They are redistributing RH code. We try to do that as a different project. So yes, you might be right, but I'd really like to not step onto someone's toes inadvertently :)
We don't need to redistribute the original files. We could make up a way to have "patches" for SRPMs. What you do when changing an SRPM is usually the following: 0. download the SRPM 1. extract the SRPM 2. change the SPEC 3. change/add/remove patches and other Sources 4. extract the included tarballs if they need to be changed 5. apply changes to the tarball content 6. repackage the tarballs 7. repackage the SRPM
Afaict this is all scriptable. 0. wget http://whatever.url/the/file/is/located/at.src.rpm 1. rpm -i whatever.src.rpm 2. cd SPEC && patch < spec-changes.patch; cd .. 3. cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd .. 4. gzip -cd whatever-1.2.3.tgz | tar xCf /tmp - 5. cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar 6. cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz 7. rpmbuild --nodeps -bs whatever.spec
I'll admit that it isn't that simple, but we could have a system to keep "SRPM patches" around and as these won't contain RH trademarked stuff it won't hurt. The to-be-patched SRPMs can be fetched by anyone from the original source which is also ok. As you might have noticed I'm suggesting to unpack tarballs into existing directories. This is to overwrite and replace existing and "offending" RH stuff. Files that should be removed can simply be overwritten with 0-byte files (I guess nobody can sue us for a filename in a tarball)
If something like this is appreciated I could write example-scripts to do the work.
btw. please CC responses to me (I don't want to take this off-list, I'm just not reading regularly enough to catch responses in time otherwise).
Regards, Andreas
On Dec 3, 2010, at 10:24 AM, Andreas Rogge wrote:
Hi Andreas!
Am 02.12.2010 22:54, schrieb Ralph Angenendt:
Am 02.12.10 10:31, schrieb Florian La Roche:
Hello KB,
One of the main things that the QA team needs to work with is whitelisting for release, the branding stuff. That intself means the qa team needs to stay small, non public access to early code builds. Also
Red Hat distributes the source without restrictions and e.g. kernel.org is mirroring it out on all its mirror systems, so there is no requirement to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
Hmmm. They are redistributing RH code. We try to do that as a different project. So yes, you might be right, but I'd really like to not step onto someone's toes inadvertently :)
We don't need to redistribute the original files. We could make up a way to have "patches" for SRPMs. What you do when changing an SRPM is usually the following: 0. download the SRPM
- extract the SRPM
- change the SPEC
- change/add/remove patches and other Sources
- extract the included tarballs if they need to be changed
- apply changes to the tarball content
- repackage the tarballs
- repackage the SRPM
While one can easily imagine the necessary procedure to "patch" build recipes, its actually a quite painful process to maintain in the "real world".
(aside) Applying meta-patches has been attempted with WindRiver Linux, rather a disaster (imho, there are other benefits to WRL, just not the meta-patching of build recipes). All JMHO, YMMV.
Afaict this is all scriptable. 0. wget http://whatever.url/the/file/is/located/at.src.rpm
- rpm -i whatever.src.rpm
- cd SPEC && patch < spec-changes.patch; cd ..
- cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd ..
- gzip -cd whatever-1.2.3.tgz | tar xCf /tmp -
- cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar
- cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz
- rpmbuild --nodeps -bs whatever.spec
Its not the scriptable, but rather the process framework to apply the meta-patch to the build recipe that is the torquemada.
I'll admit that it isn't that simple, but we could have a system to keep "SRPM patches" around and as these won't contain RH trademarked stuff it won't hurt. The to-be-patched SRPMs can be fetched by anyone from the original source which is also ok. As you might have noticed I'm suggesting to unpack tarballs into existing directories. This is to overwrite and replace existing and "offending" RH stuff. Files that should be removed can simply be overwritten with 0-byte files (I guess nobody can sue us for a filename in a tarball)
There are hints here to what tends to called "exploded SRPM's" in my vocabulary, basically don't bother with all the rituals of Sources + Patches + Recipe == Reproducible builds from last century still in use with RPM, but just build straight from a VCS like git/svn.
One immediate benefit with "exploded SRPM's" is that you can start to use grep to find what needs changing, and a VCS to track patches (rather than re-stacking patchsets and other tedious chores when something changes).
All of "exploded SRPM's" is quite doable and KISSier. But you likely are stuck with whatever @redhat chooses to do. Oh well ...
If something like this is appreciated I could write example-scripts to do the work.
You might want to look at WRL: they essentially have a *BSD ish "make world" framework on top of traditional rpmbuild invocations. The design (because it refactors per-package goop into a per-buildsys framework) is perfectly sane even if the reults (imho) are rather awkward for "package monkeys".
btw. please CC responses to me (I don't want to take this off-list, I'm just not reading regularly enough to catch responses in time otherwise).
CC done
hth
73 de Jeff
Regards, Andreas
-- Solvention Ltd. & Co. KG Egermannstr. 6-8 53359 Rheinbach
Tel: +49 2226 158179-0 Fax: +49 2226 158179-9
http://www.solvention.de mailto:info@solvention.de _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Hello Karanbir,
On Thu, 2010-12-02 at 02:29 +0000, Karanbir Singh wrote:
Patches for branding issues need to be done at the srpm payload level, and not as a patch in the .spec
Is that really necessary? The original SRPMs with the "offending" payload are freely available and if I'm not mistaken redistributable under the GPL (IANAL). If you'd just patch the spec file to replace that content that would fix the RPMs that will be build from it. What legal requirement is there to strip those SRPMs?
Regards, Leonard.
Hello Karanbir,
On Thu, 2010-12-02 at 02:29 +0000, Karanbir Singh wrote:
Patches for branding issues need to be done at the srpm payload level, and not as a patch in the .spec
Is that really necessary? The original SRPMs with the "offending" payload are freely available and if I'm not mistaken redistributable under the GPL (IANAL). If you'd just patch the spec file to replace that content that would fix the RPMs that will be build from it. What legal requirement is there to strip those SRPMs?
I'm not privy to anything, but I imagine a lot of the images are registered trademarks. GPL doesn't (nor shouldn't) cover these.
See the whole Firefox v. Debian debate a few years back. RedHat would, I think, be pretty lenient on CentOS TM violations, but only if Karanbir et al were vigilant about stripping trademarked stuff out.
Matt
Regards, Leonard.
-- mount -t life -o ro /dev/dna /genetic/research
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Nov 29, 2010 at 19:33, Douglas McClendon dmc.centos@filteredperception.org wrote:
so all you have in source control is srpms?
are many of them 100% unmodified from upstream other than renaming the file (if that)?
Files are generally not renamed. What needs to be done is
a) Look through compiled items for trademarks in images and documents. b) Look in source code to see where those images may be called or implanted. c) all corner cases not covered by a or b
For a) it requires a source code change as a patch in the source RPM as the trademark would still be distributed for b) it requires a patch to say from
a href="redhat.png" -> a href="centos.png"
c) usually comes up as requiring a request to Karanbir of whether this covers a problem or not.
To get an idea of what is changed in a release look at all the .src.rpms in say CentOS-5 with .centos.src.rpm in them.
If these questions are answered by a wiki page, by all means point me to where I should have seen the answer if I'd done my homework.
On 12/01/2010 09:14 PM, Stephen John Smoogen wrote:
On Mon, Nov 29, 2010 at 19:33, Douglas McClendon dmc.centos@filteredperception.org wrote:
so all you have in source control is srpms?
are many of them 100% unmodified from upstream other than renaming the file (if that)?
Files are generally not renamed. What needs to be done is
a) Look through compiled items for trademarks in images and documents. b) Look in source code to see where those images may be called or implanted. c) all corner cases not covered by a or b
For a) it requires a source code change as a patch in the source RPM as the trademark would still be distributed for b) it requires a patch to say from
a href="redhat.png" -> a href="centos.png"
c) usually comes up as requiring a request to Karanbir of whether this covers a problem or not.
To get an idea of what is changed in a release look at all the .src.rpms in say CentOS-5 with .centos.src.rpm in them.
ahh. I didn't see your message when crafting my response. Just now I looked back at the c5 srpm list and noticed that the example I chose was actually surrounded by examples absent the .centos suffix.
That clears things up a lot I think. So the ones without the .centos suffix are entirely unchanged from upstream. Got it.
-dmc
-
Andreas Rogge -
Douglas McClendon -
Florian La Roche -
Jeff Johnson -
JohnS -
Karanbir Singh -
Leonard den Ottolander -
Matt Rose -
raj kannan -
Ralph Angenendt -
Stefan Held -
Stephen John Smoogen