FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS Development

 
 
LinkBack Thread Tools
 
Old 11-26-2010, 10:41 AM
Karanbir Singh
 
Default Reality V/s Fantasy

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.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-26-2010, 05:21 PM
Stefan Held
 
Default Reality V/s Fantasy

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.

--

Stefan Held VI has only 2 Modes:
obi unixkiste org The first one is for beeping all the time,
the second destroys the text.

---------------------------------------------------------------------------
perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/'
---------------------------------------------------------------------------

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-26-2010, 05:28 PM
Karanbir Singh
 
Default Reality V/s Fantasy

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-26-2010, 05:49 PM
Douglas McClendon
 
Default Reality V/s Fantasy

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.
>

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-26-2010, 06:00 PM
Karanbir Singh
 
Default Reality V/s Fantasy

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-26-2010, 07:04 PM
Douglas McClendon
 
Default Reality V/s Fantasy

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

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-29-2010, 11:50 AM
Karanbir Singh
 
Default Reality V/s Fantasy

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 11-30-2010, 01:33 AM
Douglas McClendon
 
Default Reality V/s Fantasy

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. 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.

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

_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 01:29 AM
Karanbir Singh
 
Default Reality V/s Fantasy

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
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 
Old 12-02-2010, 02:14 AM
Stephen John Smoogen
 
Default Reality V/s Fantasy

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.
>


--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel
 

Thread Tools




All times are GMT. The time now is 08:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org