Re: [Mageia-dev] Mirror layout, round two

[andre999]

Luca Berra a écrit :


On Sun, Dec 05, 2010 at 09:46:21PM +0100, Wolfgang Bornath wrote:

Thinking of PLF, "MLF" comes to mind but that abbreviation has another
well-known meaning. :) "pisc" (patented in some countries) is another

what i particulary like about the plf name is the "liberation" word,
which has a clear positive meaning.
every other suggestions in this thread has a negative connotation
'tainted', 'swamp', etc.

Wording should not convey the meaning that it is illegal, thus _wrong_
to use this kind of software.

Wording should convey the meaning that using this kind of software is a
way to express personal freedom without really committing any _wrong_.

I would really hate if a free software distribution fell in the trap of
supporting the idea that software patents are _right_.

L.


I agree.
Although (as explained in another post), I think that we should avoid 
considering separating any particular patent-constrained package until 
we are approached by the patent holder.
Simply because since we are non-profit, all attempting to collect 
royalties from us will do is cause us to not use their patent technology 
- and push us to use some alternative - which could tend to lead to 
others using the same alternative - and thus lead to less usage by those 
who do pay royalties.


For packages we do classify as constrained, we should probably use PLF.
It is part of their policy to host packages for any distro, as long as 
contributors are willing to package them.

And as you say, their name doesn't have negative connotations.

(If we do end up with a constrained set of repos on Mageia, what about 
the name "Liberation" ? )


- André

Re: [Mageia-dev] Mirror layout, round two

[Luca Berra]

On Sun, Dec 05, 2010 at 09:46:21PM +0100, Wolfgang Bornath wrote:

Thinking of PLF, "MLF" comes to mind but that abbreviation has another
well-known meaning. :) "pisc" (patented in some countries) is another

what i particulary like about the plf name is the "liberation" word,
which has a clear positive meaning.
every other suggestions in this thread has a negative connotation
'tainted', 'swamp', etc.

Wording should not convey the meaning that it is illegal, thus _wrong_
to use this kind of software.

Wording should convey the meaning that using this kind of software is a
way to express personal freedom without really committing any _wrong_.

I would really hate if a free software distribution fell in the trap of
supporting the idea that software patents are _right_.

L.


--
Luca Berra -- bl...@vodka.it

Re: [Mageia-dev] Mirror layout, round two

[Marek Laane]

2010/12/8 Mika Laitio 

> > > > 'Grayzone' ?
> > >
> > > Mr. Dorian Gray's zone? Or a foggy grey zone?
> > > (SCNR!)
> > >
> > > Hmm, "foggy" sounds nice :)
> > > Or Foggy Bottom :)
> > >
> > Better than "tainted" :D
>
> I like from tainted as that term is already somehow known,
>
> Another alternative that came to my mind would be "challenge" as patents
> could be challenged...
>
> Or maybe "soap" or "slippery" to explain the uncertainty of
> possible patents included packages.
>
> Mika
>

If we have "cauldron" associated with sorcerers and like why not "swamp" as
somehow treacherous feature of landscape where you can never be quite sure?

Re: [Mageia-dev] Mirror layout, round two

[Mika Laitio]

> > > 'Grayzone' ?
> > 
> > Mr. Dorian Gray's zone? Or a foggy grey zone?
> > (SCNR!)
> > 
> > Hmm, "foggy" sounds nice :)
> > Or Foggy Bottom :)
> > 
> Better than "tainted" :D

I like from tainted as that term is already somehow known, 

Another alternative that came to my mind would be "challenge" as patents 
could be challenged...

Or maybe "soap" or "slippery" to explain the uncertainty of 
possible patents included packages.

Mika

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Mon, Dec 6, 2010 at 7:04 PM, Michael Scherer  wrote:
> Le mardi 07 décembre 2010 à 00:10 +0100, Maarten Vanraes a écrit :
>
>> I find it strange that the most heavy threads here are naming issues...
>
> http://bikeshed.com/ ?
>
> --
> Michael Scherer
>
>

" ... a metaphor indicating that you need not argue about every little
feature just because you know enough to do so."

... a metaphor indicating that you argue about every little feature
just because you don't  know enough not to do so.

FIXED

8)
-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le mardi 07 décembre 2010 à 00:10 +0100, Maarten Vanraes a écrit :

> I find it strange that the most heavy threads here are naming issues...

http://bikeshed.com/ ?

-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op dinsdag 07 december 2010 00:15:54 schreef Hoyt Duff:
> On Mon, Dec 6, 2010 at 6:10 PM, Maarten Vanraes
> 
>  wrote:
> > I find it strange that the most heavy threads here are naming issues...
> 
> All the arguments of substance have been settled?

You're a funny guy...

but don't quit your dayjob yet.

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Mon, Dec 6, 2010 at 6:10 PM, Maarten Vanraes
 wrote:

>
> I find it strange that the most heavy threads here are naming issues...
>

All the arguments of substance have been settled?


-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op dinsdag 07 december 2010 00:06:06 schreef Anssi Hannula:
> On 07.12.2010 00:30, Nex6 wrote:
> > On 12/6/2010 2:13 PM, Maarten Vanraes wrote:
> >> Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff:
> >>> On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes
> >>> 
> >>>   wrote:
>  no negative meaning???
>  
>  Paris Hilton anyone???
>  
>  afaik any word has negative meaning...
> >>> 
> >>> Snooki makes her look like a nun.
> >>> 
> >>> http://en.wikipedia.org/wiki/Nicole_Polizzi
> >> 
> >> seriously? with PH flashing not wearing underwear, flashing her privates
> >> publicly, doing porn?
> > 
> > I personally would not be against using a naming convention from Debian,
> > ubuntu or fedora.
> > 
> > in that, people coming from those distros would 'know' what things mean.
> 
> They do not have any repository of this kind.

I find it strange that the most heavy threads here are naming issues...

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 07.12.2010 00:30, Nex6 wrote:
> On 12/6/2010 2:13 PM, Maarten Vanraes wrote:
>> Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff:
>>> On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes
>>>
>>>   wrote:
 no negative meaning???

 Paris Hilton anyone???

 afaik any word has negative meaning...
>>>
>>> Snooki makes her look like a nun.
>>>
>>> http://en.wikipedia.org/wiki/Nicole_Polizzi
>>
>> seriously? with PH flashing not wearing underwear, flashing her privates
>> publicly, doing porn?
> 
> I personally would not be against using a naming convention from Debian,
> ubuntu or fedora.
> 
> in that, people coming from those distros would 'know' what things mean.

They do not have any repository of this kind.

-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[Nex6]

On 12/6/2010 2:13 PM, Maarten Vanraes wrote:

Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff:

On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes

  wrote:

no negative meaning???

Paris Hilton anyone???

afaik any word has negative meaning...


Snooki makes her look like a nun.

http://en.wikipedia.org/wiki/Nicole_Polizzi


seriously? with PH flashing not wearing underwear, flashing her privates
publicly, doing porn?


I personally would not be against using a naming convention from Debian, 
ubuntu or fedora.


in that, people coming from those distros would 'know' what things mean.



-Nex6

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op maandag 06 december 2010 22:57:23 schreef Hoyt Duff:
> On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes
> 
>  wrote:
> > no negative meaning???
> > 
> > Paris Hilton anyone???
> > 
> > afaik any word has negative meaning...
> 
> Snooki makes her look like a nun.
> 
> http://en.wikipedia.org/wiki/Nicole_Polizzi

seriously? with PH flashing not wearing underwear, flashing her privates 
publicly, doing porn?

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Mon, Dec 6, 2010 at 4:33 PM, Maarten Vanraes
 wrote:

> no negative meaning???
>
> Paris Hilton anyone???
>
> afaik any word has negative meaning...
>

Snooki makes her look like a nun.

http://en.wikipedia.org/wiki/Nicole_Polizzi

-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Frank Griffin]

Maarten Vanraes wrote:
> Op maandag 06 december 2010 16:30:00 schreef Hoyt Duff:
>   
>> Again, a good argument for a name with no conflicts and no negative
>> meanings: "paris".
>> 
> no negative meaning???
>
> Paris Hilton anyone???
>   
Hoyt is obviously not a subscriber to "The Reg" :-)

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op maandag 06 december 2010 16:30:00 schreef Hoyt Duff:
> On Mon, Dec 6, 2010 at 7:43 AM, Michael Scherer  wrote:
> > And that's not the question, this is a basic usability issue, if a
> > rather important portion of the users associate a word with something,
> > this sound sane to no reuse the same word to hold a different meaning in
> > a very similar context, or it will cause confusion.
> 
> Again, a good argument for a name with no conflicts and no negative
> meanings: "paris".

no negative meaning???

Paris Hilton anyone???

afaik any word has negative meaning...

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Mon, Dec 6, 2010 at 7:43 AM, Michael Scherer  wrote:

> And that's not the question, this is a basic usability issue, if a
> rather important portion of the users associate a word with something,
> this sound sane to no reuse the same word to hold a different meaning in
> a very similar context, or it will cause confusion.
>

Again, a good argument for a name with no conflicts and no negative
meanings: "paris".

-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 06 décembre 2010 à 13:10 +0100, Daniel Kreuter a écrit :
> On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir wrote:
> 
> >
> > Because Ubuntu already has a repo called "universal"? that's a similar
> > reason to why it wasn't called "restricted", because restricted is
> > used by distros that offer a commercial repo as in "pay to use some
> > more stuff".
> >
> > --
> > Ahmad Samir
> >
> 
> Do they have a patent on the name?


Patents apply to technical invention. What could be used is trademark.

And that's not the question, this is a basic usability issue, if a
rather important portion of the users associate a word with something,
this sound sane to no reuse the same word to hold a different meaning in
a very similar context, or it will cause confusion.  

-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 06.12.2010 14:10, Daniel Kreuter wrote:
> 
> 
> On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir  > wrote:
> 
> 
> Because Ubuntu already has a repo called "universal"? that's a similar
> reason to why it wasn't called "restricted", because restricted is
> used by distros that offer a commercial repo as in "pay to use some
> more stuff".
> 
> --
> Ahmad Samir
> 
> 
> Do they have a patent on the name?

No, but it will cause confusion among users if we use the same name for
a different thing than they do.


-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

On Mon, Dec 6, 2010 at 1:04 PM, Ahmad Samir wrote:

>
> Because Ubuntu already has a repo called "universal"? that's a similar
> reason to why it wasn't called "restricted", because restricted is
> used by distros that offer a commercial repo as in "pay to use some
> more stuff".
>
> --
> Ahmad Samir
>

Do they have a patent on the name?

-- 
Mit freundlichen Grüßen

Greetings

Daniel Kreuter

Re: [Mageia-dev] Mirror layout, round two

[Ahmad Samir]

On 6 December 2010 12:37, Daniel Kreuter
 wrote:
>
>
> On Mon, Dec 6, 2010 at 10:25 AM, Ahmad Samir 
> wrote:
>>
>> On 6 December 2010 09:29, Ernest N. Wilcox Jr.  wrote:
>> > With regard to the naming of the repository dediocated to software
>> > tainted
>> > with a patent, etc., How about "non-GPL"? I think that such a name
>> > should be
>> > well understood by users of nearly any language, particularly if they
>> > are
>> > familiar with the GPL.
>> >
>> > My2cents
>> > --
>> > Ernest N. Wilcox Jr.
>> > Registered Linux User 247790
>> > ICQ 41060744
>> >
>>
>> Read the afro-mentioned thread again; most of those stuff are released
>> under a GPL/GPL-like license (faad and faac packages for example, for
>> playing back and encoding using the AAC audio codec, respectively),
>> they're free open source software, but they infringe some patents.
>>
>> --
>> Ahmad Samir
>
> Why don't we call it universe or something like that? It's a neutral meaning
> where also packages without patents and such with patents can be stored in.
>
> --
> Mit freundlichen Grüßen
>
> Greetings
>
> Daniel Kreuter
>
>
>
>

Because Ubuntu already has a repo called "universal"? that's a similar
reason to why it wasn't called "restricted", because restricted is
used by distros that offer a commercial repo as in "pay to use some
more stuff".

-- 
Ahmad Samir

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

On Mon, Dec 6, 2010 at 10:25 AM, Ahmad Samir wrote:

> On 6 December 2010 09:29, Ernest N. Wilcox Jr.  wrote:
> > With regard to the naming of the repository dediocated to software
> tainted
> > with a patent, etc., How about "non-GPL"? I think that such a name should
> be
> > well understood by users of nearly any language, particularly if they are
> > familiar with the GPL.
> >
> > My2cents
> > --
> > Ernest N. Wilcox Jr.
> > Registered Linux User 247790
> > ICQ 41060744
> >
>
> Read the afro-mentioned thread again; most of those stuff are released
> under a GPL/GPL-like license (faad and faac packages for example, for
> playing back and encoding using the AAC audio codec, respectively),
> they're free open source software, but they infringe some patents.
>
> --
> Ahmad Samir
>

Why don't we call it universe or something like that? It's a neutral meaning
where also packages without patents and such with patents can be stored in.

-- 
Mit freundlichen Grüßen

Greetings

Daniel Kreuter

Re: [Mageia-dev] Mirror layout, round two

[Ahmad Samir]

On 6 December 2010 09:29, Ernest N. Wilcox Jr.  wrote:
> With regard to the naming of the repository dediocated to software tainted
> with a patent, etc., How about "non-GPL"? I think that such a name should be
> well understood by users of nearly any language, particularly if they are
> familiar with the GPL.
>
> My2cents
> --
> Ernest N. Wilcox Jr.
> Registered Linux User 247790
> ICQ 41060744
>

Read the afro-mentioned thread again; most of those stuff are released
under a GPL/GPL-like license (faad and faac packages for example, for
playing back and encoding using the AAC audio codec, respectively),
they're free open source software, but they infringe some patents.

-- 
Ahmad Samir

Re: [Mageia-dev] Mirror layout, round two

[David W. Hodgins]

On Mon, 06 Dec 2010 00:02:21 -0500, andre999  wrote:


Maarten Vanraes a écrit :

i like speculative

That's not bad


I would prefer a very clear term, even if long, such as
possibly-patented.

Regards, Dave Hodgins

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Maarten Vanraes a écrit :


Op zaterdag 04 december 2010 21:32:51 schreef andre999:

Dale Huckeby a écrit :

On Sat, 4 Dec 2010, andre999 wrote:

John a écrit :

On Fri, 3 Dec 2010 11:28:26 +0100

Maarten Vanraes wrote:

Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
[...]


The kernel uses the word "tainted" when it detects the nvidia
proprietary module for example, (which admittedly gave me a bit of
shock the first time I saw it :)).


Heh, i had the same reaction.


 From all the proposed names, I think "tainted" is the best one, as
the

packages in there are in a "grey" zone, i.e. not totally illegal
everywhere, but illegal only in some places in the world. And in
reality the existence of a patent doesn't necessarily mean it's
enforceable in a court of law (the only way we'd know for sure is if
someone actually does try to sue)... my 0.02€ worth :)


Generally only potentially "illegal" in some countries.
"Tainted" means contaminated, polluted. A lot stronger than
potentially "illegal". (Really only actionable in a civil sense, not
criminally illegal, as well.)
A package could end up there due to an apparently credible rumour,
later discredited. (Anyone remember SCO ?)


I agree. Problematic comes closer to "potentially illegal", so I looked
up some synonyms: ambiguous, debatable, dubious,
iffy, suspect, speculative, precarious, suspicious, uncertain,
unsettled, in addition to problematic itself. Personally
I like iffy, which is both short and to the point, but I think several
of these would do. WDYT?

Dale Huckeby


A much better set of choices.
(Thanks for looking these up.  Good idea.)

Let's remember that the question for these packages is not the quality
of their functioning - but rather the advisability to use them, for
other reasons, in some countries.
So I think that it is better to avoid words that could question the
QUALITY of the packages.

Words in the list like
   ambiguous, debatable, problematic, and speculative
avoid questioning the quality ... but could be too long or too formal.
Or just not catchy enough ;)
("Iffy" might be ok - certainly catchy enough.)

Additional words I found in Roget's thesaurus, along the same lines :

Associated more with debatable :
arguable, contestable, controvertible, disputable, questionable,

Associated more with controversial :
confutable, deniable, mistakable, moot

Of these additional words, I think that "contestable", "disputable", and
"controversial" are probably closest to the SENSE of the repositories.
But maybe too formal ?

Many of these words could be good choices.
And maybe someone will come up with some more ?

my 2 cents :)

- André



i like speculative



That's not bad

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Dale Huckeby a écrit :


On Sun, 5 Dec 2010, Maarten Vanraes wrote:


the english language is pretty rich; and i suspect there are quite a
few words
that could convey the correct meaning without the word being too
difficult.

otoh, there is also the fact that "free" or "core" don't really convey
the
correct meaning at all either and could be quite dubious.

patented would be more correct, but i don't wanna call it that,
because then
mageia would be sued by patent-lawyers all over the world. don't get
me wrong,
it wouldn't be illegal, but it would just be too timeconsuming...

imho, we should have a simple not too difficult word that somehow
shows a bit
about the nature of the contents in it, while still being vague enough.


Okay, short words: iffy, chancy, dicey, knotty, clouded, foggy, hazy,
unclear, contro (for controversial),
prob (for problematic), equiv (for equivocal), irreg (for irregular). I
like iffy best. It's short, it's
informal, its meaning is clear, yet it's not too narrow.

Dale Huckeby



great idea, abreviations !
contro, irreg, and equiv are abreviations for words that don't question 
the quality.

I like contro and irreg best.
We can always give the full word in our documentation which explains the 
purpose of each repository.

That would work.

(BTW, when I think about it, iffy could be considered to refer to 
quality - but it's still way better than tainted.)


Of course, there should be lots of other abreviations to choose from, if 
collectively we don't like one of these.


- André

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Sun, Dec 5, 2010 at 4:12 PM, Maarten Vanraes
 wrote:

>>
>> Perhaps we need an unrelated word that has meaning to Mageia, but
>> infers uniqueness without being pejorative.
>>
>> I suggest calling it the "paris" repository, a place for unique and
>> useful applications that cannot be placed in any other repository for
>> whatever reason. Then perhaps any local repository of one-off packages
>> could always be labeled "paris-local" by default.
>
> after Paris Hilton? "a place for unique and useful applications that cannot be
> placed in any other repository for whatever reason"
>
> sounds like a good comparison...
>

I was associating the richness and diversity of the  "City of Lights",
but I like the way you think.


-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Sam Bailey]

On Sun, 5 Dec 2010 17:39:08 -0600 (CST), Dale Huckeby
 wrote:
> On Sun, 5 Dec 2010, Maarten Vanraes wrote:
> 
>> the english language is pretty rich; and i suspect there are quite a few 
>> words
>> that could convey the correct meaning without the word being too difficult.
>>
>> otoh, there is also the fact that "free" or "core" don't really convey the
>> correct meaning at all either and could be quite dubious.
>>
>> patented would be more correct, but i don't wanna call it that, because then
>> mageia would be sued by patent-lawyers all over the world. don't get me 
>> wrong,
>> it wouldn't be illegal, but it would just be too timeconsuming...
>>
>> imho, we should have a simple not too difficult word that somehow shows a bit
>> about the nature of the contents in it, while still being vague enough.
> 
> Okay, short words: iffy, chancy, dicey, knotty, clouded, foggy, hazy,
> unclear, contro (for controversial),
> prob (for problematic), equiv (for equivocal), irreg (for irregular).
> I like iffy best. It's short, it's
> informal, its meaning is clear, yet it's not too narrow.
> 
> Dale Huckeby

Considering the other repo names to be used, we could always call this
one "other".

-- 
Sam Bailey

Cyprix Enterprises
Web: cyprix.com.au
Em: cyp...@cyprix.com.au
Mb: 0425 796 308

Re: [Mageia-dev] Mirror layout, round two

[Dale Huckeby]

On Sun, 5 Dec 2010, Maarten Vanraes wrote:


the english language is pretty rich; and i suspect there are quite a few words
that could convey the correct meaning without the word being too difficult.

otoh, there is also the fact that "free" or "core" don't really convey the
correct meaning at all either and could be quite dubious.

patented would be more correct, but i don't wanna call it that, because then
mageia would be sued by patent-lawyers all over the world. don't get me wrong,
it wouldn't be illegal, but it would just be too timeconsuming...

imho, we should have a simple not too difficult word that somehow shows a bit
about the nature of the contents in it, while still being vague enough.


Okay, short words: iffy, chancy, dicey, knotty, clouded, foggy, hazy, unclear, 
contro (for controversial),
prob (for problematic), equiv (for equivocal), irreg (for irregular). I like 
iffy best. It's short, it's
informal, its meaning is clear, yet it's not too narrow.

Dale Huckeby

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zondag 05 december 2010 21:50:00 schreef Erin Wilkins:
> On December 5, 2010 10:59:45 Maarten Vanraes wrote:
> > Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins:
> > > Since the packages in that repository are there because they're
> > > (potentially) encumbered by patents, why not call it for what it is,
> > > "encumbered"?
> > > 
> > > --
> > > Erin
> > 
> > too difficult
> 
> To understand? If that's the case, I think you're going to be stuck with
> "tainted". And while I don't have an issue with it, this whole discussion
> started because some people find it too negative.
> 
> The purpose of the repository name is to convey what sort of packages are
> contained in it. While many of the names that have been mentioned (foggy,
> speculative, etc) are relatively easy to remember, they don't have any
> existing meanings with regard to software. If I, or pretty much any other
> user, were not following this thread, I would not understand what sort of
> packages would be in a repository with those names. And like any other name
> that I wouldn't understand, I'd have to look up the documentation.
> 
> I don't know about you, but I'd rather go with a name that conveys an
> existing meaning, but some people will need to look at the documentation
> to understand.

I understand your point. however, Mageia is international and i think a high 
group of international no-native-english-speakers will have a hard time finding 
out what this is about...

the english language is pretty rich; and i suspect there are quite a few words 
that could convey the correct meaning without the word being too difficult.

otoh, there is also the fact that "free" or "core" don't really convey the 
correct meaning at all either and could be quite dubious.

patented would be more correct, but i don't wanna call it that, because then 
mageia would be sued by patent-lawyers all over the world. don't get me wrong, 
it wouldn't be illegal, but it would just be too timeconsuming...

imho, we should have a simple not too difficult word that somehow shows a bit 
about the nature of the contents in it, while still being vague enough.

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zondag 05 december 2010 20:49:55 schreef Hoyt Duff:
> On Sun, Dec 5, 2010 at 1:59 PM, Maarten Vanraes
> 
>  wrote:
> >> Since the packages in that repository are there because they're
> >> (potentially) encumbered by patents, why not call it for what it is,
> >> "encumbered"?
> >> 
> >> --
> >> Erin
> > 
> > too difficult
> 
> I suppose that's why nobody liked "supernumerary". 8)
> 
> How about "segregated"? Oh, wait ...
> 
> The problem is that in all languages, words that mean "not part of the
> group", "not one of us" or "not like us" all have negative
> connotations for cultural reasons.
> 
> Perhaps we need an unrelated word that has meaning to Mageia, but
> infers uniqueness without being pejorative.
> 
> I suggest calling it the "paris" repository, a place for unique and
> useful applications that cannot be placed in any other repository for
> whatever reason. Then perhaps any local repository of one-off packages
> could always be labeled "paris-local" by default.

after Paris Hilton? "a place for unique and useful applications that cannot be 
placed in any other repository for whatever reason"

sounds like a good comparison...

Re: [Mageia-dev] Mirror layout, round two

[Erin Wilkins]

On December 5, 2010 10:59:45 Maarten Vanraes wrote:
> Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins:
> > Since the packages in that repository are there because they're
> > (potentially) encumbered by patents, why not call it for what it is,
> > "encumbered"?
> > 
> > --
> > Erin
> 
> too difficult

To understand? If that's the case, I think you're going to be stuck with 
"tainted". And while I don't have an issue with it, this whole discussion 
started because some people find it too negative.

The purpose of the repository name is to convey what sort of packages are 
contained in it. While many of the names that have been mentioned (foggy, 
speculative, etc) are relatively easy to remember, they don't have any 
existing meanings with regard to software. If I, or pretty much any other 
user, were not following this thread, I would not understand what sort of 
packages would be in a repository with those names. And like any other name 
that I wouldn't understand, I'd have to look up the documentation.

I don't know about you, but I'd rather go with a name that conveys an existing 
meaning, but some people will need to look at the documentation to understand.

--
Erin

Re: [Mageia-dev] Mirror layout, round two

[Wolfgang Bornath]

Giving names we have to keep the structure in mind which was
"developped" during this thread.

Now we are talking about a name for that repo which never existed in
Mandriva, so Mandriva never had to worry about the correct naming. How
about abbreviations?

Thinking of PLF, "MLF" comes to mind but that abbreviation has another
well-known meaning. :) "pisc" (patented in some countries) is another
no-go because of various resons in different languages.

But here's one which could work: "tbp" (tainted by patents).

-- 
wobo

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 05.12.2010 21:47, Daniel Kreuter wrote:
> 
> 
> On Sun, Dec 5, 2010 at 8:39 PM, Anssi Hannula  > wrote:
> 
> On 05.12.2010 19:36, Daniel Kreuter wrote:
> >
> >
> > On Sat, Dec 4, 2010 at 9:32 PM, andre999  
> > >> wrote:
> >
> > Dale Huckeby a écrit :
> >
> > On Sat, 4 Dec 2010, andre999 wrote:
> >
> > John a écrit :
> >
> >
> > On Fri, 3 Dec 2010 11:28:26 +0100
> > Maarten Vanraes wrote:
> >
> > Op vrijdag 03 december 2010 10:45:05 schreef Ahmad
> > Samir:
> > [...]
> >
> > The kernel uses the word "tainted" when it
> > detects the nvidia
> > proprietary module for example, (which
> > admittedly gave me a bit of
> > shock the first time I saw it :)).
> >
> >
> > Heh, i had the same reaction.
> >
> > >From all the proposed names, I think
> "tainted"
> > is the best one, as the
> >
> > packages in there are in a "grey" zone,
> i.e. not
> > totally illegal
> > everywhere, but illegal only in some places in
> > the world. And in
> > reality the existence of a patent doesn't
> > necessarily mean it's
> > enforceable in a court of law (the only
> way we'd
> > know for sure is if
> > someone actually does try to sue)... my 0.02€
> > worth :)
> >
> >
> > Generally only potentially "illegal" in some countries.
> > "Tainted" means contaminated, polluted. A lot stronger
> than
> > potentially "illegal". (Really only actionable in a civil
> > sense, not
> > criminally illegal, as well.)
> > A package could end up there due to an apparently credible
> > rumour,
> > later discredited. (Anyone remember SCO ?)
> >
> >
> > I agree. Problematic comes closer to "potentially
> illegal", so I
> > looked
> > up some synonyms: ambiguous, debatable, dubious,
> > iffy, suspect, speculative, precarious, suspicious, uncertain,
> > unsettled, in addition to problematic itself. Personally
> > I like iffy, which is both short and to the point, but I think
> > several
> > of these would do. WDYT?
> >
> > Dale Huckeby
> >
> > A much better set of choices.
> > (Thanks for looking these up.  Good idea.)
> >
> > Let's remember that the question for these packages is not the
> > quality of their functioning - but rather the advisability to use
> > them, for other reasons, in some countries.
> > So I think that it is better to avoid words that could
> question the
> > QUALITY of the packages.
> >
> > Words in the list like
> >  ambiguous, debatable, problematic, and speculative
> > avoid questioning the quality ... but could be too long or too
> formal.
> > Or just not catchy enough ;)
> > ("Iffy" might be ok - certainly catchy enough.)
> >
> > Additional words I found in Roget's thesaurus, along the same
> lines :
> >
> > Associated more with debatable :
> > arguable, contestable, controvertible, disputable, questionable,
> >
> > Associated more with controversial :
> > confutable, deniable, mistakable, moot
> >
> > Of these additional words, I think that "contestable",
> "disputable",
> > and "controversial" are probably closest to the SENSE of the
> > repositories.
> > But maybe too formal ?
> >
> > Many of these words could be good choices.
> > And maybe someone will come up with some more ?
> >
> > my 2 cents :)
> >
> > - André
> >
> >
> > What about: main, free, non-free?
> > In main is everything what belongs to the core, free contains only
> > packages which are under a free license and in non-free are those
> which
> > aren't clear if free or not (what you mentioned earlier in this
> discussion).
> >
> > All three names are as clear as possible what's meant.
> 
> The license of the packages is not in question (they are free), the
> patent (etc) situat

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Sun, Dec 5, 2010 at 1:59 PM, Maarten Vanraes
 wrote:

>> Since the packages in that repository are there because they're
>> (potentially) encumbered by patents, why not call it for what it is,
>> "encumbered"?
>>
>> --
>> Erin
>
>
> too difficult
>

I suppose that's why nobody liked "supernumerary". 8)

How about "segregated"? Oh, wait ...

The problem is that in all languages, words that mean "not part of the
group", "not one of us" or "not like us" all have negative
connotations for cultural reasons.

Perhaps we need an unrelated word that has meaning to Mageia, but
infers uniqueness without being pejorative.

I suggest calling it the "paris" repository, a place for unique and
useful applications that cannot be placed in any other repository for
whatever reason. Then perhaps any local repository of one-off packages
could always be labeled "paris-local" by default.

-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

On Sun, Dec 5, 2010 at 8:39 PM, Anssi Hannula  wrote:

> On 05.12.2010 19:36, Daniel Kreuter wrote:
> >
> >
> > On Sat, Dec 4, 2010 at 9:32 PM, andre999  > > wrote:
> >
> > Dale Huckeby a écrit :
> >
> > On Sat, 4 Dec 2010, andre999 wrote:
> >
> > John a écrit :
> >
> >
> > On Fri, 3 Dec 2010 11:28:26 +0100
> > Maarten Vanraes wrote:
> >
> > Op vrijdag 03 december 2010 10:45:05 schreef Ahmad
> > Samir:
> > [...]
> >
> > The kernel uses the word "tainted" when it
> > detects the nvidia
> > proprietary module for example, (which
> > admittedly gave me a bit of
> > shock the first time I saw it :)).
> >
> >
> > Heh, i had the same reaction.
> >
> > >From all the proposed names, I think "tainted"
> > is the best one, as the
> >
> > packages in there are in a "grey" zone, i.e. not
> > totally illegal
> > everywhere, but illegal only in some places in
> > the world. And in
> > reality the existence of a patent doesn't
> > necessarily mean it's
> > enforceable in a court of law (the only way we'd
> > know for sure is if
> > someone actually does try to sue)... my 0.02€
> > worth :)
> >
> >
> > Generally only potentially "illegal" in some countries.
> > "Tainted" means contaminated, polluted. A lot stronger than
> > potentially "illegal". (Really only actionable in a civil
> > sense, not
> > criminally illegal, as well.)
> > A package could end up there due to an apparently credible
> > rumour,
> > later discredited. (Anyone remember SCO ?)
> >
> >
> > I agree. Problematic comes closer to "potentially illegal", so I
> > looked
> > up some synonyms: ambiguous, debatable, dubious,
> > iffy, suspect, speculative, precarious, suspicious, uncertain,
> > unsettled, in addition to problematic itself. Personally
> > I like iffy, which is both short and to the point, but I think
> > several
> > of these would do. WDYT?
> >
> > Dale Huckeby
> >
> > A much better set of choices.
> > (Thanks for looking these up.  Good idea.)
> >
> > Let's remember that the question for these packages is not the
> > quality of their functioning - but rather the advisability to use
> > them, for other reasons, in some countries.
> > So I think that it is better to avoid words that could question the
> > QUALITY of the packages.
> >
> > Words in the list like
> >  ambiguous, debatable, problematic, and speculative
> > avoid questioning the quality ... but could be too long or too
> formal.
> > Or just not catchy enough ;)
> > ("Iffy" might be ok - certainly catchy enough.)
> >
> > Additional words I found in Roget's thesaurus, along the same lines :
> >
> > Associated more with debatable :
> > arguable, contestable, controvertible, disputable, questionable,
> >
> > Associated more with controversial :
> > confutable, deniable, mistakable, moot
> >
> > Of these additional words, I think that "contestable", "disputable",
> > and "controversial" are probably closest to the SENSE of the
> > repositories.
> > But maybe too formal ?
> >
> > Many of these words could be good choices.
> > And maybe someone will come up with some more ?
> >
> > my 2 cents :)
> >
> > - André
> >
> >
> > What about: main, free, non-free?
> > In main is everything what belongs to the core, free contains only
> > packages which are under a free license and in non-free are those which
> > aren't clear if free or not (what you mentioned earlier in this
> discussion).
> >
> > All three names are as clear as possible what's meant.
>
> The license of the packages is not in question (they are free), the
> patent (etc) situation is.
>
> --
> Anssi Hannula
>

That's what i ment.

-- 
Mit freundlichen Grüßen

Greetings

Daniel Kreuter

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 05.12.2010 19:36, Daniel Kreuter wrote:
> 
> 
> On Sat, Dec 4, 2010 at 9:32 PM, andre999  > wrote:
> 
> Dale Huckeby a écrit :
> 
> On Sat, 4 Dec 2010, andre999 wrote:
> 
> John a écrit :
> 
> 
> On Fri, 3 Dec 2010 11:28:26 +0100
> Maarten Vanraes wrote:
> 
> Op vrijdag 03 december 2010 10:45:05 schreef Ahmad
> Samir:
> [...]
> 
> The kernel uses the word "tainted" when it
> detects the nvidia
> proprietary module for example, (which
> admittedly gave me a bit of
> shock the first time I saw it :)).
> 
> 
> Heh, i had the same reaction.
> 
> >From all the proposed names, I think "tainted"
> is the best one, as the
> 
> packages in there are in a "grey" zone, i.e. not
> totally illegal
> everywhere, but illegal only in some places in
> the world. And in
> reality the existence of a patent doesn't
> necessarily mean it's
> enforceable in a court of law (the only way we'd
> know for sure is if
> someone actually does try to sue)... my 0.02€
> worth :)
> 
> 
> Generally only potentially "illegal" in some countries.
> "Tainted" means contaminated, polluted. A lot stronger than
> potentially "illegal". (Really only actionable in a civil
> sense, not
> criminally illegal, as well.)
> A package could end up there due to an apparently credible
> rumour,
> later discredited. (Anyone remember SCO ?)
> 
> 
> I agree. Problematic comes closer to "potentially illegal", so I
> looked
> up some synonyms: ambiguous, debatable, dubious,
> iffy, suspect, speculative, precarious, suspicious, uncertain,
> unsettled, in addition to problematic itself. Personally
> I like iffy, which is both short and to the point, but I think
> several
> of these would do. WDYT?
> 
> Dale Huckeby
> 
> A much better set of choices.
> (Thanks for looking these up.  Good idea.)
> 
> Let's remember that the question for these packages is not the
> quality of their functioning - but rather the advisability to use
> them, for other reasons, in some countries.
> So I think that it is better to avoid words that could question the
> QUALITY of the packages.
> 
> Words in the list like
>  ambiguous, debatable, problematic, and speculative
> avoid questioning the quality ... but could be too long or too formal.
> Or just not catchy enough ;)
> ("Iffy" might be ok - certainly catchy enough.)
> 
> Additional words I found in Roget's thesaurus, along the same lines :
> 
> Associated more with debatable :
> arguable, contestable, controvertible, disputable, questionable,
> 
> Associated more with controversial :
> confutable, deniable, mistakable, moot
> 
> Of these additional words, I think that "contestable", "disputable",
> and "controversial" are probably closest to the SENSE of the
> repositories.
> But maybe too formal ?
> 
> Many of these words could be good choices.
> And maybe someone will come up with some more ?
> 
> my 2 cents :)
> 
> - André
> 
> 
> What about: main, free, non-free?
> In main is everything what belongs to the core, free contains only
> packages which are under a free license and in non-free are those which
> aren't clear if free or not (what you mentioned earlier in this discussion).
> 
> All three names are as clear as possible what's meant.

The license of the packages is not in question (they are free), the
patent (etc) situation is.

-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zaterdag 04 december 2010 20:58:12 schreef Erin Wilkins:
> On December 4, 2010 10:06:37 Anssi Hannula wrote:
> > On 03.12.2010 11:45, Ahmad Samir wrote:
> > > On 2 December 2010 18:43, Michael Scherer  wrote:
> > >> Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
> > >>> 2010/12/2 Anssi Hannula :
> >  For the record, I'm not a big fan of "tainted" name (too negative),
> >  but I can't think of anything better either, so... :)
> > >>> 
> > >>> I agree, as "restricted" may be misleading former Mandriva users, why
> > >>> not "special" or "extra"?
> > >>> 
> > >>> I know there is the name "extra" for some other branch but it may be
> > >>> easier to find another name for that one.
> > >> 
> > >> That would be misleading to the content of the directory.
> > >> 
> > >> What about "limited" ?
> > >> "restrained" ?
> > >> ( restrain, to deprive of liberty , seems like the perfect match )
> > >> 
> > >> 
> > >> --
> > >> Michael Scherer
> > > 
> > > limited and restrained don't sound right as they don't fully convey
> > > the purpose/filtering-rule for packages in that repo
> > 
> > Indeed.
> > 
> > Wolfgang's "foggy" sounds nice, but I think I prefer "tainted" anyway.
> 
> Since the packages in that repository are there because they're
> (potentially) encumbered by patents, why not call it for what it is,
> "encumbered"?
> 
> --
> Erin


too difficult

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zaterdag 04 december 2010 21:32:51 schreef andre999:
> Dale Huckeby a écrit :
> > On Sat, 4 Dec 2010, andre999 wrote:
> >> John a écrit :
> >>> On Fri, 3 Dec 2010 11:28:26 +0100
> >>> 
> >>> Maarten Vanraes wrote:
>  Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
>  [...]
>  
> > The kernel uses the word "tainted" when it detects the nvidia
> > proprietary module for example, (which admittedly gave me a bit of
> > shock the first time I saw it :)).
>  
>  Heh, i had the same reaction.
>  
> > From all the proposed names, I think "tainted" is the best one, as
> > the
> > 
> > packages in there are in a "grey" zone, i.e. not totally illegal
> > everywhere, but illegal only in some places in the world. And in
> > reality the existence of a patent doesn't necessarily mean it's
> > enforceable in a court of law (the only way we'd know for sure is if
> > someone actually does try to sue)... my 0.02€ worth :)
> >> 
> >> Generally only potentially "illegal" in some countries.
> >> "Tainted" means contaminated, polluted. A lot stronger than
> >> potentially "illegal". (Really only actionable in a civil sense, not
> >> criminally illegal, as well.)
> >> A package could end up there due to an apparently credible rumour,
> >> later discredited. (Anyone remember SCO ?)
> > 
> > I agree. Problematic comes closer to "potentially illegal", so I looked
> > up some synonyms: ambiguous, debatable, dubious,
> > iffy, suspect, speculative, precarious, suspicious, uncertain,
> > unsettled, in addition to problematic itself. Personally
> > I like iffy, which is both short and to the point, but I think several
> > of these would do. WDYT?
> > 
> > Dale Huckeby
> 
> A much better set of choices.
> (Thanks for looking these up.  Good idea.)
> 
> Let's remember that the question for these packages is not the quality
> of their functioning - but rather the advisability to use them, for
> other reasons, in some countries.
> So I think that it is better to avoid words that could question the
> QUALITY of the packages.
> 
> Words in the list like
>   ambiguous, debatable, problematic, and speculative
> avoid questioning the quality ... but could be too long or too formal.
> Or just not catchy enough ;)
> ("Iffy" might be ok - certainly catchy enough.)
> 
> Additional words I found in Roget's thesaurus, along the same lines :
> 
> Associated more with debatable :
> arguable, contestable, controvertible, disputable, questionable,
> 
> Associated more with controversial :
> confutable, deniable, mistakable, moot
> 
> Of these additional words, I think that "contestable", "disputable", and
> "controversial" are probably closest to the SENSE of the repositories.
> But maybe too formal ?
> 
> Many of these words could be good choices.
> And maybe someone will come up with some more ?
> 
> my 2 cents :)
> 
> - André


i like speculative

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op zaterdag 04 december 2010 15:40:58 schreef Hoyt Duff:
> On Sat, Dec 4, 2010 at 4:33 AM, andre999  wrote:
> > Better than "tainted" :D
> 
>  "Tainted" makes me chuckle -- crude anatomical reference.

I don't get that one...

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

On Sat, Dec 4, 2010 at 9:32 PM, andre999  wrote:

> Dale Huckeby a écrit :
>
>> On Sat, 4 Dec 2010, andre999 wrote:
>>
>>  John a écrit :
>>>

 On Fri, 3 Dec 2010 11:28:26 +0100
 Maarten Vanraes wrote:

  Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
> [...]
>
>> The kernel uses the word "tainted" when it detects the nvidia
>> proprietary module for example, (which admittedly gave me a bit of
>> shock the first time I saw it :)).
>>
>
> Heh, i had the same reaction.
>
>  From all the proposed names, I think "tainted" is the best one, as the
>>
>> packages in there are in a "grey" zone, i.e. not totally illegal
>> everywhere, but illegal only in some places in the world. And in
>> reality the existence of a patent doesn't necessarily mean it's
>> enforceable in a court of law (the only way we'd know for sure is if
>> someone actually does try to sue)... my 0.02€ worth :)
>>
>
>>> Generally only potentially "illegal" in some countries.
>>> "Tainted" means contaminated, polluted. A lot stronger than
>>> potentially "illegal". (Really only actionable in a civil sense, not
>>> criminally illegal, as well.)
>>> A package could end up there due to an apparently credible rumour,
>>> later discredited. (Anyone remember SCO ?)
>>>
>>
>> I agree. Problematic comes closer to "potentially illegal", so I looked
>> up some synonyms: ambiguous, debatable, dubious,
>> iffy, suspect, speculative, precarious, suspicious, uncertain,
>> unsettled, in addition to problematic itself. Personally
>> I like iffy, which is both short and to the point, but I think several
>> of these would do. WDYT?
>>
>> Dale Huckeby
>>
>>  A much better set of choices.
> (Thanks for looking these up.  Good idea.)
>
> Let's remember that the question for these packages is not the quality of
> their functioning - but rather the advisability to use them, for other
> reasons, in some countries.
> So I think that it is better to avoid words that could question the QUALITY
> of the packages.
>
> Words in the list like
>  ambiguous, debatable, problematic, and speculative
> avoid questioning the quality ... but could be too long or too formal.
> Or just not catchy enough ;)
> ("Iffy" might be ok - certainly catchy enough.)
>
> Additional words I found in Roget's thesaurus, along the same lines :
>
> Associated more with debatable :
> arguable, contestable, controvertible, disputable, questionable,
>
> Associated more with controversial :
> confutable, deniable, mistakable, moot
>
> Of these additional words, I think that "contestable", "disputable", and
> "controversial" are probably closest to the SENSE of the repositories.
> But maybe too formal ?
>
> Many of these words could be good choices.
> And maybe someone will come up with some more ?
>
> my 2 cents :)
>
> - André
>

What about: main, free, non-free?
In main is everything what belongs to the core, free contains only packages
which are under a free license and in non-free are those which aren't clear
if free or not (what you mentioned earlier in this discussion).

All three names are as clear as possible what's meant.

-- 
Mit freundlichen Grüßen

Greetings

Daniel Kreuter

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Dale Huckeby a écrit :

On Sat, 4 Dec 2010, andre999 wrote:


John a écrit :


On Fri, 3 Dec 2010 11:28:26 +0100
Maarten Vanraes wrote:


Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
[...]

The kernel uses the word "tainted" when it detects the nvidia
proprietary module for example, (which admittedly gave me a bit of
shock the first time I saw it :)).


Heh, i had the same reaction.


From all the proposed names, I think "tainted" is the best one, as the

packages in there are in a "grey" zone, i.e. not totally illegal
everywhere, but illegal only in some places in the world. And in
reality the existence of a patent doesn't necessarily mean it's
enforceable in a court of law (the only way we'd know for sure is if
someone actually does try to sue)... my 0.02€ worth :)


Generally only potentially "illegal" in some countries.
"Tainted" means contaminated, polluted. A lot stronger than
potentially "illegal". (Really only actionable in a civil sense, not
criminally illegal, as well.)
A package could end up there due to an apparently credible rumour,
later discredited. (Anyone remember SCO ?)


I agree. Problematic comes closer to "potentially illegal", so I looked
up some synonyms: ambiguous, debatable, dubious,
iffy, suspect, speculative, precarious, suspicious, uncertain,
unsettled, in addition to problematic itself. Personally
I like iffy, which is both short and to the point, but I think several
of these would do. WDYT?

Dale Huckeby


A much better set of choices.
(Thanks for looking these up.  Good idea.)

Let's remember that the question for these packages is not the quality 
of their functioning - but rather the advisability to use them, for 
other reasons, in some countries.
So I think that it is better to avoid words that could question the 
QUALITY of the packages.


Words in the list like
 ambiguous, debatable, problematic, and speculative
avoid questioning the quality ... but could be too long or too formal.
Or just not catchy enough ;)
("Iffy" might be ok - certainly catchy enough.)

Additional words I found in Roget's thesaurus, along the same lines :

Associated more with debatable :
arguable, contestable, controvertible, disputable, questionable,

Associated more with controversial :
confutable, deniable, mistakable, moot

Of these additional words, I think that "contestable", "disputable", and 
"controversial" are probably closest to the SENSE of the repositories.

But maybe too formal ?

Many of these words could be good choices.
And maybe someone will come up with some more ?

my 2 cents :)

- André

Re: [Mageia-dev] Mirror layout, round two

[Erin Wilkins]

On December 4, 2010 10:06:37 Anssi Hannula wrote:
> On 03.12.2010 11:45, Ahmad Samir wrote:
> > On 2 December 2010 18:43, Michael Scherer  wrote:
> >> Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
> >>> 2010/12/2 Anssi Hannula :
>  For the record, I'm not a big fan of "tainted" name (too negative),
>  but I can't think of anything better either, so... :)
> >>> 
> >>> I agree, as "restricted" may be misleading former Mandriva users, why
> >>> not "special" or "extra"?
> >>> 
> >>> I know there is the name "extra" for some other branch but it may be
> >>> easier to find another name for that one.
> >> 
> >> That would be misleading to the content of the directory.
> >> 
> >> What about "limited" ?
> >> "restrained" ?
> >> ( restrain, to deprive of liberty , seems like the perfect match )
> >> 
> >> 
> >> --
> >> Michael Scherer
> > 
> > limited and restrained don't sound right as they don't fully convey
> > the purpose/filtering-rule for packages in that repo
> 
> Indeed.
> 
> Wolfgang's "foggy" sounds nice, but I think I prefer "tainted" anyway.

Since the packages in that repository are there because they're (potentially) 
encumbered by patents, why not call it for what it is, "encumbered"?

--
Erin

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 03.12.2010 11:45, Ahmad Samir wrote:
> On 2 December 2010 18:43, Michael Scherer  wrote:
>> Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
>>> 2010/12/2 Anssi Hannula :

 For the record, I'm not a big fan of "tainted" name (too negative), but
 I can't think of anything better either, so... :)
>>>
>>> I agree, as "restricted" may be misleading former Mandriva users, why
>>> not "special" or "extra"?
>>>
>>> I know there is the name "extra" for some other branch but it may be
>>> easier to find another name for that one.
>>
>> That would be misleading to the content of the directory.
>>
>> What about "limited" ?
>> "restrained" ?
>> ( restrain, to deprive of liberty , seems like the perfect match )
>>
>>
>> --
>> Michael Scherer
>>
>>
> 
> limited and restrained don't sound right as they don't fully convey
> the purpose/filtering-rule for packages in that repo

Indeed.

Wolfgang's "foggy" sounds nice, but I think I prefer "tainted" anyway.

-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[Dale Huckeby]

On Sat, 4 Dec 2010, andre999 wrote:


John a écrit :


On Fri, 3 Dec 2010 11:28:26 +0100
Maarten Vanraes wrote:


Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
[...]

The kernel uses the word "tainted" when it detects the nvidia
proprietary module for example, (which admittedly gave me a bit of
shock the first time I saw it :)).


Heh, i had the same reaction.


 From all the proposed names, I think "tainted" is the best one, as the

packages in there are in a "grey" zone, i.e. not totally illegal
everywhere, but illegal only in some places in the world. And in
reality the existence of a patent doesn't necessarily mean it's
enforceable in a court of law (the only way we'd know for sure is if
someone actually does try to sue)... my 0.02€ worth :)


Generally only potentially "illegal" in some countries.
"Tainted" means contaminated, polluted.  A lot stronger than potentially 
"illegal".  (Really only actionable in a civil sense, not criminally illegal, 
as well.)
A package could end up there due to an apparently credible rumour, later 
discredited.  (Anyone remember SCO ?)


I agree.  Problematic comes closer to "potentially illegal", so I looked up 
some synonyms: ambiguous, debatable, dubious,
iffy, suspect, speculative, precarious, suspicious, uncertain, unsettled, in 
addition to problematic itself.  Personally
I like iffy, which is both short and to the point, but I think several of these 
would do.  WDYT?

Dale Huckeby

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Sat, Dec 4, 2010 at 4:33 AM, andre999  wrote:

> Better than "tainted" :D
>
 "Tainted" makes me chuckle -- crude anatomical reference.


-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Wolfgang Bornath a écrit :


2010/12/3 John:


'Grayzone' ?


Mr. Dorian Gray's zone? Or a foggy grey zone?
(SCNR!)

Hmm, "foggy" sounds nice :)
Or Foggy Bottom :)


Better than "tainted" :D

Re: [Mageia-dev] Mirror layout, round two

[andre999]

John a écrit :


On Fri, 3 Dec 2010 11:28:26 +0100
Maarten Vanraes wrote:


Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
[...]

The kernel uses the word "tainted" when it detects the nvidia
proprietary module for example, (which admittedly gave me a bit of
shock the first time I saw it :)).


Heh, i had the same reaction.


 From all the proposed names, I think "tainted" is the best one, as the

packages in there are in a "grey" zone, i.e. not totally illegal
everywhere, but illegal only in some places in the world. And in
reality the existence of a patent doesn't necessarily mean it's
enforceable in a court of law (the only way we'd know for sure is if
someone actually does try to sue)... my 0.02€ worth :)


Generally only potentially "illegal" in some countries.
"Tainted" means contaminated, polluted.  A lot stronger than potentially 
"illegal".  (Really only actionable in a civil sense, not criminally 
illegal, as well.)
A package could end up there due to an apparently credible rumour, later 
discredited.  (Anyone remember SCO ?)


how about "gray" or "grey" ?


'Grayzone' ?

John



Yes, "greyzone" conveys the idea very well.

Or "problematic" ?

my 2 cents :)

André

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op vrijdag 03 december 2010 18:58:15 schreef herman:
> On Fri, 2010-12-03 at 03:28 -0700, Maarten Vanraes wrote:
> > how about "gray" or "grey" ?
> 
> No, the Speling Nazi's will drive us nuts...

For this, it is no problem, because they are both correct! :-P

Re: [Mageia-dev] Mirror layout, round two

[Wolfgang Bornath]

2010/12/3 John :
>
> 'Grayzone' ?

Mr. Dorian Gray's zone? Or a foggy grey zone?
(SCNR!)

Hmm, "foggy" sounds nice :)
Or Foggy Bottom :)

-- 
wobo

Re: [Mageia-dev] Mirror layout, round two

[John]

On Fri, 3 Dec 2010 11:28:26 +0100
Maarten Vanraes wrote:

> Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
> [...]
> > The kernel uses the word "tainted" when it detects the nvidia
> > proprietary module for example, (which admittedly gave me a bit of
> > shock the first time I saw it :)).
> 
> Heh, i had the same reaction.
> 
> > From all the proposed names, I think "tainted" is the best one, as the
> > 
> > packages in there are in a "grey" zone, i.e. not totally illegal
> > everywhere, but illegal only in some places in the world. And in
> > reality the existence of a patent doesn't necessarily mean it's
> > enforceable in a court of law (the only way we'd know for sure is if
> > someone actually does try to sue)... my 0.02€ worth :)
> 
> how about "gray" or "grey" ?

'Grayzone' ?

John

Re: [Mageia-dev] Mirror layout, round two

[herman]

On Fri, 2010-12-03 at 03:28 -0700, Maarten Vanraes wrote:
> how about "gray" or "grey" ?

No, the Speling Nazi's will drive us nuts...

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op vrijdag 03 december 2010 10:45:05 schreef Ahmad Samir:
[...]
> The kernel uses the word "tainted" when it detects the nvidia
> proprietary module for example, (which admittedly gave me a bit of
> shock the first time I saw it :)).

Heh, i had the same reaction.

> From all the proposed names, I think "tainted" is the best one, as the
> 
> packages in there are in a "grey" zone, i.e. not totally illegal
> everywhere, but illegal only in some places in the world. And in
> reality the existence of a patent doesn't necessarily mean it's
> enforceable in a court of law (the only way we'd know for sure is if
> someone actually does try to sue)... my 0.02€ worth :)

how about "gray" or "grey" ?

Re: [Mageia-dev] Mirror layout, round two

[Ahmad Samir]

On 2 December 2010 18:43, Michael Scherer  wrote:
> Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
>> 2010/12/2 Anssi Hannula :
>> >
>> > For the record, I'm not a big fan of "tainted" name (too negative), but
>> > I can't think of anything better either, so... :)
>>
>> I agree, as "restricted" may be misleading former Mandriva users, why
>> not "special" or "extra"?
>>
>> I know there is the name "extra" for some other branch but it may be
>> easier to find another name for that one.
>
> That would be misleading to the content of the directory.
>
> What about "limited" ?
> "restrained" ?
> ( restrain, to deprive of liberty , seems like the perfect match )
>
>
> --
> Michael Scherer
>
>

limited and restrained don't sound right as they don't fully convey
the purpose/filtering-rule for packages in that repo

The kernel uses the word "tainted" when it detects the nvidia
proprietary module for example, (which admittedly gave me a bit of
shock the first time I saw it :)).

>From all the proposed names, I think "tainted" is the best one, as the
packages in there are in a "grey" zone, i.e. not totally illegal
everywhere, but illegal only in some places in the world. And in
reality the existence of a patent doesn't necessarily mean it's
enforceable in a court of law (the only way we'd know for sure is if
someone actually does try to sue)... my 0.02€ worth :)

-- 
Ahmad Samir

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Maarten Vanraes a écrit :


Op donderdag 02 december 2010 08:20:15 schreef andre999:

Maarten Vanraes a écrit :

Op woensdag 01 december 2010 21:54:48 schreef andre999:
[...]



i also see that mirror layout should be as easy as possible for mirror
admins.


Agreed.  However keeping an extra set of repositories for core packages
would just add a few extra directories (without changing the number/size
of their total content), thus have little impact on mirror administration.


One would think so; however, a few people who replied where mirror
administrators; and it seems, IIUC that they said it does have impact.

I'm just gonna trust their judgement on this, since they know more about this
than myself.


Mageia requires mirror sites to use rsync for mirroring.
Mirroring at least every few hours, if I remember correctly.  (I forget 
the other details.)


They need a single line of code, something like

rsync -ra {URL-source-directory} {local-destination-directory}

This is very easy to do : Mageia gives the source URL (and the options 
required), and the mirror site knows the destination directory.


This line of code is put in a cron (or acron) job file, configured to 
run automatically at the specified regular intervals.


If they exclude the optional "tainted" repositories, they have to add an 
"--exclude" option with the relative path to these repositories.

(Still in a single line.)
Fairly straight-forward.

Why system admins in multi-mirror sites with lots of other tasks would 
like to avoid optional repositories is that they are probably already 
overloaded with things to do, and adding the exclusion multiplies the 
risk of having a (tiny) error that makes it not work.

Also, a minor change at the Mageia source could make it stop working.
The last thing they need is another problem.


[...]


Note that if, down the road, we find another effective method for
distinquishing core / non-core, it is relatively simple to transfer
packages in "extra" to "core".
But if we eliminate the parallel set of repositories, and find later
that we have a problem giving priority to core packages, moving in the
other direction would be a much more difficult process.


IIRC someone with experience said in this thread that we could always go to
that sort of scenario if like this it wouldn't work well. Again, i'm gonna
trust their judgement on this.


( At least some things said in this thread seem to me more in the line 
of wishful thinking.  A bit like "I'm not planning to have an accident, 
so why do I need a seat belt ?" )


I still think it would be better to later remove than add.
The main problem is that without the separation by repositories, in 
order to ensure full support for core modules, we would need another 
control.
If we start with separate sets of repositories, that control is already 
there - removing the complication of adding some other control in 
setting up the system.
Maybe we can find a way of setting up a reliable such control in the 
build system without a too much effort.  But it is more effort, subject 
to debugging, etc, as with any new code.


regards

- André

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Maarten Vanraes a écrit :


Op donderdag 02 december 2010 17:43:10 schreef Michael Scherer:

Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :

2010/12/2 Anssi Hannula:

For the record, I'm not a big fan of "tainted" name (too negative), but
I can't think of anything better either, so... :)


I agree, as "restricted" may be misleading former Mandriva users, why
not "special" or "extra"?

I know there is the name "extra" for some other branch but it may be
easier to find another name for that one.


That would be misleading to the content of the directory.

What about "limited" ?
"restrained" ?
( restrain, to deprive of liberty , seems like the perfect match )


/me likes


"limited" and "restrained" are both good

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op donderdag 02 december 2010 18:23:35 schreef Leandro Dorileo:
> On Thu, Dec 2, 2010 at 12:26 PM, Wolfgang Bornath
> 
>  wrote:
> > 2010/12/2 Anssi Hannula :
> >> For the record, I'm not a big fan of "tainted" name (too negative), but
> >> I can't think of anything better either, so... :)
> > 
> > I agree, as "restricted" may be misleading former Mandriva users, why
> > not "special" or "extra"?
> > 
> > I know there is the name "extra" for some other branch but it may be
> > easier to find another name for that one.
> 
> What about "leftover"? or maybe "optional"?
> 
> 
> regards

/me likes leftovers

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op donderdag 02 december 2010 17:43:10 schreef Michael Scherer:
> Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
> > 2010/12/2 Anssi Hannula :
> > > For the record, I'm not a big fan of "tainted" name (too negative), but
> > > I can't think of anything better either, so... :)
> > 
> > I agree, as "restricted" may be misleading former Mandriva users, why
> > not "special" or "extra"?
> > 
> > I know there is the name "extra" for some other branch but it may be
> > easier to find another name for that one.
> 
> That would be misleading to the content of the directory.
> 
> What about "limited" ?
> "restrained" ?
> ( restrain, to deprive of liberty , seems like the perfect match )

/me likes

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op donderdag 02 december 2010 08:20:15 schreef andre999:
> Maarten Vanraes a écrit :
> > Op woensdag 01 december 2010 21:54:48 schreef andre999:
> > [...]
> > 
> > allthough interesting, this thread is about mirror layout; and is not
> > about removing the distinction between supported packages and not. (this
> > wasn't all that clear to me at first.)
> 
> I'll discuss further down why I think that this is a critical part of
> the question.
> 
> > i do understand that you think other methods of having the distinction
> > might not work; i have reservations myself that way. (i do feel the
> > disctinction is important.)
> 
> Glad to see that you understand my concerns.
> 
> > i also see that mirror layout should be as easy as possible for mirror
> > admins.
> 
> Agreed.  However keeping an extra set of repositories for core packages
> would just add a few extra directories (without changing the number/size
> of their total content), thus have little impact on mirror administration.

One would think so; however, a few people who replied where mirror 
administrators; and it seems, IIUC that they said it does have impact.

I'm just gonna trust their judgement on this, since they know more about this 
than myself.

[... snipping tainted stuff...] 
> In any case, rsync is a pretty straight-forward application.
> 
> > however, looking at the big picture, i think that logically it's sounds
> > to have one purpose to one thing; and thus for the mirror layout; only
> > the mirror admins should be looked at; the viewpoint of a user _should_
> > not really matter.
> 
> I agree that the user viewpoint is not of major importance : I see that
> as just a positive side effect.
> 
> I am trying to look at the big picture.  And perhaps I haven't been very
> effective at expressing my concerns.
> In my mind, we should always consider important side effects of major
> changes.  And removing separate "core"/"extra" (or "main"/"contrib"
> repositories does have an important side effect.
> Realigning "core" so it is really core should very much help packagers,
> as well as maintaining an important distinction.
> 
> Note that if, down the road, we find another effective method for
> distinquishing core / non-core, it is relatively simple to transfer
> packages in "extra" to "core".
> But if we eliminate the parallel set of repositories, and find later
> that we have a problem giving priority to core packages, moving in the
> other direction would be a much more difficult process.

IIRC someone with experience said in this thread that we could always go to 
that sort of scenario if like this it wouldn't work well. Again, i'm gonna 
trust their judgement on this.

> The suggestion that we only transfer to Mageia packages that we see as
> important to keep, sounds like a very good approach.
> This would also facilitate maintaining the core / non-core distinction.

I suppose, however, I think that developers are their own users; they write 
for theirselves; hence people will pull what they think is important for them.

but at the very least, since it's something they will use, it'll at least be 
tested some. (even if QA doesn't test it)

> I'm not trying to say that defining core / non-core in detail is a
> trivial process.  But it is in the interest of Mageia to define it.
> 
> I realise, at least at first, that things will be more difficult for
> packagers.  But firmly believe that this will be largely alleviated by a
> careful triage of existing "main" and "contrib" packages.
> Thus I am more than willing to put in a lot of effort, since it will
> have an important impact on the future of Mageia.
> 
> I also realise that many of those proposing eliminating a set of repos
> have a lot of valuable experience.  And I'm sure that if/when we can
> agree on this concern, that we will be able to work very well together.
> And I look forward to becoming a Mageia packager.
> 
> another 2 cents :)
> 
> - André

Re: [Mageia-dev] Mirror layout, round two

[Leandro Dorileo]

On Thu, Dec 2, 2010 at 12:26 PM, Wolfgang Bornath
 wrote:
> 2010/12/2 Anssi Hannula :
>>
>> For the record, I'm not a big fan of "tainted" name (too negative), but
>> I can't think of anything better either, so... :)
>
> I agree, as "restricted" may be misleading former Mandriva users, why
> not "special" or "extra"?
>
> I know there is the name "extra" for some other branch but it may be
> easier to find another name for that one.
>

What about "leftover"? or maybe "optional"?


regards

-- 
Leandro Dorileo

Re: [Mageia-dev] Mirror layout, round two

[Hoyt Duff]

On Thu, Dec 2, 2010 at 10:26 AM, Wolfgang Bornath
 wrote:
> 2010/12/2 Anssi Hannula :
>>
>> For the record, I'm not a big fan of "tainted" name (too negative), but
>> I can't think of anything better either, so... :)
>
> I agree, as "restricted" may be misleading former Mandriva users, why
> not "special" or "extra"?
>
> I know there is the name "extra" for some other branch but it may be
> easier to find another name for that one.
>
> --
> wobo
>

supernumerary

a thing that exceeds the required, an extra


-- 
Hoyt

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le jeudi 02 décembre 2010 à 16:26 +0100, Wolfgang Bornath a écrit :
> 2010/12/2 Anssi Hannula :
> >
> > For the record, I'm not a big fan of "tainted" name (too negative), but
> > I can't think of anything better either, so... :)
> 
> I agree, as "restricted" may be misleading former Mandriva users, why
> not "special" or "extra"?
> 
> I know there is the name "extra" for some other branch but it may be
> easier to find another name for that one.

That would be misleading to the content of the directory. 

What about "limited" ?
"restrained" ?
( restrain, to deprive of liberty , seems like the perfect match )


-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Wolfgang Bornath]

2010/12/2 Anssi Hannula :
>
> For the record, I'm not a big fan of "tainted" name (too negative), but
> I can't think of anything better either, so... :)

I agree, as "restricted" may be misleading former Mandriva users, why
not "special" or "extra"?

I know there is the name "extra" for some other branch but it may be
easier to find another name for that one.

-- 
wobo

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 01.12.2010 22:29, Anssi Hannula wrote:
> On 30.11.2010 12:37, Thomas Backlund wrote:
> [...]
>> Can we reach an agreement that this is the way to start the distro?
> 
> Yes.
> 
>>
>> and for refernece: The suggested layout for is:
>>
>> * core
>> * nonfree
>> * tainted

For the record, I'm not a big fan of "tainted" name (too negative), but
I can't think of anything better either, so... :)

>> * debug_core
>> * debug_nonfree
>> * debug_tainted
>>
>>
>> Every media contains the same layout:
>>
>> * backports
>> * backports_testing
>> * release
>> * updates
>> * updates_testing
> 
> I wonder which 32bit ones we should add on 64bit, and which ones of
> those should be enabled and which ones disabled.
> 
> On MDV, main+main_updates were added and enabled.
> 
> But for example wine backports are commonly wanted by 64bit users, and
> those are in main/backports (core/backports for us).
> 
> Or is there an alternative approach that I can't think of?
> 


-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Maarten Vanraes a écrit :


Op woensdag 01 december 2010 21:54:48 schreef andre999:
[...]

allthough interesting, this thread is about mirror layout; and is not about
removing the distinction between supported packages and not. (this wasn't all
that clear to me at first.)


I'll discuss further down why I think that this is a critical part of 
the question.


i do understand that you think other methods of having the distinction might
not work; i have reservations myself that way. (i do feel the disctinction is
important.)


Glad to see that you understand my concerns.


i also see that mirror layout should be as easy as possible for mirror admins.


Agreed.  However keeping an extra set of repositories for core packages 
would just add a few extra directories (without changing the number/size 
of their total content), thus have little impact on mirror administration.


However "tainted" repositories, being optional, would be more problematic.
Especially, as others pointed out, for the larger multi-project mirror 
sites, where admins are already distracted by many other demands.


On the other hand, I see the point of adding "tainted".
Since it is for packages that are likely to be problematic in *some* 
countries, I imagine that relatively few of these larger mirror admins 
would feel the need to exclude "tainted".
(And for the same reason my quibble about choosing a more neutral name, 
such as "restricted".  Or maybe even "problematic".  For countries where 
these packages would be acceptable.)


In any case, rsync is a pretty straight-forward application.


however, looking at the big picture, i think that logically it's sounds to
have one purpose to one thing; and thus for the mirror layout; only the mirror
admins should be looked at; the viewpoint of a user _should_ not really
matter.


I agree that the user viewpoint is not of major importance : I see that 
as just a positive side effect.


I am trying to look at the big picture.  And perhaps I haven't been very 
effective at expressing my concerns.
In my mind, we should always consider important side effects of major 
changes.  And removing separate "core"/"extra" (or "main"/"contrib" 
repositories does have an important side effect.
Realigning "core" so it is really core should very much help packagers, 
as well as maintaining an important distinction.


Note that if, down the road, we find another effective method for 
distinquishing core / non-core, it is relatively simple to transfer 
packages in "extra" to "core".
But if we eliminate the parallel set of repositories, and find later 
that we have a problem giving priority to core packages, moving in the 
other direction would be a much more difficult process.


The suggestion that we only transfer to Mageia packages that we see as 
important to keep, sounds like a very good approach.

This would also facilitate maintaining the core / non-core distinction.

I'm not trying to say that defining core / non-core in detail is a 
trivial process.  But it is in the interest of Mageia to define it.


I realise, at least at first, that things will be more difficult for 
packagers.  But firmly believe that this will be largely alleviated by a 
careful triage of existing "main" and "contrib" packages.
Thus I am more than willing to put in a lot of effort, since it will 
have an important impact on the future of Mageia.


I also realise that many of those proposing eliminating a set of repos 
have a lot of valuable experience.  And I'm sure that if/when we can 
agree on this concern, that we will be able to work very well together.

And I look forward to becoming a Mageia packager.

another 2 cents :)

- André

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op woensdag 01 december 2010 21:54:48 schreef andre999:
[...]

allthough interesting, this thread is about mirror layout; and is not about 
removing the distinction between supported packages and not. (this wasn't all 
that clear to me at first.)

i do understand that you think other methods of having the distinction might 
not work; i have reservations myself that way. (i do feel the disctinction is 
important.)

i also see that mirror layout should be as easy as possible for mirror admins.

however, looking at the big picture, i think that logically it's sounds to 
have one purpose to one thing; and thus for the mirror layout; only the mirror 
admins should be looked at; the viewpoint of a user _should_ not really 
matter.

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Ahmad Samir a écrit :


On 30 November 2010 07:29, andre999  wrote:

Michael Scherer a écrit :


Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :


Yann Ciret a écrit :


I dislike the main/contrib separation in some case.
The first example is with Mozilla Thunderbird packages. Some extension
packages are in contrib. So each time thunderbird received security
update, the update cannot be installed because of non automatically
rebuild of his contrib package. And each time I see a bug report of user
asking a manual rebuilt. With only one core media, this situation will
disapear (I hope).


Unlikely.  This problem is not at all related to separate repositories.


It is. It is exactly related to the fact that thunderbird is supported,
and that extension are not despites depending on it.


In this case it is evident that you don't understand how extensions work
with mozilla products.
Thunderbird will function correctly with no  extensions installed.
So why should any extension block the update of Thunderbird ?


So the user can simply uninstall that extension and update to new
thunderbird? the user can do this only if he doesn't need that
extension, only if it doesn't offer features he wants to use. That's
an invalid argument, if he doesn't need that extension why does he
have it on his system??


You're missing some points here :
1) There is no need to remove an extension.  It will continue to work, 
as long as there hasn't been some error in packaging.  In other words, 
on a generic Mozilla installation, it would continue to work.  The only 
exceptions in the past are when Mozilla changed the version of XML used 
to code extensions.  (Which has happened twice since the beginning of 
Mozilla, if I recall correctly.)  But that would not happen on an update.


2) If by chance the extension does not work properly, it can always be 
updated directly by the update function inside Thunderbird.  Unless the 
distro packaging has somehow disabled this function.  Which would be an 
error in packaging.


3) There is no reason to package Mozilla extensions in the distro, 
except for base localisation modules, which are already in main.


4) If an optional module of any application stops working, that can only 
affect the application in question.  And should not stop the application 
from working.  That does not in itself justify such an extension being 
considered (logically) core.


The rationale is/was that mozilla code breaks/broke ABI, so it was
agreed that extensions are rebuilt for both firefox and thunderbird
respective new versions.

See above.


We will look into that with upstream, so that if a rebuild isn't
needed, then all the better for us (packagers). But until that
happens, they will be rebuilt. A 1-2 day delay isn't too much for
users.
Good.  Check with upstream.  It can be done quickly, and will help clean 
the system.
By the way, if you install Thunderbird, you can confirm the critical 
elements yourself.  (Installation/update of Extensions and other 
optional modules fully managable from inside Thunderbird.  As well, by 
default there are automatic alerts when updates become available.)


The more pressing issue is, what does this have to do with the topic
at hand "Mirrors layout, round two" ?? this discussion is deviating
too much, to the extent it's becoming bloated...


Everything.
Removing the distinction between core and non-core packages removes an 
important control, useful to give greater assurance that (logically) 
core packages are not broken, thus breaking users' systems.
In my mind, alternative controls are likely to be more complex to 
maintain, and probably less reliable.
It is interesting that the names "core" and "extra" were chosen to 
replace "main" and "contrib".
Especially since "main" was originally meant to be core packages.  But 
not enforced, as some packagers themselves have pointed out.

(One would prefer that I don't mention his name.)



Additionally, modules installed will continue to work as long as the major
version doesn't change.  (Actually slightly more complicated.)
In some cases one won't be able to newly install a module because a config
file inside the module - equivalent to the spec file in rpm packages -
hasn't been updated for compatible versions.  (In fact, the versions were
probably improperly specified.)  But installed modules will continue to
function.
It is possible that the packager did not realise this - or for whatever
reason did not properly set up a spec file - but this issue has nothing at
all to do with separate sets of repositories.


Speaking abstractly without examples in this case is just that,
"speaking". Give us an example of such a case (if any) in a spec file
so that it can be fixed.

More precise details added above.



That precisely because we tell "security and bugfixes occurs only on
main" that contribs got broken, since the security team do not care to
not break contribs packages


The crux of this problem is that core (in t

Re: [Mageia-dev] Mirror layout, round two

[Anssi Hannula]

On 30.11.2010 12:37, Thomas Backlund wrote:
[...]
> Can we reach an agreement that this is the way to start the distro?

Yes.

> 
> and for refernece: The suggested layout for is:
> 
> * core
> * nonfree
> * tainted
> * debug_core
> * debug_nonfree
> * debug_tainted
> 
> 
> Every media contains the same layout:
> 
> * backports
> * backports_testing
> * release
> * updates
> * updates_testing

I wonder which 32bit ones we should add on 64bit, and which ones of
those should be enabled and which ones disabled.

On MDV, main+main_updates were added and enabled.

But for example wine backports are commonly wanted by 64bit users, and
those are in main/backports (core/backports for us).

Or is there an alternative approach that I can't think of?

-- 
Anssi Hannula

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

On 01.12.2010 00:12, Maarten Vanraes wrote:

Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit :

So, after reading all different opinions here and discussing with
founders, here is the idea:

We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
we wont use the name "restricted" as it was used in MDV commercial
products.

Now all of theese medias will have their 5 submedias: release, updates,
updates_testing, backports, backports_testing.

That brings us to 30 medias in total :)

The details of the media layout suggestion is also at the end of this
mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy


Now...

We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a working
buildsystem / base to build from.

Then we to go on with and start importing X, the different
DE's and every other package needed to build a full distro.

By doing it this way, we get a clean start, every package rebuilt,
and no old/unmaintained stuff in the beginning.

Then as more maintainers join, I guess more packages will be imported
from cooker and other sources. And packages can always be requested.

As for those that want the core/extra split:
We already tried it with main/contrib split. And I know mdv is now
trying to refine what belongs in main or not, but thats for mdv
to work through the "problem" as it wont be an easy task.

For us I think the best way for now is to start with this suggested
layout, and see if it works well for us. Remember, as Michael pointed
out, this is a community supported distro, and only time will tell how
well the community actually will support their distro.

Point is, if we later decide this is not working well, we can always
review the decisions and if decided do the split.

Can we reach an agreement that this is the way to start the distro?



I have one question at your suggestion Thomas.
Mandriva has editions like Mandriva One or Mandriva Free. Will there be 
something different or will Mageia use this as a base?


I would prefer that some proprietary firmware will be available such as 
the WIFI drivers of Intel (iwlwifi) , which is needed by my wireless 
card, without choosing the correct version of Mageia.
These drivers are also available in the kernel right now, so it would be 
a possibility to activate them there by default so newer hardware will 
work correctly.


Daniel

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op dinsdag 30 november 2010 12:04:49 schreef Samuel Verschelde:
> Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit :
> > So, after reading all different opinions here and discussing with
> > founders, here is the idea:
> > 
> > We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
> > debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
> > we wont use the name "restricted" as it was used in MDV commercial
> > products.
> > 
> > Now all of theese medias will have their 5 submedias: release, updates,
> > updates_testing, backports, backports_testing.
> > 
> > That brings us to 30 medias in total :)
> > 
> > The details of the media layout suggestion is also at the end of this
> > mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy
> > 
> > 
> > Now...
> > 
> > We wont blindly import every package from cooker, instead  we'll
> > start off the import with basesystem (as in bootable system with
> > shell access), compiler and rpm tools (and of course their buildtime
> > depencies). When all of that is imported and rebuilt, we have a working
> > buildsystem / base to build from.
> > 
> > Then we to go on with and start importing X, the different
> > DE's and every other package needed to build a full distro.
> > 
> > By doing it this way, we get a clean start, every package rebuilt,
> > and no old/unmaintained stuff in the beginning.
> > 
> > Then as more maintainers join, I guess more packages will be imported
> > from cooker and other sources. And packages can always be requested.
> > 
> > As for those that want the core/extra split:
> > We already tried it with main/contrib split. And I know mdv is now
> > trying to refine what belongs in main or not, but thats for mdv
> > to work through the "problem" as it wont be an easy task.
> > 
> > For us I think the best way for now is to start with this suggested
> > layout, and see if it works well for us. Remember, as Michael pointed
> > out, this is a community supported distro, and only time will tell how
> > well the community actually will support their distro.
> > 
> > Point is, if we later decide this is not working well, we can always
> > review the decisions and if decided do the split.
> > 
> > Can we reach an agreement that this is the way to start the distro?
> 
> OK for me provided support policy matters are not discarded forever but
> only delayed to allow things to start.
> 
> It would be great to start QA Team's organization as soon as possible. I
> don't think we need to wait for the BS and the packages to begin thinking
> about those matters.
> 
> Regards
> 
> Samuel

i agree

Re: [Mageia-dev] Mirror layout, round two

[Sam Bailey]

On Tue, 30 Nov 2010 12:37:42 +0200, Thomas Backlund  wrote:
> Can we reach an agreement that this is the way to start the distro?
> 

I also agree with this structure.

-- 
Sam Bailey

Cyprix Enterprises
Web: cyprix.com.au
Em: cyp...@cyprix.com.au
Mb: 0425 796 308

Re: [Mageia-dev] Mirror layout, round two

[Maarten Vanraes]

Op dinsdag 30 november 2010 13:29:28 schreef Samuel Verschelde:
> > > In Mandriva, you can find many examples of packages in main which are
> > > not supported in reality,
> > > 
> > >  or even maybe simply don't work. You can find also many packages in
> > >  contrib which are
> > > 
> > > perfectly supported, in cooker as in stable releases. You gave me
> > > examples. However I see very rarely security or bugfix updates for
> > > packages in contrib for stable releases (or sometimes they go to
> > > backports), whereas there are many security fixes and bugfixes for
> > > packages in main thanks to Mandriva's security team. There really is a
> > > difference between supported packages and other, although it's far
> > > from perfect.
> > 
> > The difference is mainly that Mandriva has a team of 2 people full time
> > doing the bugfixes and security updates. We do not have them.
> > 
> > So that's not because there is contribs that main got more bugfixes and
> > updates. That's because people are paid to do the work.
> > 
> > And so there is no correlation between "there is updates in main" and
> > "there is a split".
> 
> Yes there is a correlation : there is a team of people working to provide
> quick support for a set of packages. Without a list of supported packages,
> they couldn't focus their work. However please remember that I agreed that
> the split mirror-side is not the only way to achieve such focus.
> 
> Our main disagreement here is you prefer that we have the same level of
> support for any package in the distribution (which probably means very few
> packages in the distribution then) while I'd like many packages in the
> distribution, a subset of which is officially supported. At least, it
> worked well enough so that we could send more than 450 servers with
> Mandriva in French hospitals and use Mandriva at work on workstation.
> 
> Why do I prefer a large package list to a list restricted to
> platinum-supported packages : I can build a system where the critical
> parts are supported, and if I need to add some less supported stuff, I
> still can. We should compare the ratio between packages in main and
> packages in contrib which are actually installed on people's systems. On
> our servers, that would be around 98% coming from main, and less than 2%
> coming from contrib. On my workstation, it would be probably 75% vs 25%.
> Main provides stability and security (regardless of some badly supported
> packages). Contrib provides choice..

I do see a point here.

> > Seeing that everything is equally supported is a sign of a lack of
> > quality ?
> 
> It depends on the amount of available packages and available resources.
> 1 packages *equally supported* with 30 packages, yep, that would be a
> sign of a lack of quality. If there are only 1000 packages, of course,
> this is different. I still prefer the 1000 supported packages + 9000
> use-at-your-own-risk packages.

It is true that it could be viewed as such by people.

> > > Now if there were a list of supported packages, either it would not be
> > > officially supported and the user would know he could use it but maybe
> > > won't have security and bugfix updates, or it is officially supported.
> > > Now take the example above :
> > > - Someone checks if postgresql is supported because if not he'll use
> > > another distribution where it is - It is !
> > > - However the maintainer went away doing his own fork, so he dropped
> > > maintainership. - Someone in QA Team rings a bell : "this supported
> > > package isn't supported anymore, but we promised we would support it
> > > for Mageia 2011 for 2 years from now ! We have to do something !"
> > > - The package team leader, or someone else, relays the warning and
> > > finds someone else to maintain the package, at least for Mageia 2011,
> > > for security and bugfix updates.
> > 
> > Please, I would appreciate that you do not arrange facts just to support
> > your point, or I will seriously have to reconsider answering in the
> > futur.
> > 
> > In the first case :
> > package is not supported, no one step to maintain, we drop -> that's
> > bad.
> > 
> > second case :
> > package is not supported, someone step, we don't drop -> that's good
> > 
> > Why do you make the assumption that someone will step to maintain in 2nd
> > case and not in the first one ?
> > 
> > Just saying "it should be supported because it is on some official list"
> > is not really something that worked that well at Mandriva for the
> > community.
> 
> The way you make a caricature of my arguments is rude here.
> 
> What I'm saying is totally different :
> 
> In the first case :
> - no one steps in to maintain it. We drop it.
> 
> In the second case :
> - no one steps in to maintain it. Because we promised to support it, and
> because there are people who care about that (the QA Team Leader for
> example), we would *try very hard* to find a solution. this is a problem,
> we identify the problem, we try to solve it

Re: [Mageia-dev] Mirror layout, round two

[Renaud MICHEL]

On mardi 30 novembre 2010 at 11:37, Thomas Backlund wrote :
> Can we reach an agreement that this is the way to start the distro?

I agree.

-- 
Renaud Michel

Re: [Mageia-dev] Mirror layout, round two

[Yann Ciret]

Le 30/11/2010 11:37, Thomas Backlund a écrit :
>
> Can we reach an agreement that this is the way to start the distro?
> 
I agree with this proposal.

Regards
Yann

Re: [Mageia-dev] Mirror layout, round two

[Daniel Kreuter]

2010/11/30 Thomas Backlund 

> * core
>  - enabled by default
>  - mirrors must mirror this media to be listed as a mirror
>  - only free/libre stuff as described by FSF / OSI
>  - must be selfcontained
>
> * nonfree
>  - disabled by default, installer will ask to enable it if
>it detects hw that need driver/fw from here
>  - mirrors must mirror this media to be listed as a mirror
>  - contains apps/drivers/firmware that are free to redistribute
>but we dont have redistributable source for
>  - for example: ati/nvidia drivers/firmware, Oracle Java,
>Adobe stuff we might get redistribution permission for
>
> * tainted
>  - disabled by default
>  - mirrors are free to not mirror this media ( ? )
>  - stuff we think we can redistribute, but that may have some
>patent issues or other legal restrictions
>  - what belongs / is allowed here must still be discussed
>
> * debug_core
>  - disabled by default
>  - debug rpms for core
>
> * debug_nonfree
>  - disabled by default
>  - debug rpms for nonfree
>
> * debug_tainted
>  - disabled by default
>  - debug rpms for tainted
>
>
>
> Every media contains the same layout:
>
> * backports
>  - disabled by default
>
> * backports_testing
>  - disabled by default
>
> * release
>  - disabled by default on nonfree, installer will ask to enable
>it if it detects hw that need driver/fw from here
>  - disabled by default on tainted, debug_core, debug_nonfree,
>debug_tainted
>
> * updates
>  - disabled by default on nonfree, installer will ask to enable
>it if it detects hw that need driver/fw from here
>  - disabled by default on tainted, debug_core, debug_nonfree,
>debug_tainted
>
> * updates_testing
>  - disabled by default
>

The Scheme sounds good. One only suggestion from my side, i would enable the
updates once the repositories are enabled.
For Example if I enable the non-free Repos i would like also to get the
Updates for them. or maybe only security fixes and enable the other updates
manually would be ok.

-- 
Mit freundlichen Grüßen

Greetings

Daniel Kreuter

Re: [Mageia-dev] Mirror layout, round two

[Romain d'Alverny]

On Tue, Nov 30, 2010 at 13:29, Samuel Verschelde  wrote:
> What I'm saying is totally different :
>
> In the first case :
> - no one steps in to maintain it. We drop it.
>
> In the second case :
> - no one steps in to maintain it. Because we promised to support it, and 
> because there are people who care about that (the QA Team Leader for 
> example), we would *try very hard* to find a solution. this is a problem, we 
> identify the problem, we try to solve it. Maybe we fail, but at least we try 
> hard, because the package is on the "supported" list.

Ok, it's a degree of support management:
 - first case, dropping is automatic,
 - second case, we turn the red light on and try to organise around
this to find a "best effort" solution.

But, in the second case, relying exclusively on the community, for the
support promise to work, you have to show that you have either some
separate incentive, either a large enough community to grow the
chances for this to happen.

>> another solution : "we do no promises of supporting anything".
>
> This is a solution. Not mine however.

Not promising of something to happen is not a promise of this thing
not to happen.

Such a promise of support is much more sustainable if you have a
clear, identifiable incentive or reason or experience (for the people
you promise to) to keep it. There are differences between:
 * guaranteed,
 * trying very hard,
 * best effort,
 * good will,
 * nothing pretended

support promises.

> Let me present the idea differently. There are 2 levels of support :
>
> - top guaranteed support (a subset of packages) : those are packages your can 
> rely on blindly, they'll be updated in a timely manner. Those are the 
> packages the QA Team puts its limited resources on (doesn't mean the QA Team 
> provides support, but they check that good support is provided). The 
> maintainer is responsible for the package, but the QA Team is vigilant about 
> them.
> - supported packages (every other package) : those are maintained packages, 
> however the QA Team doesn't have to check them. It's up to the maintainer.
> - unsupported packages are dropped.
>
> So everything is supported, but there a special level of support for some 
> critical components.

Just saying, but as packages support is to be distributed, we may as
well have commercial companies step around and manage this kind of
support:
 * within/through Mageia through their employees (so, it matches our
policies, that's the idea),
 * because it matches their activity/interest (they build the
software, they consult/sell/build around it).

To help thinking about that (in the future, because now we have
nothing to track/compare) we need to collect and report relevant data
about packages management experience (supported, not supported, number
of updates, maintainers, time to push an update, etc.) against a first
policy. So we can measure what happens and what can be reasonably
changed/expected in the future.

Romain

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Michael Scherer skrev 30.11.2010 14:23:

Le mardi 30 novembre 2010 à 07:50 -0300, Balcaen John a écrit :

Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit :

So, after reading all different opinions here and discussing with
founders, here is the idea:

We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
we wont use the name "restricted" as it was used in MDV commercial
products.


[...]


We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a working
buildsystem / base to build from.

Are you (not specifically you thomas :p)  going to check again the basesystem
dependencies/requirements, if i remember correctly the basesystem in mandriva is
not anymore a « real » basesystem ?


The explicit goal is to be able to boot, and start bash. Not bash and be
able to do anything useful with it :)
( ok, maybe a script with /dev/tcp to say "hello" on irc ).

So if basesystem as a rpm is not enough, we will import what is needed
to complete it.


or basesystem-minimal :)

--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Anne nicolas skrev 30.11.2010 13:15:

2010/11/30 Thomas Backlund:

So, after reading all different opinions here and discussing with founders,
here is the idea:



For us I think the best way for now is to start with this suggested
layout, and see if it works well for us. Remember, as Michael pointed
out, this is a community supported distro, and only time will tell how
well the community actually will support their distro.

Point is, if we later decide this is not working well, we can always
review the decisions and if decided do the split.

Can we reach an agreement that this is the way to start the distro?



Looks ok for me and the easiest layout we may achieve. Still we will
need to finalize policies about repositories content.



True.

A post on that will follow later today/tomorrow.

--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Samuel Verschelde skrev 30.11.2010 13:04:


Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit :


So, after reading all different opinions here and discussing with
founders, here is the idea:

We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
we wont use the name "restricted" as it was used in MDV commercial products.

Now all of theese medias will have their 5 submedias: release, updates,
updates_testing, backports, backports_testing.

That brings us to 30 medias in total :)

The details of the media layout suggestion is also at the end of this
mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy


Now...

We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a working
buildsystem / base to build from.

Then we to go on with and start importing X, the different
DE's and every other package needed to build a full distro.

By doing it this way, we get a clean start, every package rebuilt,
and no old/unmaintained stuff in the beginning.

Then as more maintainers join, I guess more packages will be imported
from cooker and other sources. And packages can always be requested.

As for those that want the core/extra split:
We already tried it with main/contrib split. And I know mdv is now
trying to refine what belongs in main or not, but thats for mdv
to work through the "problem" as it wont be an easy task.

For us I think the best way for now is to start with this suggested
layout, and see if it works well for us. Remember, as Michael pointed
out, this is a community supported distro, and only time will tell how
well the community actually will support their distro.

Point is, if we later decide this is not working well, we can always
review the decisions and if decided do the split.

Can we reach an agreement that this is the way to start the distro?



OK for me provided support policy matters are not discarded forever but only 
delayed to allow things to start.



It wont be discarded.
We need to list package priority, wich ones must go through QA, and wich 
ones that are subject to maintainer qa & testing



It would be great to start QA Team's organization as soon as possible. I don't 
think we need to wait for the BS and the packages to begin thinking about those 
matters.



Yes, its time to start defining policies around all this and team creation.

--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Balcaen John skrev 30.11.2010 12:50:

Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit :

So, after reading all different opinions here and discussing with
founders, here is the idea:

We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
we wont use the name "restricted" as it was used in MDV commercial
products.


[...]


We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a working
buildsystem / base to build from.

Are you (not specifically you thomas :p)  going to check again the basesystem
dependencies/requirements, if i remember correctly the basesystem in mandriva is
not anymore a « real » basesystem ?



Well,
technically it's basesystem-minimal that should be just that: minimal.
but it will be reviewed as everythng else.


Then we to go on with and start importing X, the different
DE's and every other package needed to build a full distro.

Should not each package imported directly by the maintener here (for the DE),
so he's going to import (hopefully ?) only the real requirements so we'll be
able to drop « more » unused packages maybe?

[...]

Can we reach an agreement that this is the way to start the distro?

Sure (even if i'm not followed for the 2 points before :p )



--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

Jerome Quelin skrev 30.11.2010 12:48:

On 10/11/30 12:37 +0200, Thomas Backlund wrote:

We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a
working buildsystem / base to build from.

Then we to go on with and start importing X, the different
DE's and every other package needed to build a full distro.

By doing it this way, we get a clean start, every package rebuilt,
and no old/unmaintained stuff in the beginning.

Then as more maintainers join, I guess more packages will be imported
from cooker and other sources. And packages can always be requested.


sounds sensible to me.

questions:
- how will the import be done?


It will be done by reviewing every srpm, drop anything mdv 
"owned"/trademarked, and then committed to svn. This is to get a clean 
svn to start from.



- is it up for the maintainer to request it? or only for non-base system
   packages?
- or does the maintainer has a magic command to do?


maintainers will be able to import stuff into svn themselves.
More to follow soon regarding packagers / cleanup work.

We will notify users when we open up the svn so people can start 
reviewing/cleaning packages and commit it to svn


Then a new notification will be sent when we consider BS fully open.


- will submitting a package for rebuild bork the list of maintainer (mdv
   uses the "maintainer = 1st to submit" scheme)


I guess that will be so atleast for now.
This will be refined for packaging teams/maintainer groups...


- do we have an estimated planning with the different steps?



Not yet, there are still some fixes needed to be done on youri to get it 
fully working.


--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Samuel Verschelde]

> > In Mandriva, you can find many examples of packages in main which are not 
> > supported in reality,
> >  or even maybe simply don't work. You can find also many packages in 
> > contrib which are 
> > perfectly supported, in cooker as in stable releases. You gave me examples. 
> > However I 
> > see very rarely security or bugfix updates for packages in contrib for 
> > stable releases 
> > (or sometimes they go to backports), whereas there are many security fixes 
> > and bugfixes 
> > for packages in main thanks to Mandriva's security team. There really is a 
> > difference 
> > between supported packages and other, although it's far from perfect.
> 
> The difference is mainly that Mandriva has a team of 2 people full time
> doing the bugfixes and security updates. We do not have them. 
> 
> So that's not because there is contribs that main got more bugfixes and
> updates. That's because people are paid to do the work.
> 
> And so there is no correlation between "there is updates in main" and
> "there is a split". 

Yes there is a correlation : there is a team of people working to provide quick 
support for a set of packages. Without a list of supported packages, they 
couldn't focus their work. However please remember that I agreed that the split 
mirror-side is not the only way to achieve such focus.

Our main disagreement here is you prefer that we have the same level of support 
for any package in the distribution (which probably means very few packages in 
the distribution then) while I'd like many packages in the distribution, a 
subset of which is officially supported. At least, it worked well enough so 
that we could send more than 450 servers with Mandriva in French hospitals and 
use Mandriva at work on workstation. 

Why do I prefer a large package list to a list restricted to platinum-supported 
packages : I can build a system where the critical parts are supported, and if 
I need to add some less supported stuff, I still can. We should compare the 
ratio between packages in main and packages in contrib which are actually 
installed on people's systems. On our servers, that would be around 98% coming 
from main, and less than 2% coming from contrib. On my workstation, it would be 
probably 75% vs 25%. Main provides stability and security (regardless of some 
badly supported packages). Contrib provides choice..

> Seeing that everything is equally supported is a sign of a lack of
> quality ?

It depends on the amount of available packages and available resources. 1 
packages *equally supported* with 30 packages, yep, that would be a sign of a 
lack of quality. If there are only 1000 packages, of course, this is different. 
I still prefer the 1000 supported packages + 9000 use-at-your-own-risk packages.

> > Now if there were a list of supported packages, either it would not be 
> > officially supported and 
> > the user would know he could use it but maybe won't have security and 
> > bugfix updates, 
> > or it is officially supported. Now take the example above :
> > - Someone checks if postgresql is supported because if not he'll use 
> > another distribution where it is
> > - It is !
> > - However the maintainer went away doing his own fork, so he dropped 
> > maintainership. 
> > - Someone in QA Team rings a bell : "this supported package isn't supported 
> > anymore, 
> > but we promised we would support it for Mageia 2011 for 2 years from now ! 
> > We have 
> > to do something !"
> > - The package team leader, or someone else, relays the warning and finds 
> > someone 
> > else to maintain the package, at least for Mageia 2011, for security and 
> > bugfix 
> > updates.
> 
> Please, I would appreciate that you do not arrange facts just to support
> your point, or I will seriously have to reconsider answering in the
> futur.
> 
> In the first case :
> package is not supported, no one step to maintain, we drop -> that's
> bad.
> 
> second case :
> package is not supported, someone step, we don't drop -> that's good
> 
> Why do you make the assumption that someone will step to maintain in 2nd
> case and not in the first one ? 
> 
> Just saying "it should be supported because it is on some official list"
> is not really something that worked that well at Mandriva for the
> community. 

The way you make a caricature of my arguments is rude here.

What I'm saying is totally different : 

In the first case :
- no one steps in to maintain it. We drop it.

In the second case :
- no one steps in to maintain it. Because we promised to support it, and 
because there are people who care about that (the QA Team Leader for example), 
we would *try very hard* to find a solution. this is a problem, we identify the 
problem, we try to solve it. Maybe we fail, but at least we try hard, because 
the package is on the "supported" list. In my example I supposed we find a 
solution, because I suppose that we find it. If I were that kind of "person who 
cares", I'm sure I would find someone. Of cours

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le mardi 30 novembre 2010 à 07:50 -0300, Balcaen John a écrit :
> Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit :
> > So, after reading all different opinions here and discussing with
> > founders, here is the idea:
> > 
> > We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
> > debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
> > we wont use the name "restricted" as it was used in MDV commercial
> > products.
> > 
> [...]
> > 
> > We wont blindly import every package from cooker, instead  we'll
> > start off the import with basesystem (as in bootable system with
> > shell access), compiler and rpm tools (and of course their buildtime
> > depencies). When all of that is imported and rebuilt, we have a working
> > buildsystem / base to build from.
> Are you (not specifically you thomas :p)  going to check again the basesystem 
> dependencies/requirements, if i remember correctly the basesystem in mandriva 
> is 
> not anymore a « real » basesystem ?

The explicit goal is to be able to boot, and start bash. Not bash and be
able to do anything useful with it :) 
( ok, maybe a script with /dev/tcp to say "hello" on irc ).

So if basesystem as a rpm is not enough, we will import what is needed
to complete it.

> > Then we to go on with and start importing X, the different
> > DE's and every other package needed to build a full distro.
> Should not each package imported directly by the maintener here (for the DE),
> so he's going to import (hopefully ?) only the real requirements so we'll be 
> able to drop « more » unused packages maybe?

Yes, but we do have some issues, ie, we need to import X and the other
layers upon which kde, gnome, xfce are built upon. And so we need to do
the import in the proper order.

And we should make sure that someone take care of theses packages before
uploading. But this would likely be a topic for the packaging team ( ie,
comaintainenance, individual maintainance ), that should be started soon
(tm)

-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Anne nicolas]

2010/11/30 Thomas Backlund :
> So, after reading all different opinions here and discussing with founders,
> here is the idea:

> For us I think the best way for now is to start with this suggested
> layout, and see if it works well for us. Remember, as Michael pointed
> out, this is a community supported distro, and only time will tell how
> well the community actually will support their distro.
>
> Point is, if we later decide this is not working well, we can always
> review the decisions and if decided do the split.
>
> Can we reach an agreement that this is the way to start the distro?


Looks ok for me and the easiest layout we may achieve. Still we will
need to finalize policies about repositories content.




-- 
Anne
http://www.mageia.org

Re: [Mageia-dev] Mirror layout, round two

[Samuel Verschelde]

Le mardi 30 novembre 2010 11:37:42, Thomas Backlund a écrit :
> 
> So, after reading all different opinions here and discussing with 
> founders, here is the idea:
> 
> We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
> debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
> we wont use the name "restricted" as it was used in MDV commercial products.
> 
> Now all of theese medias will have their 5 submedias: release, updates,
> updates_testing, backports, backports_testing.
> 
> That brings us to 30 medias in total :)
> 
> The details of the media layout suggestion is also at the end of this
> mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy
> 
> 
> Now...
> 
> We wont blindly import every package from cooker, instead  we'll
> start off the import with basesystem (as in bootable system with
> shell access), compiler and rpm tools (and of course their buildtime
> depencies). When all of that is imported and rebuilt, we have a working 
> buildsystem / base to build from.
> 
> Then we to go on with and start importing X, the different
> DE's and every other package needed to build a full distro.
> 
> By doing it this way, we get a clean start, every package rebuilt,
> and no old/unmaintained stuff in the beginning.
> 
> Then as more maintainers join, I guess more packages will be imported
> from cooker and other sources. And packages can always be requested.
> 
> As for those that want the core/extra split:
> We already tried it with main/contrib split. And I know mdv is now
> trying to refine what belongs in main or not, but thats for mdv
> to work through the "problem" as it wont be an easy task.
> 
> For us I think the best way for now is to start with this suggested
> layout, and see if it works well for us. Remember, as Michael pointed
> out, this is a community supported distro, and only time will tell how
> well the community actually will support their distro.
> 
> Point is, if we later decide this is not working well, we can always
> review the decisions and if decided do the split.
> 
> Can we reach an agreement that this is the way to start the distro?
> 

OK for me provided support policy matters are not discarded forever but only 
delayed to allow things to start.

It would be great to start QA Team's organization as soon as possible. I don't 
think we need to wait for the BS and the packages to begin thinking about those 
matters.

Regards

Samuel

Re: [Mageia-dev] Mirror layout, round two

[nicolas vigier]

On Tue, 30 Nov 2010, Thomas Backlund wrote:

> So, after reading all different opinions here and discussing with founders, 
> here is the idea:
>
> We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
> debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
> we wont use the name "restricted" as it was used in MDV commercial products.
>
> Now all of theese medias will have their 5 submedias: release, updates,
> updates_testing, backports, backports_testing.
>
> That brings us to 30 medias in total :)
>
> The details of the media layout suggestion is also at the end of this
> mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy
>
> [...]
> Can we reach an agreement that this is the way to start the distro?

I agree with this proposal.

Re: [Mageia-dev] Mirror layout, round two

[Romain d'Alverny]

On Tue, Nov 30, 2010 at 11:37, Thomas Backlund  wrote:
> So, after reading all different opinions here and discussing with founders,
> here is the idea:
> [...]
> Can we reach an agreement that this is the way to start the distro?

Looks good, yes.

Romain

Re: [Mageia-dev] Mirror layout, round two

[Balcaen John]

Le mardi 30 novembre 2010 07:37:42, Thomas Backlund a écrit :
> So, after reading all different opinions here and discussing with
> founders, here is the idea:
> 
> We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
> debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
> we wont use the name "restricted" as it was used in MDV commercial
> products.
> 
[...]
> 
> We wont blindly import every package from cooker, instead  we'll
> start off the import with basesystem (as in bootable system with
> shell access), compiler and rpm tools (and of course their buildtime
> depencies). When all of that is imported and rebuilt, we have a working
> buildsystem / base to build from.
Are you (not specifically you thomas :p)  going to check again the basesystem 
dependencies/requirements, if i remember correctly the basesystem in mandriva 
is 
not anymore a « real » basesystem ?

> Then we to go on with and start importing X, the different
> DE's and every other package needed to build a full distro.
Should not each package imported directly by the maintener here (for the DE),
so he's going to import (hopefully ?) only the real requirements so we'll be 
able to drop « more » unused packages maybe?

[...]
> Can we reach an agreement that this is the way to start the distro?
Sure (even if i'm not followed for the 2 points before :p )

Regards,

-- 
Balcaen John
IRC: mikala on freenode.org
XMPP: mik...@jabber.littleboboy.net

Re: [Mageia-dev] Mirror layout, round two

[Jerome Quelin]

On 10/11/30 12:37 +0200, Thomas Backlund wrote:
> We wont blindly import every package from cooker, instead  we'll
> start off the import with basesystem (as in bootable system with
> shell access), compiler and rpm tools (and of course their buildtime
> depencies). When all of that is imported and rebuilt, we have a
> working buildsystem / base to build from.
> 
> Then we to go on with and start importing X, the different
> DE's and every other package needed to build a full distro.
> 
> By doing it this way, we get a clean start, every package rebuilt,
> and no old/unmaintained stuff in the beginning.
> 
> Then as more maintainers join, I guess more packages will be imported
> from cooker and other sources. And packages can always be requested.

sounds sensible to me.

questions:
- how will the import be done?
- is it up for the maintainer to request it? or only for non-base system
  packages?
- or does the maintainer has a magic command to do?
- will submitting a package for rebuild bork the list of maintainer (mdv
  uses the "maintainer = 1st to submit" scheme)
- do we have an estimated planning with the different steps?

jérôme 
-- 
jque...@gmail.com

Re: [Mageia-dev] Mirror layout, round two

[Thomas Backlund]

So, after reading all different opinions here and discussing with 
founders, here is the idea:


We start of with  3 medias: core, nonfree, tainted and 3 debug medias:
debug_core, debug_nonfree, debug_tainted. In order to avoid confusion,
we wont use the name "restricted" as it was used in MDV commercial products.

Now all of theese medias will have their 5 submedias: release, updates,
updates_testing, backports, backports_testing.

That brings us to 30 medias in total :)

The details of the media layout suggestion is also at the end of this
mail, and at: http://mageia.org/wiki/doku.php?id=mirrors_policy


Now...

We wont blindly import every package from cooker, instead  we'll
start off the import with basesystem (as in bootable system with
shell access), compiler and rpm tools (and of course their buildtime
depencies). When all of that is imported and rebuilt, we have a working 
buildsystem / base to build from.


Then we to go on with and start importing X, the different
DE's and every other package needed to build a full distro.

By doing it this way, we get a clean start, every package rebuilt,
and no old/unmaintained stuff in the beginning.

Then as more maintainers join, I guess more packages will be imported
from cooker and other sources. And packages can always be requested.

As for those that want the core/extra split:
We already tried it with main/contrib split. And I know mdv is now
trying to refine what belongs in main or not, but thats for mdv
to work through the "problem" as it wont be an easy task.

For us I think the best way for now is to start with this suggested
layout, and see if it works well for us. Remember, as Michael pointed
out, this is a community supported distro, and only time will tell how
well the community actually will support their distro.

Point is, if we later decide this is not working well, we can always
review the decisions and if decided do the split.

Can we reach an agreement that this is the way to start the distro?



and for refernece: The suggested layout for is:

* core
  - enabled by default
  - mirrors must mirror this media to be listed as a mirror
  - only free/libre stuff as described by FSF / OSI
  - must be selfcontained

* nonfree
  - disabled by default, installer will ask to enable it if
it detects hw that need driver/fw from here
  - mirrors must mirror this media to be listed as a mirror
  - contains apps/drivers/firmware that are free to redistribute
but we dont have redistributable source for
  - for example: ati/nvidia drivers/firmware, Oracle Java,
Adobe stuff we might get redistribution permission for

* tainted
  - disabled by default
  - mirrors are free to not mirror this media ( ? )
  - stuff we think we can redistribute, but that may have some
patent issues or other legal restrictions
  - what belongs / is allowed here must still be discussed

* debug_core
  - disabled by default
  - debug rpms for core

* debug_nonfree
  - disabled by default
  - debug rpms for nonfree

* debug_tainted
  - disabled by default
  - debug rpms for tainted



Every media contains the same layout:

* backports
  - disabled by default

* backports_testing
  - disabled by default

* release
  - disabled by default on nonfree, installer will ask to enable
it if it detects hw that need driver/fw from here
  - disabled by default on tainted, debug_core, debug_nonfree,
debug_tainted

* updates
  - disabled by default on nonfree, installer will ask to enable
it if it detects hw that need driver/fw from here
  - disabled by default on tainted, debug_core, debug_nonfree,
debug_tainted

* updates_testing
  - disabled by default

--
Thomas

Re: [Mageia-dev] Mirror layout, round two

[Ahmad Samir]

On 30 November 2010 07:29, andre999  wrote:
> Michael Scherer a écrit :
>>
>> Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :
>>
>>>
>>> Yann Ciret a écrit :
>>>
>>>

 I dislike the main/contrib separation in some case.
 The first example is with Mozilla Thunderbird packages. Some extension
 packages are in contrib. So each time thunderbird received security
 update, the update cannot be installed because of non automatically
 rebuild of his contrib package. And each time I see a bug report of user
 asking a manual rebuilt. With only one core media, this situation will
 disapear (I hope).


>>>
>>> Unlikely.  This problem is not at all related to separate repositories.
>>>
>>
>> It is. It is exactly related to the fact that thunderbird is supported,
>> and that extension are not despites depending on it.
>>
>
> In this case it is evident that you don't understand how extensions work
> with mozilla products.
> Thunderbird will function correctly with no
> extensions installed.  So why should any extension block the update of
> Thunderbird ?

So the user can simply uninstall that extension and update to new
thunderbird? the user can do this only if he doesn't need that
extension, only if it doesn't offer features he wants to use. That's
an invalid argument, if he doesn't need that extension why does he
have it on his system??

The rationale is/was that mozilla code breaks/broke ABI, so it was
agreed that extensions are rebuilt for both firefox and thunderbird
respective new versions.

We will look into that with upstream, so that if a rebuild isn't
needed, then all the better for us (packagers). But until that
happens, they will be rebuilt. A 1-2 day delay isn't too much for
users.

The more pressing issue is, what does this have to do with the topic
at hand "Mirrors layout, round two" ?? this discussion is deviating
too much, to the extent it's becoming bloated...

> Additionally, modules installed will continue to work as long as the major
> version doesn't change.  (Actually slightly more complicated.)
> In some cases one won't be able to newly install a module because a config
> file inside the module - equivalent to the spec file in rpm packages -
> hasn't been updated for compatible versions.  (In fact, the versions were
> probably improperly specified.)  But installed modules will continue to
> function.
> It is possible that the packager did not realise this - or for whatever
> reason did not properly set up a spec file - but this issue has nothing at
> all to do with separate sets of repositories.

Speaking abstractly without examples in this case is just that,
"speaking". Give us an example of such a case (if any) in a spec file
so that it can be fixed.

>
>> That precisely because we tell "security and bugfixes occurs only on
>> main" that contribs got broken, since the security team do not care to
>> not break contribs packages.
>>
>
> The crux of this problem is that core (in the general sense) packages are
> dependant on packages that are not recognized as core.
> That again has nothing to do with repositories as such.

I agree with Michael here, doing sec fixes isn't hard (once one gets
used to it), just time consuming, and it should be done for all
packages in the "official" repos; it's true that GPL gives no
guarantees what so ever, just it's a moral obligation for people
involved in the FOSS world to support users as best they can.

Users do not differentiate between main/contrib, there's a package
they install it, I don't think they look from which repo it comes
from.

>
>>> Rather that one package was updated, and an optional installed module
>>> was not.
>>> The fact that the module is optional is the key point.
>>> The installer should be flexible enough to give a warning in this case,
>>> and ask if you wish to continue the installation.
>>>
>>
>> So basically, you want a --nodeps ?
>> If there is a requires, there is usually a good reason. Engineering is
>> not randomly adding line to a file until it work.
>>
>
> How about better configured spec files ?
> A better definition (in general) of core packages ?
> A focus on ensuring that core packages are maintained ?
> Basically my idea behind a core sandbox.
> But if you have a better idea ...
>

Again, give us an example of a spec file that needs "better"
configuration, otherwise you're theorising.

> Just remember, eliminating a supported core breaks the sandbox.
> So removing repositories does have secondary effects.
> And they should be seriously considered and discussed by those proposing to
> remove the repositories.
>
>>> As well, in the case of Thunderbird, it is almost certain that the
>>> installed module was in fact compatible with newer version of
>>> Thunderbird.  (A security problem may directly impact Thunderbird or the
>>> module, but highly unlikely both packages.)
>>> Rpm tags should have been set so that Thunderbird would recognize that
>>> the module was appropriate 

Re: [Mageia-dev] Mirror layout, round two

[Wolfgang Bornath]

I think this whole question is not done with an easy answer. It can
also not be ssen in a black/white mode. I see the clear insight of
Michael's suggestion which is a black/white point of view. Not
maintained? Kick it out (well, not "out" but into the ante-room). But
I also see the reality from the user's POV. As for technical skilled
or experienced users (including server admins) the main question is
that those packages which are available should work and be maintained.
Period.
But there is also the vast group of the "unwashed masses" including
those we want to attract to Mageia. Many of those do look at the sheer
number of packages (like, "I'd rather switch to Foo Linux which offers
2 million packages while Mageia only offers 5,000"). Yes, I know, it's
rather dumb and those users are the first to complain about some
missing icon. But they are a large part of the users out there.

So we have to find a middle way between the pure and the ugly. How to
find that, I don't know, this is far beyond my knowledge. I only
wanted to comment on the "philosophical" side of the problem. For me
as a mostly non-technical guy the best solution would be the "flag"
solution. Forget the main/contrib split and just flag unmaintained
rpms so that the user sees it in the GUI. How to accomplish that on
the CLI with urpmi I don't know. Then people who are security- aware
like server admins can easily avoid unmaintained packages or open a
request in Bugzilla which **may** inspire somebody to pick up the poor
unmaintained package.

One comment on the mirror maintainer part of the story:
I was mentioned by Michael several times as an example of a certain
kind of mirror maintainers. Yes, ressources are tight but not that
tight. As I understood the "official mirror" as suggested by Olivier
was about to fill up to 700 GB during the next 3 years - given that we
will have 2 releases per year. Most of the official mirrors of
Mandriva do not provide 6 releases, moreso when the life cycle of a
release is less than 2 years.
So, a realistic size woul be more like 450-500 GB at the most which is
easily done with today's hardware. This is not a problem. Time is not
a problem either for such people like me. The only problem I still see
from the mirror maintainer's side is the way to deal with "tainted"
packages wrt the mirrorlist (as already mentioned).

-- 
wobo

Re: [Mageia-dev] Mirror layout, round two

[Jerome Quelin]

On 10/11/30 00:29 -0500, andre999 wrote:
> My point is that a sandbox will facilitate proper support.  Which
> would be facilitated by keeping the 2 sets of free repositories.
> And restricting what should be considered core.
> We both know that Mandriva is moving in that direction.  Evidently
> recognising that they weren't restrictive enough in the past.
> 
> Your focus is removing 1 of these repository sets, and thus the sandbox.
> But I don't see your solution for giving priority to maintaining
> core packages ?
> These factors are undeniably linked.

no they're not. the problem is the lack of maintainers.

your answer: "it is in core media, so people will acknowledge it's
important and will step in".

guess what? they won't. history suggests that. the following too:
https://maint.mandriva.com/listpkgs.php?owner=1&media=1&scount=1000

you will answer that those packages should not be in main, but in extra
since they aren't really "core" (your definition of "core"). but most of
them are in main because of buildrequires dependencies. so what to do?

and by having 2 medias, you are increasing the work of potential
packagers. and their frustration. trust me on this - been there, done
that.

now michael's answer: "broken? no one steps in? removed from mageia."
does it suck? yes. as a user, i prefer having lots of packages
available, since it means that i won't have to package it myself if/when
i need the tool. 

but it has a great virtue: it passes reality check. less packages means
less work for the small pool of maintainer. and it may force people to
step in ('cause there's an impacting action that will happen otherwise)
rather than handwaving. which increases the pool of maintainer.

so i'm in favour of misc's proposal.
jérôme 
-- 
jque...@gmail.com

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Michael Scherer a écrit :

Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :
   

Yann Ciret a écrit :

 

I dislike the main/contrib separation in some case.
The first example is with Mozilla Thunderbird packages. Some extension
packages are in contrib. So each time thunderbird received security
update, the update cannot be installed because of non automatically
rebuild of his contrib package. And each time I see a bug report of user
asking a manual rebuilt. With only one core media, this situation will
disapear (I hope).

   

Unlikely.  This problem is not at all related to separate repositories.
 

It is. It is exactly related to the fact that thunderbird is supported,
and that extension are not despites depending on it.
   
In this case it is evident that you don't understand how extensions work 
with mozilla products.  Thunderbird will function correctly with no 
extensions installed.  So why should any extension block the update of 
Thunderbird ?
Additionally, modules installed will continue to work as long as the 
major version doesn't change.  (Actually slightly more complicated.)
In some cases one won't be able to newly install a module because a 
config file inside the module - equivalent to the spec file in rpm 
packages - hasn't been updated for compatible versions.  (In fact, the 
versions were probably improperly specified.)  But installed modules 
will continue to function.
It is possible that the packager did not realise this - or for whatever 
reason did not properly set up a spec file - but this issue has nothing 
at all to do with separate sets of repositories.



That precisely because we tell "security and bugfixes occurs only on
main" that contribs got broken, since the security team do not care to
not break contribs packages.
   
The crux of this problem is that core (in the general sense) packages 
are dependant on packages that are not recognized as core.

That again has nothing to do with repositories as such.


Rather that one package was updated, and an optional installed module
was not.
The fact that the module is optional is the key point.
The installer should be flexible enough to give a warning in this case,
and ask if you wish to continue the installation.
 

So basically, you want a --nodeps ?
If there is a requires, there is usually a good reason. Engineering is
not randomly adding line to a file until it work.
   

How about better configured spec files ?
A better definition (in general) of core packages ?
A focus on ensuring that core packages are maintained ?
Basically my idea behind a core sandbox.
But if you have a better idea ...

Just remember, eliminating a supported core breaks the sandbox.
So removing repositories does have secondary effects.
And they should be seriously considered and discussed by those proposing 
to remove the repositories.



As well, in the case of Thunderbird, it is almost certain that the
installed module was in fact compatible with newer version of
Thunderbird.  (A security problem may directly impact Thunderbird or the
module, but highly unlikely both packages.)
Rpm tags should have been set so that Thunderbird would recognize that
the module was appropriate in the newer version.
 

No. If there is stricter dependency, it is precisely because there is no
guarantee of any kind of ABI between thunderbird versions. The same goes
for firefox.
   
Overly restrictive compatibility specification is a very a common error 
in Mozilla extension packaging.  (It's mentioned in their development 
guides.)

But the rpm packager should be knowledgable enough to recognize it.
But such errors do happen.

So in sum, this was probably only a packaging problem.  Whatever the
repository.
 

No. Not at all.
The problem is linked to the difference of support between main and
contribs.
   


In this case, it is inappropriate packaging.
Other cases could be a difference of support.

There is no reason that extensions should ever block the upgrade of 
Thunderbird, unless when one passes from one major version to another.
In that case, the extension will have to be rewritten, a development 
function.

(That has only happened a few times since the beginning of Mozilla.)

The essence of our disagreement seems to be how to ensure that core 
packages are properly supported.
My point is that a sandbox will facilitate proper support.  Which would 
be facilitated by keeping the 2 sets of free repositories.  And 
restricting what should be considered core.
We both know that Mandriva is moving in that direction.  Evidently 
recognising that they weren't restrictive enough in the past.


Your focus is removing 1 of these repository sets, and thus the sandbox.
But I don't see your solution for giving priority to maintaining core 
packages ?

These factors are undeniably linked.

By the way, I'm very willing to be convinced.  Just give me the logic.

regards

- André

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 29 novembre 2010 à 20:06 -0500, andre999 a écrit :
> nicolas vigier a écrit :
> > On Mon, 29 Nov 2010, andre999 wrote:
> >
> >
> >> The supposed advantages of discarding a set of repositories over having an
> >> obvious sandbox aren't clear.
> >>  
> > I think misc already explained it clearly in this mail :
> > https://www.mageia.org/pipermail/mageia-dev/20101129/001503.html
> >
> > If you disagree, you can reply to his email. But don't keep repeating
> > that there's not clear drawbacks, that the cost of creating new
> > repositories is almost nil and this kind of thing if you don't have
> > any real arguments.
> >
> >
> Well you can insist that the mentioned drawbacks are significant, but if 
> you follow my arguments, you will see that I explain why I don't believe 
> they are.

I would be more inclined to trust boklm's technical judgement, who is in
charge of setting up the Mageia BS, who proposed several improvement on
it ( uid splitting, etc ), who worked since several years as a packager,
build system and cluster admin at Mandriva.

> And I'm not the only one with this point of view.

Not being alone doesn't mean that's a good idea. For example
all lemmings that think that mass suicide are not alone.

> It is useful to take a global point of view, with all the factors involved.

Well, yes, and we think we did it. You know, we worked on a distribution
since some time. So we have a global point of view. 

> As well, some supposed costs make assumptions that we will do things the 
> same way as Mandriva.  But I have presented a different way of doing 
> things, which wouldn't necessarily entail such costs.

You have presented exactly the same system as Mandriva. That's not what
I call "different".


> So you like to say that I don't have any real arguments.
> Well I'd say that much of misc's arguments in that post don't hold if we 
> do things in a different way. 
> [..]
>  In other posts, misc's arguments conform 
> with my point of view.

What you achieved is the demonstration about the emptiness of saying
"misc's argument" without refering to the arguments you are speaking of.
 
Next time, can you be more precise and say "$FOO do not hold because
of .., while $BAR is in favor of my idea" with $FOO and $BAR being the
actual arguments so we can at least understand ?

I would also request you to refrain from using my nickname for doing
such name dropping in the future.

> By the way, I'm *not* proposing creating *new* repositories.  I'm 
> proposing *not removing* some existing repositories, and doing certain 
> things in a different way.

We propose to remove existing repositories precisely because we know
what problem this create to keep the existing system. And we know
because we faced them. This is based on our experiences as long time
packagers and distribution admins. 
 
-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 29 novembre 2010 à 15:56 -0500, andre999 a écrit :

> Isn't choice part of 
> what Linux is supposed to be about ?

No. 

That's freedom of the source code, not choice. Reread either Gnu
manifesto, or Linus Torvalds biography.

And so, you are free to use the source code for what you want, period.

> I think that one advantage of using the mirror structure is that it is a 
> sandbox that makes it clear to everyone (packagers, maintainers, current 
> and potential users, qa, etc) what is officially supported and what is not.
> It has largely worked for Mandriva.

No.
See the various example I gave. You are not even a packager, how can you
speak for them by telling "it is clear to everyone" when several
packagers have expressed that it is a mess ?


> What didn't work is
> (1) the lack of a well-defined and applied criteria for what is to be 
> officially supported, and
>
> (2) the lack of a clear applied policy and strategies of how to deal 
> with possible dependancies of supported packages on non-supported packages.

The policy was always clear. Main is self contained. This was enforced
in 2006 with the use of iurt to build rpm.

Every policy of mixing package from main or contribs would be too
complex from a technical point of view, unsafe from a security point of
view, incomplete from a QA point of view and a blatant lie for people
telling "this software is supported" while it depend on unsupported
components.

> Without this sandbox, packagers are much less likely to do what is 
> necessary to ensure that supported packages are fully supported, 
> including dependancies.  Including getting the necessary support from 
> others to achieve this.
> Support is much more than an official maintainer.
>
> The supposed advantages of discarding a set of repositories over having 
> an obvious sandbox aren't clear.
>
> Another mechanism allowing the end-user to select only supported 
> packages will be at least as complex.
> There will be no difference for mirrors.  (Same size, just a few extra 
> directories.)
> Packagers can't help but notice if accessing dependancies outside the 
> sandbox.

Are you sure you have a idea on how packages are built at Mandriva or on
various distributions ?
Because right now, what you say doesn't make sense to me, and I can
guarantee that I know how it work.

> > [ stormi's example ]
> Excellent example.
> This also points to the advantage of a mirror-based categorization.  
> Support should only change by release, not stop somewhere in between.  

This is distribution made by volunteers. If no one want to do the job,
then the job will not be done. So if no one want to maintain something,
what should be done ?

And if someone want to do the job, the only thing he has to do is to
become maintainer.

So no, the example is not "excellent". It is based on a single important
change : "someone will step to maintain it", while in my example, I
precisely pre-supposed the contrary.

So the comparaison is totally invalid and misleading.


-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 29 novembre 2010 à 20:54 -0500, andre999 a écrit :
> Yann Ciret a écrit :
>   
> > I dislike the main/contrib separation in some case.
> > The first example is with Mozilla Thunderbird packages. Some extension
> > packages are in contrib. So each time thunderbird received security
> > update, the update cannot be installed because of non automatically
> > rebuild of his contrib package. And each time I see a bug report of user
> > asking a manual rebuilt. With only one core media, this situation will
> > disapear (I hope).
> >
> Unlikely.  This problem is not at all related to separate repositories.

It is. It is exactly related to the fact that thunderbird is supported,
and that extension are not despites depending on it.

That precisely because we tell "security and bugfixes occurs only on
main" that contribs got broken, since the security team do not care to
not break contribs packages.

> Rather that one package was updated, and an optional installed module 
> was not.
> The fact that the module is optional is the key point.
> The installer should be flexible enough to give a warning in this case, 
> and ask if you wish to continue the installation.

So basically, you want a --nodeps ? 
If there is a requires, there is usually a good reason. Engineering is
not randomly adding line to a file until it work.

> As well, in the case of Thunderbird, it is almost certain that the 
> installed module was in fact compatible with newer version of 
> Thunderbird.  (A security problem may directly impact Thunderbird or the 
> module, but highly unlikely both packages.)
> Rpm tags should have been set so that Thunderbird would recognize that 
> the module was appropriate in the newer version.

No. If there is stricter dependency, it is precisely because there is no
guarantee of any kind of ABI between thunderbird versions. The same goes
for firefox.

> So in sum, this was probably only a packaging problem.  Whatever the 
> repository.

No. Not at all. 
The problem is linked to the difference of support between main and
contribs.
-- 
Michael Scherer

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 29 novembre 2010 à 18:29 +0100, Samuel Verschelde a écrit :
> Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit :
> > 
> > So either the package is supported, and we keep, or it is not, and then
> > why should we keep it ?
> 
> Because it works, at least partially.

Having it work 'partially" is not sufficient. There is lots of things
that would work "partially", but if we want to have people to feel
confident in the distribution, we shouldn't have "partially working
packages", some with "security flaw" and hope that users will understand
the difference. Some of them will not, and shouldn't have to.

Partially working packages take time from packagers, space on mirrors,
space in hdlist size on everybody. They give bad reputation to our work.

>  Because it has users. 

If no one care to even try to update it ( not even a prospective
packager ), then it is likely not much popular. I cannot really think
that a package can have lots of users, and yet none of them being
technical enough to step and become a packager, or to convince someone
from taking it.
That would just be statistically improbable. 

> It may have flaws, 
> it may not have the latest security fixes, it may just be supported but only 
> updated 
> once a year... That's not a reason for dropping it.

Being insecure is a reason to drop it. If no one is willing to take time
to simply dig and apply security patchs, and later fix then we should
not let people install it. 

>  That's why distiction between 
> officially supported and not officially supported is useful. There are 
> working 
> packages, seldom updated, which don't deserve to be dropped, but which can't 
> be 
> advertised as officially supported, and that's understandable. The world is 
> not 
> either black or white, there are many shades of grey, and that's particularly 
> true for packages in a linux distribution.
>
> According to what you said, it looks like there will be only 2 kinds of 
> packages :
> - in the distribution (which would be equal to "supported")
> - not in the distribution

You said that you want to have confidence in the distro capacity to
maintain rpms. So there shouldn't be something saying "here is packages
that we cannot support because there isn't enough people to do it". 

If we let people install insecure/buggy packages with just a click, they
will sooner or later. We will just increase the number of those that
complain about unmaintained packages and start to have a reputation of
not having security fixes on everything.

> In Mandriva, you can find many examples of packages in main which are not 
> supported in reality,
>  or even maybe simply don't work. You can find also many packages in contrib 
> which are 
> perfectly supported, in cooker as in stable releases. You gave me examples. 
> However I 
> see very rarely security or bugfix updates for packages in contrib for stable 
> releases 
> (or sometimes they go to backports), whereas there are many security fixes 
> and bugfixes 
> for packages in main thanks to Mandriva's security team. There really is a 
> difference 
> between supported packages and other, although it's far from perfect.

The difference is mainly that Mandriva has a team of 2 people full time
doing the bugfixes and security updates. We do not have them. 

So that's not because there is contribs that main got more bugfixes and
updates. That's because people are paid to do the work.

And so there is no correlation between "there is updates in main" and
"there is a split". 

> If there's no difference in term of security updates between php and a random 
> maintained 
> game, then I won't be very confident in the distribution's quality. 

In fact, I fail to see or understand what you mean, even after trying
very hard. 

Seeing that everything is equally supported is a sign of a lack of
quality ?

In this case, you would likely have problem with gentoo, debian or
fedora security policy :/

> Let's say I want to install php on the stable Mageia 2011, will it be 
> supported for 
> security fixes and bugfixes ? For how long ? Are security fixes applied as 
> soon as possible ?
> [ snip ]

If you really want to discuss of support policy, then a new thread
should be started. Or this thread will be more messy. The goal is to
speak about mirror layout, as written in the subject.

> > > and the decision to merge core and extras must be taken together 
> > > with decisions on QA and support processes, 
> > 
> > Well, everything should be supported or dropped, that's all. Easy, done
> > by every other distros out there except those that place a artificial
> > separation. If there is a security bug opened and no one act on it after
> > a time, let's drop the package. If there is a severe bug and no one act,
> > the same, let's drop it.
> > 
> > If people want to resurrect a rpm, they can, there is a svn for that.
> 
> This is the most terrible thing I read so far. 
> I already tried to answer it earlier in this message, 
> h

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Michael Scherer a écrit :

Le lundi 29 novembre 2010 à 14:28 +0100, Olivier Thauvin a écrit :
   

* Thomas Backlund (t...@iki.fi) wrote:
 

Olivier Thauvin skrev 29.11.2010 03:06:
   

* Thomas Backlund (t...@iki.fi) wrote:
I can't agree with the "mirrors are free to not mirror this media",
three reasons:
1) I don't see an easy and safe way for mirrors to exclude a media (a
directory + hdlist in media/media_info) in each distribution,
 

Thats easy, just use --exclude-from

On my local mirror I exclude the debug stuff
so I use --exclude-from=excclude.lst

# cat exclude.lst
i586/media/*debug*
i586/media/media_info/*debug*
x86_64/media/*debug*
x86_64/media/media_info/*debug*

And thats all needed.
We can even provide this exclude file ourselves on the mirrors so we
know its correct and if we change the mirror layout, we update the file.
   

Completly not realist on mirror admin side.

You really have to remember that first mirror admin job is not maintains
mirrors. They have often hundred of users on their back waiting for
fixes.

When such will go wrong, nobody will be able to check and fix.
 

The issue is that we have 2 types of mirror admins :

- there is some of them who are hobbyist/enthusiasts, that use their own
server for that, and that mirror only one or 2 distros, and that may not
do it for their job or as part of their job. I think for example
Wolfgang would be in this category. They want to help us, but they may
have slightly limited ressources. But they can have time to tweak the
mirroring to fit what they can offer to us.

- on the other end of the spectrum, we have people who manage lots of
mirrors, with more bandwidth and bigger servers, more , but maybe not
more time. Ie people that does it as part of their job, with the
associate increase of ressources and work that come with a job.

So admins that are more of the type 1 are likely ok with following
lists, giving input, tweaking rsync scripts, etc. They are the one that
could help us by giving stats or stuff like that, because they have the
time. But that's also people who may have more trouble ( because of
lesser ressources )

Type 2 would prefer to not have too much to do because they may have
better thing to do. Ideally, they set up and do not touch for the 10
next year and that's ok.

So we need to take in account this divide.
   

Good points.

We can't have just one type or the other, but in both case, a simpler
mirroring process will benefit to everybody.

   

- André

Re: [Mageia-dev] Mirror layout, round two

[andre999]

Yann Ciret a écrit :

Le 29/11/2010 15:44, Dexter Morgan a écrit :
   

On Mon, Nov 29, 2010 at 3:10 PM, Jerome Quelin  wrote:
 

On 10/11/28 22:12 +0200, Thomas Backlund wrote:
   

So the mirror medias accordingly to all comments so far would be a simple:

* core
   - enabled by default
   - mirrors must mirror this media to be listed as a mirror
   - only GPL stuff
   - must be selfcontained
 

I liked the main/contrib separation.
Main was officially supported + sec updates and with only core this
means a lot more work/support.

 

I dislike the main/contrib separation in some case.
The first example is with Mozilla Thunderbird packages. Some extension
packages are in contrib. So each time thunderbird received security
update, the update cannot be installed because of non automatically
rebuild of his contrib package. And each time I see a bug report of user
asking a manual rebuilt. With only one core media, this situation will
disapear (I hope).
   

Unlikely.  This problem is not at all related to separate repositories.

Rather that one package was updated, and an optional installed module 
was not.

The fact that the module is optional is the key point.
The installer should be flexible enough to give a warning in this case, 
and ask if you wish to continue the installation.
As well, in the case of Thunderbird, it is almost certain that the 
installed module was in fact compatible with newer version of 
Thunderbird.  (A security problem may directly impact Thunderbird or the 
module, but highly unlikely both packages.)
Rpm tags should have been set so that Thunderbird would recognize that 
the module was appropriate in the newer version.
So in sum, this was probably only a packaging problem.  Whatever the 
repository.


Note that if you install generic (not distro specific) Mozilla products, 
extensions can be added directly from within the application.  I suspect 
that this works the same with Mandriva versions, in which case packaging 
of Thunderbird should probably be done without any requirements for 
optional modules.



the other part ( non free + tainted ) seems OK for me

 

Me too
   


Agreed.
Except I would use the more neutral "restricted" rather than "tainted".
"tainted" sounds like one should never install such a package, whereas 
it is intended for packages more at risk to have legal problems in some 
countries.

Re: [Mageia-dev] Mirror layout, round two

[Michael Scherer]

Le lundi 29 novembre 2010 à 14:28 +0100, Olivier Thauvin a écrit :
> * Thomas Backlund (t...@iki.fi) wrote:
> > Olivier Thauvin skrev 29.11.2010 03:06:
> >> * Thomas Backlund (t...@iki.fi) wrote:
> >> I can't agree with the "mirrors are free to not mirror this media",
> >> three reasons:
> >> 1) I don't see an easy and safe way for mirrors to exclude a media (a
> >> directory + hdlist in media/media_info) in each distribution,
> >
> > Thats easy, just use --exclude-from
> >
> > On my local mirror I exclude the debug stuff
> > so I use --exclude-from=excclude.lst
> >
> > # cat exclude.lst
> > i586/media/*debug*
> > i586/media/media_info/*debug*
> > x86_64/media/*debug*
> > x86_64/media/media_info/*debug*
> >
> > And thats all needed.
> > We can even provide this exclude file ourselves on the mirrors so we  
> > know its correct and if we change the mirror layout, we update the file.
> 
> Completly not realist on mirror admin side.
> 
> You really have to remember that first mirror admin job is not maintains
> mirrors. They have often hundred of users on their back waiting for
> fixes.
> 
> When such will go wrong, nobody will be able to check and fix.

The issue is that we have 2 types of mirror admins :

- there is some of them who are hobbyist/enthusiasts, that use their own
server for that, and that mirror only one or 2 distros, and that may not
do it for their job or as part of their job. I think for example
Wolfgang would be in this category. They want to help us, but they may
have slightly limited ressources. But they can have time to tweak the
mirroring to fit what they can offer to us.

- on the other end of the spectrum, we have people who manage lots of
mirrors, with more bandwidth and bigger servers, more , but maybe not
more time. Ie people that does it as part of their job, with the
associate increase of ressources and work that come with a job. 

So admins that are more of the type 1 are likely ok with following
lists, giving input, tweaking rsync scripts, etc. They are the one that
could help us by giving stats or stuff like that, because they have the
time. But that's also people who may have more trouble ( because of
lesser ressources )
 
Type 2 would prefer to not have too much to do because they may have
better thing to do. Ideally, they set up and do not touch for the 10
next year and that's ok. 

So we need to take in account this divide.

We can't have just one type or the other, but in both case, a simpler
mirroring process will benefit to everybody.  


-- 
Michael Scherer