subject:"\[Mageia\-dev\] How will be the realese cycle\?"

On Wed, Oct 20, 2010 at 17:30, Wolfgang Bornath  wrote:
> 2010/10/20 Gustavo Giampaoli :
>> 2010/10/20 Tux99 :
>>> I hope you are not serious about this. Creepy unique identifiers (or any
>>> other tracking method) have absolutely no place in a FOSS community OS.
>>
>> Only if the default option is "NOT" enabled and system asks the user
>> "if he/she wants to collaborate with anonymous statistics" and
>> something like "if you don't know, use the default option NO".
>>
>> Don't know you, but I don't feel "hurt" nor feel my freedom violated
>> if it lets me choose. Different from Windows that does whatever MS
>> says without ask.
>
> The problem is that according to Robert's suggestion you do not have
> this choice if you want to file a bug report. I fear you will not get
> that many bug reports from privacy aware users if this system is used.
>

wait, what? I did not say that. What I am saying is that you have a choice,
just that for newbies you shouldn't have to learn how to sign up for a
bugzilla account and such... That would make Mageia look bug-prone,
in my opinion.

-- 
later, Robert Xu

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Wolfgang Bornath

2010/10/20 Gustavo Giampaoli :
> 2010/10/20 Tux99 :
>> I hope you are not serious about this. Creepy unique identifiers (or any
>> other tracking method) have absolutely no place in a FOSS community OS.
>
> Only if the default option is "NOT" enabled and system asks the user
> "if he/she wants to collaborate with anonymous statistics" and
> something like "if you don't know, use the default option NO".
>
> Don't know you, but I don't feel "hurt" nor feel my freedom violated
> if it lets me choose. Different from Windows that does whatever MS
> says without ask.

The problem is that according to Robert's suggestion you do not have
this choice if you want to file a bug report. I fear you will not get
that many bug reports from privacy aware users if this system is used.

Re: [Mageia-dev] How will be the realese cycle?

On Wed, Oct 20, 2010 at 16:29, Marc Paré  wrote:
> Le 2010-10-20 14:16, Gustavo Giampaoli a écrit :
>>
>> 2010/10/20 Tux99:
>>>
>>> I hope you are not serious about this. Creepy unique identifiers (or any
>>> other tracking method) have absolutely no place in a FOSS community OS.
>>
>> Only if the default option is "NOT" enabled and system asks the user
>> "if he/she wants to collaborate with anonymous statistics" and
>> something like "if you don't know, use the default option NO".
>>
>> Don't know you, but I don't feel "hurt" nor feel my freedom violated
>> if it lets me choose. Different from Windows that does whatever MS
>> says without ask.
>>
>> Regards.
>>
>>
>> Gustavo Giampaoli (aka tavillo1980)
>>
>
> I also would not like this and find it just as creepy. I would like to think
> that most of us would like to stay away from this.
>

only a suggestion. take it however you wish.

-- 
later, Robert Xu

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Marc Paré


Le 2010-10-20 14:16, Gustavo Giampaoli a écrit :

2010/10/20 Tux99:

I hope you are not serious about this. Creepy unique identifiers (or any
other tracking method) have absolutely no place in a FOSS community OS.


Only if the default option is "NOT" enabled and system asks the user
"if he/she wants to collaborate with anonymous statistics" and
something like "if you don't know, use the default option NO".

Don't know you, but I don't feel "hurt" nor feel my freedom violated
if it lets me choose. Different from Windows that does whatever MS
says without ask.

Regards.


Gustavo Giampaoli (aka tavillo1980)



I also would not like this and find it just as creepy. I would like to 
think that most of us would like to stay away from this.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Gustavo Giampaoli

2010/10/20 Tux99 :
> I hope you are not serious about this. Creepy unique identifiers (or any
> other tracking method) have absolutely no place in a FOSS community OS.

Only if the default option is "NOT" enabled and system asks the user
"if he/she wants to collaborate with anonymous statistics" and
something like "if you don't know, use the default option NO".

Don't know you, but I don't feel "hurt" nor feel my freedom violated
if it lets me choose. Different from Windows that does whatever MS
says without ask.

Regards.


Gustavo Giampaoli (aka tavillo1980)

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Wolfgang Bornath

2010/10/20 Robert Xu :
> Maybe one month every year you refresh the UUIDs by having the
> software send their UUID?
> That way any inactive UUIDs could be deleted.

Sorry, but still this seems like a monster. BTW: how do you want to
deal with non-Mageia and non-Linux machines from where I will want to
access Mageia places?

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Tux99

On Wed, 20 Oct 2010, Robert Xu wrote:

> On Wed, Oct 20, 2010 at 12:25, Wolfgang Bornath  
> wrote:
> > 2010/10/20 Robert Xu :
> >> Maybe you could modify it to give a personal UUID for each computer,
> >> so that the user
> >> is not forced to register?
> >
> > OMG! I would have gathered at least 10 UUIDs over the last 2 years.
> > Depends on what piece of hardware you want to attach the UUID to :)
> > Reminds me of the Windows registration system.
> >
> 
> haha, same. :)
> Er, I guess that could become a problem later...
> Maybe one month every year you refresh the UUIDs by having the
> software send their UUID?
> That way any inactive UUIDs could be deleted.
 

I hope you are not serious about this. Creepy unique identifiers (or any 
other tracking method) have absolutely no place in a FOSS community OS.

Re: [Mageia-dev] How will be the realese cycle?

On Wed, Oct 20, 2010 at 12:25, Wolfgang Bornath  wrote:
> 2010/10/20 Robert Xu :
>> Maybe you could modify it to give a personal UUID for each computer,
>> so that the user
>> is not forced to register?
>
> OMG! I would have gathered at least 10 UUIDs over the last 2 years.
> Depends on what piece of hardware you want to attach the UUID to :)
> Reminds me of the Windows registration system.
>

haha, same. :)
Er, I guess that could become a problem later...
Maybe one month every year you refresh the UUIDs by having the
software send their UUID?
That way any inactive UUIDs could be deleted.

-- 
later, Robert Xu

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread Wolfgang Bornath

2010/10/20 Robert Xu :
> Maybe you could modify it to give a personal UUID for each computer,
> so that the user
> is not forced to register?

OMG! I would have gathered at least 10 UUIDs over the last 2 years.
Depends on what piece of hardware you want to attach the UUID to :)
Reminds me of the Windows registration system.

Re: [Mageia-dev] How will be the realese cycle?

On Wed, Oct 20, 2010 at 10:11, andré  wrote:

[snip!]

>
> Good analogy :)
> It's like an accellerated version of "pass a message to the person to the
> left in the circle".  By the time it completes the circle and comes back (to
> the right), the original message is unrecognisable.
>>
>> It's much better to help the user formulate a useful bug report,
>> that's easier / more productive for all involved parties.
>>
>
> True.  Even the most naïve user can produce a good bug report with some
> help, if they are willing to put in some effort.  A thank you email would be
> a nice touch, especially for challenged users.  (I forget if Bugzilla
> already acknowleges bug reports.)
>
> The critical part is the ability to directly contact the user with the
> problem.  For Bugzilla, you have to log in, so there is an email adresse for
> contact.  And this is generally the case for forums.  If we use a forum for
> submitting bugs, we need the same login so that Bugzilla has a contact email
> available.  This is doable, and would also be more convenient for all
> contributors.
> Of course, there is still the barrier of getting the user to sign up for an
> account ... :)
>
> Another possibility is to have a Bugzilla assistant on the desktop, where
> the user is asked to describe the problem, give an email adresse, which is
> sent to Bugzilla.
>
> The approach of OpenOffice (official) could always be used for crashes.
> A bug report page opens as OpenOffice restarts automatically on a crash.
> Relevent info has already been gathered, viewable on a sub-page.
> The user is asked to optionally describe what he was doing, and is invited
> to optionally enter their email adresse if there are furthur questions (and
> informed that it will only be used for the purposes of the bug in question).
> And if the user provides an email adresse, they receive a thank you email
> with the bug tracking number.
> Very easy, and probably provides as much info as the average bugzilla
> report.
> Of course, only useful when a program crashes, where it can be automatically
> sensed that there is a problem.  And it will produce a lot of duplicate bug
> reports, evidently.
>

You could use a tool like abrt, which can detect duplicate bug
reports, if I am correct.
It'll also make filing bug reports easier...
Maybe you could modify it to give a personal UUID for each computer,
so that the user
is not forced to register?

-- 
later, Robert Xu

Re: [Mageia-dev] How will be the realese cycle?

2010-10-20 Thread andré


Ahmad Samir a écrit :

On 16 October 2010 17:31, Marc Paré  wrote:
   

Le 2010-10-16 02:56, Luca Berra a écrit :
 

On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:

The basic/novice user doesn't read anything,
 

remove basic/novice from the sentence and i will agree ;)
   

doesn't request anything to some like a bugzilla,
 

but give him a forum and he probably will
   

This statement I totally agree with! If a user is told to submit in
bugzilla, I find that they will not do it. Reporting to bugzilla for a user,
is one more level of serious commitment on their part and most will not want
to commit themselves to it.

However, if they can report to a forum, this is different. Users view forums
as community involvement with community feedback. They may be ask to test
out the problem and report back on the result (just like in bugzilla) but
they know that other community members will be there to lend a hand and
support.
 

And other community members are there in bugzilla to to lend a hand
and support (although a bit different kind of support as bugzilla's
have stricter rules, more organised).
   

If we are going to be really interested in quashing bugs with a lot of
community involvement, IMHO, I think that we should offer

-- bugzilla for the enthused and commited users. These people are interested
on reporting bugs the right way and will replicated and help in debugging.

-- but for ordinary users, we could offer them a "Report a bug" forum where
they can report a bug; the community could then replicated the bug; have a
"Bug-ambassador" or "bug-reporter" or  who could then submit it
officially on bugzilla. Tracking of that particular bug could then be the
responsibility of the "Bug-ambassador"; once the bug is quashed, the
"Bug-ambassador" could report back to the "Report a bug" forum of the bug
fix and thank the community for their help. This would help validate the
user who reported the bug and make him/her feel like a part of the
contributing team.

IMHO, this would work a lot better for the majority of users who do not want
to commit to any more than reporting the bug; the devs would get a more
constant stream of bug submissions by "Bug-ambassadors" who are able to
triage submitted bugs on the forum.

Doing it this way would still make bugzilla the only place where devs would
go to pick up bug information and the "Bug-ambassadors" would be the people
who triage the bugs at the forum level.

Marc
 

Backport requests are a special case as they're usually a 2-line
report "hey, could you backport the latest version of package foo to
?", so basically anyone can do it, either
the user or someone on his behalf.

But generally reporting bugs by proxy is always a bad idea, unless the
guy who'll play middle-man can reproduce the exact same bug on his own
box. You see, triage team / package maintainer / dev will ask for info
about the bug, more than once depending on the bug itself; now Mr.
middle-man will have to go to and fro a lot of times, taking info from
the user and posting it in bugzilla then taking questions/info from
the bugzilla and conveying it to the user; now that's a tedious and
tiresome job that's very prone to failure. (it's like a friend being
sick and instead of him going to the doctor he sends you on his behalf
because "you know the symptoms" :)).
   

Good analogy :)
It's like an accellerated version of "pass a message to the person to 
the left in the circle".  By the time it completes the circle and comes 
back (to the right), the original message is unrecognisable.

It's much better to help the user formulate a useful bug report,
that's easier / more productive for all involved parties.
   
True.  Even the most naïve user can produce a good bug report with some 
help, if they are willing to put in some effort.  A thank you email 
would be a nice touch, especially for challenged users.  (I forget if 
Bugzilla already acknowleges bug reports.)


The critical part is the ability to directly contact the user with the 
problem.  For Bugzilla, you have to log in, so there is an email adresse 
for contact.  And this is generally the case for forums.  If we use a 
forum for submitting bugs, we need the same login so that Bugzilla has a 
contact email available.  This is doable, and would also be more 
convenient for all contributors.
Of course, there is still the barrier of getting the user to sign up for 
an account ... :)


Another possibility is to have a Bugzilla assistant on the desktop, 
where the user is asked to describe the problem, give an email adresse, 
which is sent to Bugzilla.


The approach of OpenOffice (official) could always be used for crashes.
A bug report page opens as OpenOffice restarts automatically on a crash.
Relevent info has already been gathered, viewable on a sub-page.
The user is asked to optionally describe what he was doing, and is 
invited to optionally enter their email adresse if there are furthur 
q

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Dubeau, Patrick

> -Message d'origine-
> De : mageia-dev-boun...@mageia.org [mailto:mageia-dev-
> boun...@mageia.org] De la part de Wolfgang Bornath
> Envoyé : 18 octobre 2010 16:52
> À : Mageia development mailing-list
> Objet : Re: [Mageia-dev] How will be the realese cycle?
> 
> 2010/10/18 Renaud MICHEL :
> > On lundi 18 octobre 2010 at 03:04, Fernando Parra wrote :
> >> There are a biological law: Grow up in population or die, as simple
> as
> >> that.
> >
> > Here is another one: if you outgrow your natural resources, you'll
> starve.
> > (and humanity should be very aware of that)
> 
> When you expand your body so far that your heart can not supply it
> with blood (+ oxygen) you'll die.

Wow! Are we setting up a bio version of Mageia? :D


Patrick Dubeau (alias DaaX) - Webmaster MLO
http://www.mandrivalinux-online.org

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Wolfgang Bornath

2010/10/18 Renaud MICHEL :
> On lundi 18 octobre 2010 at 03:04, Fernando Parra wrote :
>> There are a biological law: Grow up in population or die, as simple as
>> that.
>
> Here is another one: if you outgrow your natural resources, you'll starve.
> (and humanity should be very aware of that)

When you expand your body so far that your heart can not supply it
with blood (+ oxygen) you'll die.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Renaud MICHEL

On lundi 18 octobre 2010 at 03:04, Fernando Parra wrote :
> There are a biological law: Grow up in population or die, as simple as
> that.

Here is another one: if you outgrow your natural resources, you'll starve.
(and humanity should be very aware of that)

-- 
Renaud Michel

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Sinner from the Prairy

Florian Hubold wrote:

> Hate to do that, but could we please focus on the topic of the thread
> and not dream about the next best thing in operating systems?
> We should focus on getting our base cleaned up, and to get a stable
> and good quality release out the door, This should be our top priority,
> and not endless discussions what everybody would wish for.

+1 


Salut,
Sinner

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Marc Paré


Le 2010-10-18 04:26, Wolfgang Bornath a écrit :

2010/10/18 Marc Paré:


Thanks Michael for the note. This is why I am in favour of streamlining the
reporting of bugs from the user side and not the dev. Devs should always
count on seeing bugs reported on bugzilla and nothing more. However, on the
user side, to keep the reporting of bug flow from breaking down, I suggest a
two tier format that I discussed earlier. Maybe have a look at this and
comment?

I imagine that the Mageia devs are interested in hearing of bugs from as
many sources as possible regardless of user experience.


Here's the place where I may bring back to attention the proposed
system of helpers in the user forums. People who help unexperienced
users to write bug reports and will also help them along if the devs
ask questions during the lifetime of that bug in bugzilla. A user who
has done this once (ideally from the start of a bug until its end)
will be eager to do it again when he stumbles across another bug. He
will also be eager to "teach" his new knowledge to other users. This
way we will get a larger community of "bug reporters" than by any
documents.

There must not be  a fixed "Bug Friends" group, this "mentoring" can
be done by all experienced users.



Actually, the process that you describe is exactly what mentoring is all 
about. I would be in favour of both processes.


BTW ... someone mentioned that we should have a different thread for 
this. Should we do this? Maybe call it "Report Bug Process" ?


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Marc Paré


Le 2010-10-18 04:18, Wolfgang Bornath a écrit :

Here's the result of the German community.
After the initial opening of the poll there was a discussion with more
than 40 postings, still going on. Involved were people actively using
ArchLinux, members of our packaging team and interested users. Voters
had the chance to alter their vote during the discussion, which was
used by some who learned more about "rolling release" during the
discussion.


* Exactly as Mandriva, 6 months release cycle 4%
* Exactly as Mandriva, 12 months release cycle   20%
* 6 months cycle for core, rolling release model for other software  13%
* 12 months cycle for core, rolling release model for other software 41%
* Rolling release 22%

With 54 % this is a majority for the "rolling light" model (where the
12 months cycle for core received the most votes). Remarkable is the
fact that the Mandriva release cycle (6 months) came in last.



Thanks again for the results. I wonder how many more communities are 
running the poll?


The results are becoming more and more obviously clear.

Could we start a new thread on this with the results posted on it?

Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Florian Hubold


 Am 18.10.2010 02:56, schrieb Fernando Parra:

On Sun, 17 Oct 2010 01:01:27 -0400
andré  wrote:


It's not just creating the update that costs, also due to these changing
dependancies, dealing with bugs on various installations of the release
in question becomes much more problematic.  Installing a backport is
generally more stable than installing a new version.

100% with you, more than that, we need take in count the panic caused by the 
installation of the complete OS.

Linux experienced users take this practice as a regular one, but anyone who has 
had to reinstall Windows with all previous applications, a process known to be 
hell, slow, tedious and often risky


Sorry, but i don't buy your arguments, This is not about making Mageia
noobproof installation. And when someone has panic about reinstalling
his/her box, then someone else should do it for them, simple as that.

Hate to do that, but could we please focus on the topic of the thread
and not dream about the next best thing in operating systems?
We should focus on getting our base cleaned up, and to get a stable
and good quality release out the door, This should be our top priority,
and not endless discussions what everybody would wish for.

For this there should be a wiki page or keep this on your private wishlist,
until the time has come to look if it can be realized and/or if it has more
advantages than disadvantages.


On topic: I'd like to see a snapshot/release every 12 months,
the core system (aka basesystem plus default de) should
be "frozen" and only receive bugfixes/security updates
and mostly everything else should be more-or-less rolling.
That also means there is no more difference in backports
and updates, that would be my model to go.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Thierry Vignaud

On 17 October 2010 09:56, David W. Hodgins  wrote:
> The problem I've experienced with the current Mandriva release cycle
> is with one friend, who has a slow system.  It took 13 hours to go
> from 2010.0 to 2010.1, even though (I'm guessing) the bulk of the files
> being downloaded were identical (except for the release number, and
> date of build), to what he already had.
>
> The same upgrade only took a couple of hours, on my system.  He has a
> faster internet connection, but a much slower computer.  I thought the
> faster download would be more important than the speed of the system,
> so I mistakenly gave him a 4 hour guesstimate.

Uh?
I've updated p...@733mhz with 256 to 512Mb of RAM on a 100kb/sec line
on a couple hours (let say between 2 & 6 hours)

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Thierry Vignaud

On 15 October 2010 13:42, Buchan Milne  wrote:
> "Now, maybe the user interface needs to be improved. For example, maybe there
> should be no dropdown box, but instead when searching for a package by name,
> it should show you all the versions:
>
> 
> Find: | digikam         | In: ->Graphical applications   |By: ->Package Name
> 
> Package|                |Status                          | Action
> +digikam                |Security update recommended     |Update            |
> - 1.3.0-1mdv            |Installed                       |Uninstall         |
> - 1.3.0-1.1mdv          |Security Update                 |Update            |
> - 1.4.0-4mdv            |Unsupported upgrade (backport)  |Upgrade           |
>
> -
> digikam - A KDE 
> =

woot! I love that

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Thierry Vignaud

On 14 October 2010 19:05, Tux99  wrote:
>> However, I then found that the new version of VLC had problems with
>> DVD menus, and the new CUPS introduced problems (not just in my
>> installation but at least one other Mandriva user).
>
> I would put this down to the fact that currently in Mandriva backports
> are given little attention by the packagers (as has been mentioned by
> the Mandriva packagers here themselves).

You really look only at what you want :-)

> Of course if we make them more central to the Mageia strategy then more
> care and testing is needed before a backport is pushed out.

That just mean double the amount of work for the QA team...
Experience told us that QA team has already too much work, the same
way, bug triage team has too much work, ...

And double is a minimum since :
- you're asking for quite a lot more agressive backports, thus quite a
lot more packages to test
- instead of just testing the security hole & basic work, we would
have to test quite a lot more stuff.
  (eg: for above VLC, playing various video, playing various musics,
playing DVD, ...)
- there would be quite a lot more situation to checks. eg:
  o bare distro + one updated package
  o bare distro + one backported package
  o bare distro + one backported package + backported some of its deps

Whereas updates can be tested on top of released distro + its updates,
for backports, we would have to test the distro + its updates, the
distro with some backports applied, ...

You're asking for a maintenance nightmare.

Let's focus. Let's maintain & stabilize one thing at a time, that is a
distro every 6 monthes.

> So I wouldn't consider that a fundamental issue with backports, just a
> procedural issue.

Yeah sure.

> Also personally I would consider CUPS a core app so I wouldn't have
> included that in backports at all.

No comment...
And what about above VLC?
Cannot you understand that _ANY_ backport can & will break ?

That's remains me new MDV leadership who tried to explain to us how
easy it's to maintain a stabe distro with 10% of the team...

Unrelated, I just found out that fglrx updates are half in
http://ftp.free.fr/pub/Distributions_Linux/MandrivaLinux/official/2010.1/x86_64/media/main/updates/
and half in nonfree/release... whereas they're fully not open
source...

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Wolfgang Bornath

2010/10/18 Marc Paré :
>
> Thanks Michael for the note. This is why I am in favour of streamlining the
> reporting of bugs from the user side and not the dev. Devs should always
> count on seeing bugs reported on bugzilla and nothing more. However, on the
> user side, to keep the reporting of bug flow from breaking down, I suggest a
> two tier format that I discussed earlier. Maybe have a look at this and
> comment?
>
> I imagine that the Mageia devs are interested in hearing of bugs from as
> many sources as possible regardless of user experience.

Here's the place where I may bring back to attention the proposed
system of helpers in the user forums. People who help unexperienced
users to write bug reports and will also help them along if the devs
ask questions during the lifetime of that bug in bugzilla. A user who
has done this once (ideally from the start of a bug until its end)
will be eager to do it again when he stumbles across another bug. He
will also be eager to "teach" his new knowledge to other users. This
way we will get a larger community of "bug reporters" than by any
documents.

There must not be  a fixed "Bug Friends" group, this "mentoring" can
be done by all experienced users.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-18 Thread Wolfgang Bornath

Here's the result of the German community.
After the initial opening of the poll there was a discussion with more
than 40 postings, still going on. Involved were people actively using
ArchLinux, members of our packaging team and interested users. Voters
had the chance to alter their vote during the discussion, which was
used by some who learned more about "rolling release" during the
discussion.


* Exactly as Mandriva, 6 months release cycle 4%
* Exactly as Mandriva, 12 months release cycle   20%
* 6 months cycle for core, rolling release model for other software  13%
* 12 months cycle for core, rolling release model for other software 41%
* Rolling release 22%

With 54 % this is a majority for the "rolling light" model (where the
12 months cycle for core received the most votes). Remarkable is the
fact that the Mandriva release cycle (6 months) came in last.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread atilla ontas

2010/10/18 Marc Paré :
>
> Hi Atilla:
>
> Thanks for reporting back to the mailist with the poll results.Did you find
> that users were well informed of a "rolling release model"?
>
> Marc
>
>

Yes. They know what is a rolling release model. Most of them also use
Arch Linux or try to get Arch on their computer. They know about
updating every day and less test, less stability. What can i say some
folks just want to get high. :)

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Marc Paré


Le 2010-10-17 15:28, atilla ontas a écrit :

Hi. If you interested, Mandriva Turkiye Community poll ended about
release cycle. Here are the results:

*Exactly as Mandriva, 6 months release cycle 18.2%
*Like OpenSuse, 8-9 months release cycle   13.6%
*One release a year  31.8%
* 6 months cycle for core, rolling release model other for other software  4.5%
* Rolling release 31.8%



Hi Atilla:

Thanks for reporting back to the mailist with the poll results.Did you 
find that users were well informed of a "rolling release model"?


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Marc Paré


Le 2010-10-17 19:44, Michael Scherer a écrit :

Le vendredi 15 octobre 2010 à 22:00 -0500, Fernando Parra a écrit :

I am just coming back from my weekend, so I may have missed lots of
discussion, but there is 2 points in your mail that I really wanted to
address.


The basic/novice user doesn't read anything, doesn't request anything
to some like a bugzilla,


And so, because some users are considered too lazy, we should do the
work for them ?

I am living in a world where days are only 24h long. If people are not
able to do their part of the work like "filling a proper bug report on
bugzilla to get their wish done for free by a already overworked
volunteer", the only answer I can give is 'too bad for them'.

If packagers were not already busy, yeah, I would think we should have
more backports requests. But if there is any packager that think "I do
not have enough work, give me more", he can send me a mail and I will
have no problem to help him solve this issue fo too much free time.

While I agree we should lower the bar for all kind of contributions, I
am not sure that giving more work to packagers by requesting backports
clearly qualify as a contribution, and so as such should not be lowered
too easily.

So before doing anything, we need to think about scaling from our side.


Please take in mind that we are trying to get a considerable number of new 
users.


I do not think I am ok to be counted in the "we" you use. I do not think
I want, nor that I will even try to get a considerable number of new
users, I want a sustainable number of users that can be properly taught
of free software way and ecosystem, so they can be later part of the
community as people who help us in very direct way. And that's what I
will try to do.



Thanks Michael for the note. This is why I am in favour of streamlining 
the reporting of bugs from the user side and not the dev. Devs should 
always count on seeing bugs reported on bugzilla and nothing more. 
However, on the user side, to keep the reporting of bug flow from 
breaking down, I suggest a two tier format that I discussed earlier. 
Maybe have a look at this and comment?


I imagine that the Mageia devs are interested in hearing of bugs from as 
many sources as possible regardless of user experience.


Marc Pare

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Fernando Parra

On Mon, 18 Oct 2010 01:44:29 +0200
Michael Scherer  wrote:


> I do not think I am ok to be counted in the "we" you use. I do not think
> I want, nor that I will even try to get a considerable number of new
> users, I want a sustainable number of users that can be properly taught
> of free software way and ecosystem, so they can be later part of the
> community as people who help us in very direct way. And that's what I
> will try to do.
> 
> -- 
> Michael Scherer
> 
There are a biological law: Grow up in population or die, as simple as that.

Regards from Mexico

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Fernando Parra

On Sun, 17 Oct 2010 01:01:27 -0400
andré  wrote:

> With Mandriva and thus initially Mageia, often one only has to select 
> the new version, and the old version is automatically removed.  
> Otherwise the old version can be removed later.  So we already have it 
> easier :)

I agree, our way is better, but its still strange for the new users

> This is simply not advisable.  In the event of a problem resulting from 
> an automatic update, the user will have no idea what was done.  So how 
> easy will it be to support the user in such a case ?  All changes should 
> be expressly confirmed (or specifically requested) by the user.

I never wrote something like an automatic and forced upgrade, automatic means 
that the upgrade must be offered by the SO as soon as a new version is 
available for its download.

All here will consider it as an offence of course, and invasion to the user 
space. Therefore it can be result in a law suite.

I despise the way MS applies the updates to operating system, because when you 
install Windows remains as the default option to automatically download and 
install all updates. If you want to change, it must be done manually.

> They will only likely want a new version of their favorite program if 
> they know it is available.  Which they will probably discover via backports.

Again, nobody is trying to kill backports. Question: if the backports 
repository was browsed by a draktool that only search for the Rolling Light 
Apps, and offer the updates available, would this be a problem? 

> Agree 100%.  The presentation definitely needs improvement.
> Obviously the novice user would use Rpmdrake via the MCC.
> And Rpmdrake definitely needs improvement.

100% with you, MCC needs and urgent improvement. As an examples we can see the 
Apple, Google and Ubuntu equivalent tools. I'm pretty sure we can do a better 
job.

> It's not just creating the update that costs, also due to these changing 
> dependancies, dealing with bugs on various installations of the release 
> in question becomes much more problematic.  Installing a backport is 
> generally more stable than installing a new version.

100% with you, more than that, we need take in count the panic caused by the 
installation of the complete OS.

Linux experienced users take this practice as a regular one, but anyone who has 
had to reinstall Windows with all previous applications, a process known to be 
hell, slow, tedious and often risky

> I think that all updates should be specifically confirmed.  Otherwise, 
> it's a bit like driving a car blind-folded, and later wondering why one 
> had an accident.
> It is a good idea to tag updates as "security", "recommended", etc.
> Implicitly, an advanced user is more likely to decide otherwise.
> But anyone who is intelligent enough to use a computer should be 
> respected enough to at least confirm updates.

The Ubuntu's automatic update tool has this functionality, but it has not a 
choice for permanently forget an a package in particular (as Mandriva too, only 
not obviously).

I causes, that every day an update not initially desired appear in the 
invitation window.

As an example in Mandriva One 2010.1 there is installed by default "tracker" 
this tool demands a lot of time and resources. Well there are a lot of 
recommendations for to inhibit this tool, I did it, but since last week every 
morning I see the invitation to update "tracker"

Anyway I suggest two different apps / ways / other. Why? Because it will be a 
better experience for the user. 

There a lot of recommended updates as well as security updates, some weeks 2 or 
3, that is good of course, but it can be converted in a routine, again nobody 
reads. I know users that never update their SO, why? because it's a tedious job 
(¿?)

IMHO an elegant different window or globe indicative of a new version of 
program "XWZ" should be a great opportunity for say: We are here, we are 
pending of your needs.

> And you didn't train your users ?  From personal experience, most users 
> learn quickly to copy error messages that appear on the screen - even 
> those who initially seem totally inept.  I regularly trained users who 
> initially required a lot of hand-holding to let me reliably troubleshoot 
> by telephone.  But it does take a little patience.
> Of course, novice home users will be more problematic, since they will 
> often use the computer much less.

Well it depends in a lot of factors, Corporative rules is one of them, but 
there a lot more.

Think in a novice user (maybe a young grandma), totally tired of crashes and 
malware, suddenly he/she reads in a blog about Mageia. She go to an cafe 
Internet and obtain a DVD installed on the laptop. Weeks later he/she are at an 
error situation.

What kind of training he/she has? he/she acts as always, try, and try again, 
and when finally looks outside, his/her behaviour could be as described above.

Thanks for your comments.

Regards from México.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Michael Scherer

Le vendredi 15 octobre 2010 à 22:00 -0500, Fernando Parra a écrit :

I am just coming back from my weekend, so I may have missed lots of
discussion, but there is 2 points in your mail that I really wanted to
address.

> The basic/novice user doesn't read anything, doesn't request anything 
> to some like a bugzilla, 

And so, because some users are considered too lazy, we should do the
work for them ?

I am living in a world where days are only 24h long. If people are not
able to do their part of the work like "filling a proper bug report on
bugzilla to get their wish done for free by a already overworked
volunteer", the only answer I can give is 'too bad for them'. 

If packagers were not already busy, yeah, I would think we should have
more backports requests. But if there is any packager that think "I do
not have enough work, give me more", he can send me a mail and I will
have no problem to help him solve this issue fo too much free time. 

While I agree we should lower the bar for all kind of contributions, I
am not sure that giving more work to packagers by requesting backports
clearly qualify as a contribution, and so as such should not be lowered
too easily. 

So before doing anything, we need to think about scaling from our side.

> Please take in mind that we are trying to get a considerable number of new 
> users. 

I do not think I am ok to be counted in the "we" you use. I do not think
I want, nor that I will even try to get a considerable number of new
users, I want a sustainable number of users that can be properly taught
of free software way and ecosystem, so they can be later part of the
community as people who help us in very direct way. And that's what I
will try to do.

-- 
Michael Scherer

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread atilla ontas

Hi. If you interested, Mandriva Turkiye Community poll ended about
release cycle. Here are the results:

*Exactly as Mandriva, 6 months release cycle 18.2%
*Like OpenSuse, 8-9 months release cycle   13.6%
*One release a year  31.8%
* 6 months cycle for core, rolling release model other for other software  4.5%
* Rolling release 31.8%

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Marc Paré


Le 2010-10-17 04:34, Tux99 a écrit :

On Sun, 17 Oct 2010, David W. Hodgins wrote:


I know enough c, perl, python, etc., that I can sometimes figure out
where the problem is, (when submitting bug reports), but I don't know
enough to put together rpm packages, or where to start, to learn how
to do so.


Making rpm packages is actually a lot easier than writing C, Perl or
Python code, so with your background it would be very easy for you to
learn how to make a package.

Have a look here, these instructions explain it well, I learnt it from
there:
http://wiki.mandriva.com/en/Development/Howto/RPM






Thanks for the link Tux99, I am interested in this too.

Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Tux99

On Sun, 17 Oct 2010, David W. Hodgins wrote:

> I know enough c, perl, python, etc., that I can sometimes figure out
> where the problem is, (when submitting bug reports), but I don't know
> enough to put together rpm packages, or where to start, to learn how
> to do so.

Making rpm packages is actually a lot easier than writing C, Perl or 
Python code, so with your background it would be very easy for you to 
learn how to make a package.

Have a look here, these instructions explain it well, I learnt it from 
there:
http://wiki.mandriva.com/en/Development/Howto/RPM

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread Ahmad Samir

On 17 October 2010 09:56, David W. Hodgins  wrote:
> On Sat, 16 Oct 2010 19:15:30 -0400, Fernando Parra 
> wrote:
>
>
>> Well the ball is on the air. The Mageia Server should be a Rolling Ligth
>> distro, yes or no?
>
> The problem I've experienced with the current Mandriva release cycle
> is with one friend, who has a slow system.  It took 13 hours to go
> from 2010.0 to 2010.1, even though (I'm guessing) the bulk of the files
> being downloaded were identical (except for the release number, and
> date of build), to what he already had.
>
> The same upgrade only took a couple of hours, on my system.  He has a
> faster internet connection, but a much slower computer.  I thought the
> faster download would be more important than the speed of the system,
> so I mistakenly gave him a 4 hour guesstimate.
>

A bit off-topic: What took a long time exactly? downloading the
package or installing them?

I am asking because I upgraded, more than one, virtualbox installs, it
never took more than 30min. to install the new packages (that's
leaving out the time it took to download them, which has more to do
with the download rate what with having a slow/fast system).

> I'm not a pc developer, so I don't know why things are being done the
> way they are, but expecting a user to spend half a day updating, every
> six months (or year), really annoys new users. My background is ibm
> 370 asm, cobol, pl/1, fortran, mark iv, roscoe, tso, db2, ims dc/db, etc.
>
> I know enough c, perl, python, etc., that I can sometimes figure out
> where the problem is, (when submitting bug reports), but I don't know
> enough to put together rpm packages, or where to start, to learn how
> to do so.
>
> Regards, Dave Hodgins
>



-- 
Ahmad Samir

Re: [Mageia-dev] How will be the realese cycle?

2010-10-17 Thread David W. Hodgins


On Sat, 16 Oct 2010 19:15:30 -0400, Fernando Parra  
wrote:



Well the ball is on the air. The Mageia Server should be a Rolling Ligth 
distro, yes or no?


The problem I've experienced with the current Mandriva release cycle
is with one friend, who has a slow system.  It took 13 hours to go
from 2010.0 to 2010.1, even though (I'm guessing) the bulk of the files
being downloaded were identical (except for the release number, and
date of build), to what he already had.

The same upgrade only took a couple of hours, on my system.  He has a
faster internet connection, but a much slower computer.  I thought the
faster download would be more important than the speed of the system,
so I mistakenly gave him a 4 hour guesstimate.

I'm not a pc developer, so I don't know why things are being done the
way they are, but expecting a user to spend half a day updating, every
six months (or year), really annoys new users. My background is ibm
370 asm, cobol, pl/1, fortran, mark iv, roscoe, tso, db2, ims dc/db, etc.

I know enough c, perl, python, etc., that I can sometimes figure out
where the problem is, (when submitting bug reports), but I don't know
enough to put together rpm packages, or where to start, to learn how
to do so.

Regards, Dave Hodgins

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread andré


Fernando Parra a écrit :

On Fri, 15 Oct 2010 12:42:03 +0100
Buchan Milne  wrote:
...

On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
 

Hi everybody.

I feel that the concept of a new way, as it exist into my mind is not
completely understood. Let me try to re-explain again. Please be patient
and excuses any mistake with my English (I'm totally out of practice):

I'm talking about to liberate to novice/novel/without experience user,
about concepts like backports, but I'm not talking about
close/disappear/eliminate/forgot backports.

Why? because a big share of them will arrive from a very different
environment (especially windows), and as you now, in there those concepts
are not only estrange, they simply don't exists. When a Windows user
wants/needs to update a program, as much the only thing that he/she must
do is unninstall the old/previous version and then install the new one.
   
With Mandriva and thus initially Mageia, often one only has to select 
the new version, and the old version is automatically removed.  
Otherwise the old version can be removed later.  So we already have it 
easier :)

What programs? Following the same idea, about these kind of users, we
should ask: what programs they usually upgrade? The answer could be found
asking to the user's themselves, but certainly could be another ways.

Why not all backports? Reason 1: Because a lot of them don't care about the
new version of CUPS (in example) or the new version of Maxima (I'm sure
there are a lot clearly examples). Reason 2: Because there are packages
that may causes some incidents after upgrade them.

How we can solve this situation? Offering a default automatic upgrade for a
small group of packages, especially when they change in an important way,
in example Firefox 3.6x 3.6x+ or to 4.x
   
This is simply not advisable.  In the event of a problem resulting from 
an automatic update, the user will have no idea what was done.  So how 
easy will it be to support the user in such a case ?  All changes should 
be expressly confirmed (or specifically requested) by the user.

With this in mind:
   

What aspects of the Mandriva backports solution are not satisfactory?

-The fact that not everything is available as a backport?
 

True in the Microsoft windows environnement, as everywhere else.

Not all are in backports, more these users don't want/understand a big
share of them
   

So, we must "dumb down" everything, and not provide openldap backports for
people running servers who want a convenient way to run the software version
that will allow them to file bugs upstream (OpenLDAP team doesn't respond to
bugs filed on non-current releases)?
 

Specially here the answer is obvious: The novice doesn't now what is OpenLDAP! 
and maybe he wont hear about it for the rest of his life. New versions of 
OpenLDAP should be stay available in the backports repository, not as an 
automatic available upgrade.
   
The user selects which backports they want.  If they don't understand 
OpenLDAP, they wouldn't have a reason to select it.

-That users don't know how to request a backport?
 

That is true, more, they don't want to learn about that, they only want a
new version of their favourite program.
   
They will only likely want a new version of their favorite program if 
they know it is available.  Which they will probably discover via backports.

What do we do in the case where a new version of some software is available,
and has been sent to cooker? How do we decide whether it should go to
backports or not? And for which releases?

(FYI, for Mandriva users can typically request backports in bugzilla or on
IRC, but we may need better means).
 

Agree 100%.  The presentation definitely needs improvement.

Ok, first at all, we must deicide what packages (not all of them!) will be at 
the Rolling Ligth model. After that, all this packages must have an appropriate 
path.
   

-That too many backports are available?
 

This is matter of who are revising backports, for novice? Yes there are to
many. For the geek or the expert? Maybe never there will enough of them.
   

-That all users don't get them by default?
-That users doing network installs by default don't get the backport on
initial installation?
 

No, they are not get them if we will use a potentially problematic
repository.
   

-That users aren't aware of backports?
-Something else?
 

Panic? Fear? Baal, Luzbel and other demons in their minds?
   

Technically speaking?
Less than 'urpmi --searchmedia Backports chromium' ?
 

If I was a novice my answer will be: What hell is that?
   

Obviously the novice user would use Rpmdrake via the MCC.
And Rpmdrake definitely needs improvement.

This was a response to 'users must do less', not 'it must be very easy'. At
present, users need to do just one thing. We can fix the ease of doing that
one thing, if we understand the problem correctly

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Liam R E Quin

On Sat, 2010-10-16 at 23:11 -0400, Marc Paré wrote:

[...]

> I think what this all boils down to is, does the Mageia project want to 
> actively seek out bugs and encourage its users to report bugs? If Mageia 
> is interested in seriously quashing bugs, then the reporting process has 
> to be streamlined in such a way as to encourage the reporting of bug as 
> painlessly as possible for users.

It's a good question (although some projects prefer to keep it so that
the people reporting bugs tend to be the ones able to give a clear
description of the problem and ways to reproduce it)... but...

Please do change the subject line if you go this-far off thread.

I'm only checking each thread once a week or so and probably others
do the same, not trying to read every message, as the volume is too
high.  But, more people could contribute if the mail-flood was easier.
Which is not unlike your point about the bugs :-)

Best,

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org www.advogato.org

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-16 18:35, Romain d'Alverny a écrit :

On Sat, Oct 16, 2010 at 21:29, Marc Paré  wrote:

Le 2010-10-16 12:36, Ahmad Samir a écrit :


It's much better to help the user formulate a useful bug report,
that's easier / more productive for all involved parties.


There would be no middle man. Once the middle-man could replicate the bug
and verify the bug with other users, then the middle-man would submit to
bugzilla. That's it. From there on, the middle-man will take care of testing
requests from devs.

As far as reporting back to the original user who reported the bug, as an
extra gesture of kindness, the middle-man would just post on the "Report a
bug" forum that the bug has been quashed or is still under review ... but
not to the user but to the "Report a bug" forum.

The idea is to keep the flow of possible bug reports coming in an organised
way. The middle-man would have to be someone with a little more experience
than that of a new user and also someone who has an interest in working this
way. We will get more bug reports from users by keeping it simple and easy.


Yes, and for everyone.

I tend to agree with Ahmad, as well as with you.

You may as well imagine we improve the Bugzilla process with a
front-process, guiding the reporter about her bug report.

That may be a forum with people active there, educating the user about
the bug and the reporting process;

And/or that may be a better designed bug reporting process with a
better flow (providing and getting info to/from the user), querying a
knowledge-base, filtering known/resolved queries out of
yet-another-duplicate-bug-report and ultimately opening a bug in
Bugzilla with a specific interaction to the user (so she knows what
happens next).*

That removes the middle-man issue and that filters out as well people
that are not concerned enough to report/follow-up on a bug (provided
the process is, indeed, better designed and better welcomes the end
user).


* moreover, I believe this type of improvement would benefit many,
many, if not all, projects using a bug report tool.

Cheers,

Romain



Thanks for the note Romain.

I think what this all boils down to is, does the Mageia project want to 
actively seek out bugs and encourage its users to report bugs? If Mageia 
is interested in seriously quashing bugs, then the reporting process has 
to be streamlined in such a way as to encourage the reporting of bug as 
painlessly as possible for users. Human nature being what it is, people 
will gladly report a bug if there is a way to do so quickly and easily. 
However, it gets more complicated if you ask users to follow up on their 
bug report, as in bugzilla.


IMHO, it would be easier if Mageia offered users:

-- The reporting of bugs through bugzilla as is usually done, and the 
devs can work out these problems with the normal messaging that normally 
goes along with the bugzilla process.


-- For users who have no intention of being part of bugzilla and who 
would still like to report a bug, a forum discussion where a "middle 
man" or "bug facilitator" would help triage the bugs in this forum, 
verify the bug and then submit it in their name. The user would not be 
obligated from this point on to involve herself with the testing of 
possible bug repairs. The "bug facilitator" would be obligated to the 
usual bugzilla process. Of course if the user wished to learn more and 
participate in the bugzilla process, then the "bug-facilitator" could 
help mentor the user to the bugzilla process.


This way the user would have 2 methods of reporting, one with a certain 
amount of commitment and the other with no commitments other than 
reporting and doing a quick verification with the help of the "bug 
facilitator".


The devs would not be part of this process and would work through the 
bugzilla as usual. And the bug reporting would, IMOH, be more streamlined.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Fernando Parra

On Sat, 16 Oct 2010 23:28:32 +0200
Luca Berra  wrote:

> On Sat, Oct 16, 2010 at 10:41:31AM -0500, Fernando Parra wrote:
> >On Sat, 16 Oct 2010 08:56:06 +0200
> >Luca Berra  wrote:
> >
> >> On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:
> >> >The basic/novice user doesn't read anything,
> >> remove basic/novice from the sentence and i will agree ;)
> >> 
> >
> >Are you agree with some like that?
> >Only the geek/expert/professional users read?
> I think most people don't read, sometime even geek/expert/professional
> don't. This is probably due to an overload of information, and trying to
> create messages that are actually 'seen' by users is becoming a new
> branch of science.
> 

I will try to answer. Nobody reads, yes it's the true (I'm a teacher I really 
know about the situation), but there are a magic exception. The user reads when 
he wants something. By example a lot of my students has a Notebook or a Laptop, 
and always have installed the last version of MSN Live, and of course the 
latest versions of their favourite games. How we can explain that? Are all this 
programs magically installed? No they install them as their wishes. But first 
appear a nice message invite them to upgrade.

> >> > doesn't request anything to some like a bugzilla,
> >> but give him a forum and he probably will
> >
> >Here I'm not completely sure, How many forums, blogs, etc. about software 
> >are there (including Windows, Mac and others)? and How many users they have? 
> >At present time the number of pc's in the entire world are estimated in 
> >1,500 millions, the number of users can be estimated without force the 
> >numbers as a twice of this number. Worst, we are in the Wikipedia age; in 
> >example, when I request an investigation to my students, about any theme. I 
> >need strictly keep out Wikipedia (Oh well, yes Encarta too) as a valid 
> >source.
> 
> Then it is difficult to do what user want, if we don't get any feedback.
> 

Well, you are right its difficult, but it isn't impossible. The big share of 
software publishers has statistics about at least of the number of downloads of 
their programs. And there are a lot of independent statistical measures. More, 
we have common sense (I hope!). And a final resource: we can make experiments, 
The Rolling Ligth program list shouldn't be like the 10 commandments (static 
per secula seculorum), As the software it is permanent state of change, the 
user's preferences are in a permanent evolution.

> ...
> >> Seriuosly speaking, i'd like to make a distinguo:
> >> The real basic(*) user just uses a computer to get her work done, he
> >> does not give a damn about a new version of firefox, kde or wathever, as
> >> long as the version she is using is functioning.
> ...
> >Are you sure? I'll try to explain me with a practical example: I really 
> >don't remember what of the versions of the Open Office 3.x branch open the 
> >road to read and write the MS Office 2007 (docx, etc) but when its happen, 
> >it was "the great success" How many users really need this particular 
> >"goodie", I think a big share of them!
> 
> well i had in mind a real life example when i wrote the above
> ...
> >> we should not mix the needs of this two categories, neither would like
> >> it.
> >
> >Ok, I call these users "intermediate users" and here in Mexico we have an 
> >idiomatic expression for these situations: "El qué quiera azul celeste, ¡que 
> >le cueste!" A poor translation of that is: If someone want something 
> >special, pays for get it!
> the above stands, these categories have different needs and whishes.
> 
> >> btw, we also have users interested in backports of stuff like openldap,
> >> samba or such, these users will actually contribute to the technical
> >> making of the distro, either by using bugzilla when they find bugs or
> >> actually doing packaging work. Ignoring the will of such users will,
> >> sooner or later, force mageia to employ paid personnel to do packaging
> >> work.
> >
> >I disagree here, a big share of the users are sick (including me) of an 
> >illness called "versionitis gravis". Good I'm sick!:) As I can see there are 
> >two variants of the illness:
> I just meant that many people working on packaging are also using the
> distro for running servers, so we are interested in server stuff, which
> the average user wont' prolly give a sh@@@ about.

Well, I'm thinking a lot in the server users, As a server administrator I'm 
very conservative (but it is only my POV) before to say anything I'm reading 
more opinions about the Rolling Light in servers.

You can read an interesting thread a the discuss mail list, specially one of 
the mails is about a college that prefer install CentOS in their desktops PC, 
because they don't want to support two different distros, and they choose 
CentOS as a server.

Well the ball is on the air. The Mageia Server should be a Rolling Ligth 
distro, yes or no?

Regards from Mexico.
-- 
Fernando Parra

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Romain d'Alverny

On Sat, Oct 16, 2010 at 21:29, Marc Paré  wrote:
> Le 2010-10-16 12:36, Ahmad Samir a écrit :
>
>> It's much better to help the user formulate a useful bug report,
>> that's easier / more productive for all involved parties.
>
> There would be no middle man. Once the middle-man could replicate the bug
> and verify the bug with other users, then the middle-man would submit to
> bugzilla. That's it. From there on, the middle-man will take care of testing
> requests from devs.
>
> As far as reporting back to the original user who reported the bug, as an
> extra gesture of kindness, the middle-man would just post on the "Report a
> bug" forum that the bug has been quashed or is still under review ... but
> not to the user but to the "Report a bug" forum.
>
> The idea is to keep the flow of possible bug reports coming in an organised
> way. The middle-man would have to be someone with a little more experience
> than that of a new user and also someone who has an interest in working this
> way. We will get more bug reports from users by keeping it simple and easy.

Yes, and for everyone.

I tend to agree with Ahmad, as well as with you.

You may as well imagine we improve the Bugzilla process with a
front-process, guiding the reporter about her bug report.

That may be a forum with people active there, educating the user about
the bug and the reporting process;

And/or that may be a better designed bug reporting process with a
better flow (providing and getting info to/from the user), querying a
knowledge-base, filtering known/resolved queries out of
yet-another-duplicate-bug-report and ultimately opening a bug in
Bugzilla with a specific interaction to the user (so she knows what
happens next).*

That removes the middle-man issue and that filters out as well people
that are not concerned enough to report/follow-up on a bug (provided
the process is, indeed, better designed and better welcomes the end
user).


* moreover, I believe this type of improvement would benefit many,
many, if not all, projects using a bug report tool.

Cheers,

Romain

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Luca Berra

On Sat, Oct 16, 2010 at 10:41:31AM -0500, Fernando Parra wrote:

On Sat, 16 Oct 2010 08:56:06 +0200
Luca Berra wrote:

On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:
>The basic/novice user doesn't read anything,
remove basic/novice from the sentence and i will agree ;)

Are you agree with some like that?
Only the geek/expert/professional users read?

I think most people don't read, sometime even geek/expert/professional
don't. This is probably due to an overload of information, and trying to
create messages that are actually 'seen' by users is becoming a new
branch of science.

> doesn't request anything to some like a bugzilla,
but give him a forum and he probably will

Here I'm not completely sure, How many forums, blogs, etc. about software are
there (including Windows, Mac and others)? and How many users they have? At
present time the number of pc's in the entire world are estimated in 1,500
millions, the number of users can be estimated without force the numbers as a
twice of this number. Worst, we are in the Wikipedia age; in example, when I
request an investigation to my students, about any theme. I need strictly keep
out Wikipedia (Oh well, yes Encarta too) as a valid source.

Then it is difficult to do what user want, if we don't get any feedback.

...

Seriuosly speaking, i'd like to make a distinguo:
The real basic(*) user just uses a computer to get her work done, he
does not give a damn about a new version of firefox, kde or wathever, as
long as the version she is using is functioning.

...

Are you sure? I'll try to explain me with a practical example: I really don't remember what of the
versions of the Open Office 3.x branch open the road to read and write the MS Office 2007 (docx,
etc) but when its happen, it was "the great success" How many users really need this
particular "goodie", I think a big share of them!

well i had in mind a real life example when i wrote the above
...

we should not mix the needs of this two categories, neither would like
it.

Ok, I call these users "intermediate users" and here in Mexico we have an idiomatic
expression for these situations: "El qué quiera azul celeste, ¡que le cueste!" A poor
translation of that is: If someone want something special, pays for get it!

the above stands, these categories have different needs and whishes.

btw, we also have users interested in backports of stuff like openldap,
samba or such, these users will actually contribute to the technical
making of the distro, either by using bugzilla when they find bugs or
actually doing packaging work. Ignoring the will of such users will,
sooner or later, force mageia to employ paid personnel to do packaging
work.

I disagree here, a big share of the users are sick (including me) of an illness called
"versionitis gravis". Good I'm sick!:) As I can see there are two variants of
the illness:

I just meant that many people working on packaging are also using the
distro for running servers, so we are interested in server stuff, which
the average user wont' prolly give a sh@@@ about.

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

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-16 16:08, Frederic Janssens a écrit :



On Sat, Oct 16, 2010 at 21:52, Renaud MICHEL
mailto:r.h.michel%2bmag...@gmail.com>> wrote:

I think it may work if those "bug friends" (don't remember who
proposed that
name) only take for themselves the simple, one package, software
only bugs,
and suggest to the reporter to create himself a bugreport (eventually
providing assistance if the reporter has never done it before)

yes, it is mainly there that 'help with followup' is needed.
If that help is well done, a certain number of the helped could become
helpers later on.

describing
his problem, because the devs will really need his feedback first hand.
That forum would be an easier entry point than bugzilla for users not
familiar with bugreports.

--
Renaud Michel

Frederic


Thanks Frederic, my feeling also.

Marc

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-16 15:52, Renaud MICHEL a écrit :

On samedi 16 octobre 2010 at 21:29, Marc Paré wrote :

There would be no middle man. Once the middle-man could replicate the
bug and verify the bug with other users, then the middle-man would
submit to bugzilla. That's it. From there on, the middle-man will take
care of testing requests from devs.


That would only work for pure software bugs.
If the bug is hardware related, it is unlikely that the "middle man" will be
able to reproduce it. For those we really need the input from the real bug
reporter.

And for software bugs, the "middle man" would have to reproduce the software
environment of the reporter, which may be complicated if he installed
software from third party (or worse, proprietary software).
Sometimes the problem is obvious and only related to a single package, and
for such case a forum with some contributors reproducing the bug and then
submitting a bug report may work.
But if the problem is related to a particular combination of packages then
the "middle man" could spend a considerable amount of time replicating the
reporter particular configuration before he can actually reproduce the bug.

I think it may work if those "bug friends" (don't remember who proposed that
name) only take for themselves the simple, one package, software only bugs,
and suggest to the reporter to create himself a bugreport (eventually
providing assistance if the reporter has never done it before) describing
his problem, because the devs will really need his feedback first hand.
That forum would be an easier entry point than bugzilla for users not
familiar with bugreports.



Yes you are perfectly right. This is where the the bug report would be 
ramped up to the bugzilla stage, and at the point, the reporter would 
have obviously shown an interest in the resolution/fix of the bug. This 
would in effect would create a mentorhsip/reporter relationship and a 
great training opportunity for the reporter. We would then have, by 
default, a mentorship programme in the "Report a bug" forum that may 
eventually form other "bug friends" This would be a great opportunity 
for Mageia to teach reporters how to use bugzilla.


IMHO, this would still be a simple way of dealing with normal users who 
do not want to involve themselves any more than reporting a bug. And for 
those who develop a taste for furthering their knowledge of the process 
of bug reporting, the "bug friend" could then mentor this person ... who 
could eventually become a "bug friend" himself/herself.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Frederic Janssens

On Sat, Oct 16, 2010 at 21:52, Renaud MICHEL

> wrote:

> I think it may work if those "bug friends" (don't remember who proposed
> that
> name) only take for themselves the simple, one package, software only bugs,
> and suggest to the reporter to create himself a bugreport (eventually
> providing assistance if the reporter has never done it before)


yes, it is mainly there that 'help with followup' is needed.
If that help is well done, a certain number of the helped could become
helpers later on.

describing
> his problem, because the devs will really need his feedback first hand.
> That forum would be an easier entry point than bugzilla for users not
> familiar with bugreports.
>
> --
> Renaud Michel
>



-- 

Frederic

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Renaud MICHEL

On samedi 16 octobre 2010 at 21:29, Marc Paré wrote :
> There would be no middle man. Once the middle-man could replicate the 
> bug and verify the bug with other users, then the middle-man would 
> submit to bugzilla. That's it. From there on, the middle-man will take 
> care of testing requests from devs.

That would only work for pure software bugs.
If the bug is hardware related, it is unlikely that the "middle man" will be 
able to reproduce it. For those we really need the input from the real bug 
reporter.

And for software bugs, the "middle man" would have to reproduce the software 
environment of the reporter, which may be complicated if he installed 
software from third party (or worse, proprietary software).
Sometimes the problem is obvious and only related to a single package, and 
for such case a forum with some contributors reproducing the bug and then 
submitting a bug report may work.
But if the problem is related to a particular combination of packages then 
the "middle man" could spend a considerable amount of time replicating the 
reporter particular configuration before he can actually reproduce the bug.

I think it may work if those "bug friends" (don't remember who proposed that 
name) only take for themselves the simple, one package, software only bugs, 
and suggest to the reporter to create himself a bugreport (eventually 
providing assistance if the reporter has never done it before) describing 
his problem, because the devs will really need his feedback first hand.
That forum would be an easier entry point than bugzilla for users not 
familiar with bugreports.

-- 
Renaud Michel

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-16 12:36, Ahmad Samir a écrit :



But generally reporting bugs by proxy is always a bad idea, unless the
guy who'll play middle-man can reproduce the exact same bug on his own
box. You see, triage team / package maintainer / dev will ask for info
about the bug, more than once depending on the bug itself; now Mr.
middle-man will have to go to and fro a lot of times, taking info from
the user and posting it in bugzilla then taking questions/info from
the bugzilla and conveying it to the user; now that's a tedious and
tiresome job that's very prone to failure. (it's like a friend being
sick and instead of him going to the doctor he sends you on his behalf
because "you know the symptoms" :)).

It's much better to help the user formulate a useful bug report,
that's easier / more productive for all involved parties.



There would be no middle man. Once the middle-man could replicate the 
bug and verify the bug with other users, then the middle-man would 
submit to bugzilla. That's it. From there on, the middle-man will take 
care of testing requests from devs.


As far as reporting back to the original user who reported the bug, as 
an extra gesture of kindness, the middle-man would just post on the 
"Report a bug" forum that the bug has been quashed or is still under 
review ... but not to the user but to the "Report a bug" forum.


The idea is to keep the flow of possible bug reports coming in an 
organised way. The middle-man would have to be someone with a little 
more experience than that of a new user and also someone who has an 
interest in working this way. We will get more bug reports from users by 
keeping it simple and easy.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Ahmad Samir

On 16 October 2010 17:31, Marc Paré  wrote:
> Le 2010-10-16 02:56, Luca Berra a écrit :
>>
>> On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:
>>>
>>> The basic/novice user doesn't read anything,
>>
>> remove basic/novice from the sentence and i will agree ;)
>>
>>> doesn't request anything to some like a bugzilla,
>>
>> but give him a forum and he probably will
>>
>
> This statement I totally agree with! If a user is told to submit in
> bugzilla, I find that they will not do it. Reporting to bugzilla for a user,
> is one more level of serious commitment on their part and most will not want
> to commit themselves to it.
>
> However, if they can report to a forum, this is different. Users view forums
> as community involvement with community feedback. They may be ask to test
> out the problem and report back on the result (just like in bugzilla) but
> they know that other community members will be there to lend a hand and
> support.

And other community members are there in bugzilla to to lend a hand
and support (although a bit different kind of support as bugzilla's
have stricter rules, more organised).

>
> If we are going to be really interested in quashing bugs with a lot of
> community involvement, IMHO, I think that we should offer
>
> -- bugzilla for the enthused and commited users. These people are interested
> on reporting bugs the right way and will replicated and help in debugging.
>
> -- but for ordinary users, we could offer them a "Report a bug" forum where
> they can report a bug; the community could then replicated the bug; have a
> "Bug-ambassador" or "bug-reporter" or  who could then submit it
> officially on bugzilla. Tracking of that particular bug could then be the
> responsibility of the "Bug-ambassador"; once the bug is quashed, the
> "Bug-ambassador" could report back to the "Report a bug" forum of the bug
> fix and thank the community for their help. This would help validate the
> user who reported the bug and make him/her feel like a part of the
> contributing team.
>
> IMHO, this would work a lot better for the majority of users who do not want
> to commit to any more than reporting the bug; the devs would get a more
> constant stream of bug submissions by "Bug-ambassadors" who are able to
> triage submitted bugs on the forum.
>
> Doing it this way would still make bugzilla the only place where devs would
> go to pick up bug information and the "Bug-ambassadors" would be the people
> who triage the bugs at the forum level.
>
> Marc
>
>

Backport requests are a special case as they're usually a 2-line
report "hey, could you backport the latest version of package foo to
?", so basically anyone can do it, either
the user or someone on his behalf.

But generally reporting bugs by proxy is always a bad idea, unless the
guy who'll play middle-man can reproduce the exact same bug on his own
box. You see, triage team / package maintainer / dev will ask for info
about the bug, more than once depending on the bug itself; now Mr.
middle-man will have to go to and fro a lot of times, taking info from
the user and posting it in bugzilla then taking questions/info from
the bugzilla and conveying it to the user; now that's a tedious and
tiresome job that's very prone to failure. (it's like a friend being
sick and instead of him going to the doctor he sends you on his behalf
because "you know the symptoms" :)).

It's much better to help the user formulate a useful bug report,
that's easier / more productive for all involved parties.

-- 
Ahmad Samir

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Fernando Parra

On Sat, 16 Oct 2010 11:52:27 +0200
Renaud MICHEL  wrote:

> Hello
> On samedi 16 octobre 2010 at 05:00, Fernando Parra wrote :
> > > On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
> > > So, we must "dumb down" everything, and not provide openldap backports
> > > for people running servers who want a convenient way to run the
> > > software version that will allow them to file bugs upstream (OpenLDAP
> > > team doesn't respond to bugs filed on non-current releases)?
> > 
> > Specially here the answer is obvious: The novice doesn't now what is
> > OpenLDAP! and maybe he wont hear about it for the rest of his life. New
> > versions of OpenLDAP should be stay available in the backports
> > repository, not as an automatic available upgrade.
> 
> Well, for example like OpenLDAP it is not a problem, because only users that 
> need it will install it, and those that might need it are most likely aware 
> what it implies to upgrade it to a newer version. So it will not bother 
> other users if it is in backports or even updates, because as they won't 
> have it installed, they won't be proposed to update.
> 
> It is more of a concern for things like cups or dbus, which most users will 
> use without knowing it, and won't know how to fix if it breaks (not even 
> knowing which package actually broke).
> 
> > > What do we do in the case where a new version of some software is
> > > available, and has been sent to cooker? How do we decide whether it
> > > should go to backports or not? And for which releases?
> > > 
> > > (FYI, for Mandriva users can typically request backports in bugzilla or
> > > on IRC, but we may need better means).
> > 
> > Ok, first at all, we must deicide what packages (not all of them!) will
> > be at the Rolling Ligth model. After that, all this packages must have
> > an appropriate path.
> 
> I don't understand what you mean by "appropriate path".
> 

Well, if we are talking about a new model, I think we need to redefine what 
will be the way that's Mageia offer these particular (Rolling Light) packages. 
I'm not closed to any method in particular.

> I think we should not decide before hand what packages will be backported, 
> we should maybe have a (short) list of packages that must not be backported 
> (like glibc) and then have backports either when contributors are willing to 
> make (and test) them, or on request.
> 
> Maybe we could also have a (short also) list of packages that we should 
> really try (the packaging team could decide to dedicate some of his 
> resources to that) to backport to the latest stable release, and maybe the 
> previous latest.
> Such packages would be for example firefox or OOo, packages that we know are 
> used by many (most) users, and many users are likely to want a newer 
> version.
> 
> > Anyway, after decide what packages will be in the Rolling Light, The OS
> > must be gentle with the user and show a Window with a Message like that:
> > 
> > There are available a new version of Firefox(as an example). Do you want
> > to install it? NO,   Maybe Later,   Show me more information,Yes
> 
> A little OT, but:
> 
> Dialog windows should (almost) never have yes/no or ok/cancel choices, 
> because when an user see a yes/ok choice, he generally interpret it as "yes, 
> I want to keep on doing what I was doing". (and I know I have done it some 
> times myself)
> 
> In your example, the No/yes should be labelled something like "keep current 
> version" and "install new version".
> 

Ok, as more clear options, as it will be better.

> 
> cheers
> -- 
> Renaud Michel
> 

Regards from Mexico
-- 
Fernando Parra

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Fernando Parra

On Sat, 16 Oct 2010 08:56:06 +0200
Luca Berra  wrote:

> On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:
> >The basic/novice user doesn't read anything,
> remove basic/novice from the sentence and i will agree ;)
> 

Are you agree with some like that?
Only the geek/expert/professional users read?

> > doesn't request anything to some like a bugzilla,
> but give him a forum and he probably will

Here I'm not completely sure, How many forums, blogs, etc. about software are 
there (including Windows, Mac and others)? and How many users they have? At 
present time the number of pc's in the entire world are estimated in 1,500 
millions, the number of users can be estimated without force the numbers as a 
twice of this number. Worst, we are in the Wikipedia age; in example, when I 
request an investigation to my students, about any theme. I need strictly keep 
out Wikipedia (Oh well, yes Encarta too) as a valid source.

> 
> > If you show on his screen some like your proposal, he usually take one of 
> > two different ways: 1) Check all the options or maybe worst 2) Close the 
> > window and he will think: "Oh hell, Why Linux is so hard?"
> then we shall abuse the user like most windows installers do, and
> install all sort of crap with preselected checkboxes?
> 
> >Anyway, after decide what packages will be in the Rolling Light
> was the model decided yet?
> 

As you may watch, this discussion is on the way.

> >The OS must be gentle with the user and show a Window with a Message like 
> >that:
> >
> >There are available a new version of Firefox(as an example). Do you want to 
> >install it?
> >NO,   Maybe Later,   Show me more information,Yes
> popups like this are not gentle, they are annoying, users will try to
> get rid of them as soon as they can and go on with what they were doing.
> 

Ok, maybe is no quite gentle for some one, but it is the usually way, speaking 
about Windows users.

> >Please take in mind that we are trying to get a considerable number of new 
> >users. If we just keep doing things like today, we will certainly have new 
> >users, but they probably come from other distributions.
> 
> Seriuosly speaking, i'd like to make a distinguo:
> The real basic(*) user just uses a computer to get her work done, he
> does not give a damn about a new version of firefox, kde or wathever, as
> long as the version she is using is functioning.
> A popup stating about a new version will probably cause a call to her
> son, either before or after having got rid of it, depending on the
> moment.
> The problem with this kind of user is getting them to apply security
> updates.

Are you sure? I'll try to explain me with a practical example: I really don't 
remember what of the versions of the Open Office 3.x branch open the road to 
read and write the MS Office 2007 (docx, etc) but when its happen, it was "the 
great success" How many users really need this particular "goodie", I think a 
big share of them!

> 
> (*) i won't call them novice because they might have been using a
> computer for a good deal of time.
> 
> Another kind of user is amused by computers, he will read some
> semi-technical magazines, every leaflet from big electronic shop, some
> news site, he will buy a lot of gadgets, and will try to install new
> versions of everything, just to see how they work.
> This user is probably interested of seeing backports of firefox, gnome,
> kde, Ooo, and such.
> He will probably not bother with bugzilla (why the  do i have to
> input all this crap, cant they just provide me with gizmo 1.99.2.3 like
> every windows user has?), but probably will do such a request on a forum
> like media.
> 
> we should not mix the needs of this two categories, neither would like
> it.

Ok, I call these users "intermediate users" and here in Mexico we have an 
idiomatic expression for these situations: "El qué quiera azul celeste, ¡que le 
cueste!" A poor translation of that is: If someone want something special, pays 
for get it!
> 
> btw, we also have users interested in backports of stuff like openldap,
> samba or such, these users will actually contribute to the technical
> making of the distro, either by using bugzilla when they find bugs or
> actually doing packaging work. Ignoring the will of such users will,
> sooner or later, force mageia to employ paid personnel to do packaging
> work.
> 
> L.
> 

I disagree here, a big share of the users are sick (including me) of an illness 
called "versionitis gravis". Good I'm sick!:) As I can see there are two 
variants of the illness:

Open Source Type, we are totally involved in each new release of our favourite 
distro, there is no matter how many times we make a promise of stay in the same 
release for at least one year, at the end of the road, we find a "valid" excuse 
for install and use the new version.

Privative Type: There is no matter if their favourite music player is going on, 
each time than appear a new version the users download and i

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-16 02:56, Luca Berra a écrit :

On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:

The basic/novice user doesn't read anything,

remove basic/novice from the sentence and i will agree ;)


doesn't request anything to some like a bugzilla,

but give him a forum and he probably will



This statement I totally agree with! If a user is told to submit in 
bugzilla, I find that they will not do it. Reporting to bugzilla for a 
user, is one more level of serious commitment on their part and most 
will not want to commit themselves to it.


However, if they can report to a forum, this is different. Users view 
forums as community involvement with community feedback. They may be ask 
to test out the problem and report back on the result (just like in 
bugzilla) but they know that other community members will be there to 
lend a hand and support.


If we are going to be really interested in quashing bugs with a lot of 
community involvement, IMHO, I think that we should offer


-- bugzilla for the enthused and commited users. These people are 
interested on reporting bugs the right way and will replicated and help 
in debugging.


-- but for ordinary users, we could offer them a "Report a bug" forum 
where they can report a bug; the community could then replicated the 
bug; have a "Bug-ambassador" or "bug-reporter" or  who could then 
submit it officially on bugzilla. Tracking of that particular bug could 
then be the responsibility of the "Bug-ambassador"; once the bug is 
quashed, the "Bug-ambassador" could report back to the "Report a bug" 
forum of the bug fix and thank the community for their help. This would 
help validate the user who reported the bug and make him/her feel like a 
part of the contributing team.


IMHO, this would work a lot better for the majority of users who do not 
want to commit to any more than reporting the bug; the devs would get a 
more constant stream of bug submissions by "Bug-ambassadors" who are 
able to triage submitted bugs on the forum.


Doing it this way would still make bugzilla the only place where devs 
would go to pick up bug information and the "Bug-ambassadors" would be 
the people who triage the bugs at the forum level.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-16 Thread Renaud MICHEL

Hello
On samedi 16 octobre 2010 at 05:00, Fernando Parra wrote :
> > On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
> > So, we must "dumb down" everything, and not provide openldap backports
> > for people running servers who want a convenient way to run the
> > software version that will allow them to file bugs upstream (OpenLDAP
> > team doesn't respond to bugs filed on non-current releases)?
> 
> Specially here the answer is obvious: The novice doesn't now what is
> OpenLDAP! and maybe he wont hear about it for the rest of his life. New
> versions of OpenLDAP should be stay available in the backports
> repository, not as an automatic available upgrade.

Well, for example like OpenLDAP it is not a problem, because only users that 
need it will install it, and those that might need it are most likely aware 
what it implies to upgrade it to a newer version. So it will not bother 
other users if it is in backports or even updates, because as they won't 
have it installed, they won't be proposed to update.

It is more of a concern for things like cups or dbus, which most users will 
use without knowing it, and won't know how to fix if it breaks (not even 
knowing which package actually broke).

> > What do we do in the case where a new version of some software is
> > available, and has been sent to cooker? How do we decide whether it
> > should go to backports or not? And for which releases?
> > 
> > (FYI, for Mandriva users can typically request backports in bugzilla or
> > on IRC, but we may need better means).
> 
> Ok, first at all, we must deicide what packages (not all of them!) will
> be at the Rolling Ligth model. After that, all this packages must have
> an appropriate path.

I don't understand what you mean by "appropriate path".

I think we should not decide before hand what packages will be backported, 
we should maybe have a (short) list of packages that must not be backported 
(like glibc) and then have backports either when contributors are willing to 
make (and test) them, or on request.

Maybe we could also have a (short also) list of packages that we should 
really try (the packaging team could decide to dedicate some of his 
resources to that) to backport to the latest stable release, and maybe the 
previous latest.
Such packages would be for example firefox or OOo, packages that we know are 
used by many (most) users, and many users are likely to want a newer 
version.

> Anyway, after decide what packages will be in the Rolling Light, The OS
> must be gentle with the user and show a Window with a Message like that:
> 
> There are available a new version of Firefox(as an example). Do you want
> to install it? NO,   Maybe Later,   Show me more information,Yes

A little OT, but:

Dialog windows should (almost) never have yes/no or ok/cancel choices, 
because when an user see a yes/ok choice, he generally interpret it as "yes, 
I want to keep on doing what I was doing". (and I know I have done it some 
times myself)

In your example, the No/yes should be labelled something like "keep current 
version" and "install new version".

cheers
-- 
Renaud Michel

Re: [Mageia-dev] How will be the realese cycle?

2010-10-15 Thread Luca Berra


On Fri, Oct 15, 2010 at 10:00:14PM -0500, Fernando Parra wrote:

The basic/novice user doesn't read anything,

remove basic/novice from the sentence and i will agree ;)


doesn't request anything to some like a bugzilla,

but give him a forum and he probably will


If you show on his screen some like your proposal, he usually take one of two different 
ways: 1) Check all the options or maybe worst 2) Close the window and he will think: 
"Oh hell, Why Linux is so hard?"

then we shall abuse the user like most windows installers do, and
install all sort of crap with preselected checkboxes?


Anyway, after decide what packages will be in the Rolling Light

was the model decided yet?


The OS must be gentle with the user and show a Window with a Message like that:

There are available a new version of Firefox(as an example). Do you want to 
install it?
NO,   Maybe Later,   Show me more information,Yes

popups like this are not gentle, they are annoying, users will try to
get rid of them as soon as they can and go on with what they were doing.


Please take in mind that we are trying to get a considerable number of new 
users. If we just keep doing things like today, we will certainly have new 
users, but they probably come from other distributions.


Seriuosly speaking, i'd like to make a distinguo:
The real basic(*) user just uses a computer to get her work done, he
does not give a damn about a new version of firefox, kde or wathever, as
long as the version she is using is functioning.
A popup stating about a new version will probably cause a call to her
son, either before or after having got rid of it, depending on the
moment.
The problem with this kind of user is getting them to apply security
updates.

(*) i won't call them novice because they might have been using a
computer for a good deal of time.

Another kind of user is amused by computers, he will read some
semi-technical magazines, every leaflet from big electronic shop, some
news site, he will buy a lot of gadgets, and will try to install new
versions of everything, just to see how they work.
This user is probably interested of seeing backports of firefox, gnome,
kde, Ooo, and such.
He will probably not bother with bugzilla (why the  do i have to
input all this crap, cant they just provide me with gizmo 1.99.2.3 like
every windows user has?), but probably will do such a request on a forum
like media.

we should not mix the needs of this two categories, neither would like
it.

btw, we also have users interested in backports of stuff like openldap,
samba or such, these users will actually contribute to the technical
making of the distro, either by using bugzilla when they find bugs or
actually doing packaging work. Ignoring the will of such users will,
sooner or later, force mageia to employ paid personnel to do packaging
work.

L.

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

Re: [Mageia-dev] How will be the realese cycle?

2010-10-15 Thread Fernando Parra

On Fri, 15 Oct 2010 12:42:03 +0100
Buchan Milne  wrote:

Hi Buchan.

First, I believe this is the beginning of a long term friendship, I really love 
your answers, Is very clear for myself we aren't agree in a lot of points, but 
both are looking the same thing, we only differ in the method.

> On Friday, 15 October 2010 03:48:56 Fernando Parra wrote:
> > Hi everybody.
> > 
> > I feel that the concept of a new way, as it exist into my mind is not
> > completely understood. Let me try to re-explain again. Please be patient
> > and excuses any mistake with my English (I'm totally out of practice):
> > 
> > I'm talking about to liberate to novice/novel/without experience user,
> > about concepts like backports, but I'm not talking about
> > close/disappear/eliminate/forgot backports.
> > 
> > Why? because a big share of them will arrive from a very different
> > environment (especially windows), and as you now, in there those concepts
> > are not only estrange, they simply don't exists. When a Windows user
> > wants/needs to update a program, as much the only thing that he/she must
> > do is unninstall the old/previous version and then install the new one.
> > 
> > What programs? Following the same idea, about these kind of users, we
> > should ask: what programs they usually upgrade? The answer could be found
> > asking to the user's themselves, but certainly could be another ways.
> > 
> > Why not all backports? Reason 1: Because a lot of them don't care about the
> > new version of CUPS (in example) or the new version of Maxima (I'm sure
> > there are a lot clearly examples). Reason 2: Because there are packages
> > that may causes some incidents after upgrade them.
> > 
> > How we can solve this situation? Offering a default automatic upgrade for a
> > small group of packages, especially when they change in an important way,
> > in example Firefox 3.6x 3.6x+ or to 4.x
> > 
> > With this in mind:
> > > What aspects of the Mandriva backports solution are not satisfactory?
> > > 
> > > -The fact that not everything is available as a backport?
> > 
> > Not all are in backports, more these users don't want/understand a big
> > share of them
> 
> So, we must "dumb down" everything, and not provide openldap backports for 
> people running servers who want a convenient way to run the software version 
> that will allow them to file bugs upstream (OpenLDAP team doesn't respond to 
> bugs filed on non-current releases)?

Specially here the answer is obvious: The novice doesn't now what is OpenLDAP! 
and maybe he wont hear about it for the rest of his life. New versions of 
OpenLDAP should be stay available in the backports repository, not as an 
automatic available upgrade.

> 
> > > -That users don't know how to request a backport?
> > 
> > That is true, more, they don't want to learn about that, they only want a
> > new version of their favourite program.
> 
> What do we do in the case where a new version of some software is available, 
> and has been sent to cooker? How do we decide whether it should go to 
> backports or not? And for which releases?
> 
> (FYI, for Mandriva users can typically request backports in bugzilla or on 
> IRC, but we may need better means).
> 

Ok, first at all, we must deicide what packages (not all of them!) will be at 
the Rolling Ligth model. After that, all this packages must have an appropriate 
path.

> > > -That too many backports are available?
> > 
> > This is matter of who are revising backports, for novice? Yes there are to
> > many. For the geek or the expert? Maybe never there will enough of them.
> > 
> > > -That all users don't get them by default?
> > > -That users doing network installs by default don't get the backport on
> > > initial installation?
> > 
> > No, they are not get them if we will use a potentially problematic
> > repository.
> > 
> > > -That users aren't aware of backports?
> > > -Something else?
> > 
> > Panic? Fear? Baal, Luzbel and other demons in their minds?
> > 
> > > Technically speaking?
> > > Less than 'urpmi --searchmedia Backports chromium' ?
> > 
> > If I was a novice my answer will be: What hell is that?
> 
> This was a response to 'users must do less', not 'it must be very easy'. At 
> present, users need to do just one thing. We can fix the ease of doing that 
> one thing, if we understand the problem correctly.

Some times easy doesn't means "do less", I think in this particular case must 
means Understandable.

> 
> I note you chose to leave out:
> 
> > > Or, should it be more obvious in rpmdrake or similar? How about
> > > commenting on my proposal for UI change in rpmdrake making backports
> > > more obvious?
> 
> The proposal I refer to is:
> "
> Now, maybe the user interface needs to be improved. For example, maybe there 
> should be no dropdown box, but instead when searching for a package by name, 
> it should show you all the versions:
> 
> 
> Find: | di

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Ahmad Samir

On 15 October 2010 04:48, Fernando Parra  wrote:
> Hi everybody.
>
> I feel that the concept of a new way, as it exist into my mind is not 
> completely understood. Let me try to re-explain again. Please be patient and 
> excuses any mistake with my English (I'm totally out of practice):
>
> I'm talking about to liberate to novice/novel/without experience user, about 
> concepts like backports, but I'm not talking about 
> close/disappear/eliminate/forgot backports.
>
> Why? because a big share of them will arrive from a very different 
> environment (especially windows), and as you now, in there those concepts are 
> not only estrange, they simply don't exists.
> When a Windows user wants/needs to update a program, as much the only thing 
> that he/she must do is unninstall the old/previous version and then install 
> the new one.
>
> What programs? Following the same idea, about these kind of users, we should 
> ask: what programs they usually upgrade? The answer could be found asking to 
> the user's themselves, but certainly could be another ways.
>
> Why not all backports? Reason 1: Because a lot of them don't care about the 
> new version of CUPS (in example) or the new version of Maxima (I'm sure there 
> are a lot clearly examples).
> Reason 2: Because there are packages that may causes some incidents after 
> upgrade them.
>
> How we can solve this situation? Offering a default automatic upgrade for a 
> small group of packages, especially when they change in an important way, in 
> example Firefox 3.6x 3.6x+ or to 4.x
>
> With this in mind:
>
>> What aspects of the Mandriva backports solution are not satisfactory?
>
>> -The fact that not everything is available as a backport?
>
> Not all are in backports, more these users don't want/understand a big share 
> of them
>
>> -That users don't know how to request a backport?
>
> That is true, more, they don't want to learn about that, they only want a new 
> version of their favourite program.
>
>> -That too many backports are available?
>
> This is matter of who are revising backports, for novice? Yes there are to 
> many. For the geek or the expert? Maybe never there will enough of them.
>
>> -That all users don't get them by default?
>> -That users doing network installs by default don't get the backport on
>> initial installation?
>
> No, they are not get them if we will use a potentially problematic repository.
>
>> -That users aren't aware of backports?
>> -Something else?
>
> Panic? Fear? Baal, Luzbel and other demons in their minds?
>
>> Technically speaking?
>> Less than 'urpmi --searchmedia Backports chromium' ?
>
> If I was a novice my answer will be: What hell is that?
>
>> Again, before we can decide what *more* we should do (what significant
>> resources we need to commit), maybe we should first understand why the
>> existing features (which have significant effort behind them) are not
>> resulting in user satisfaction.
>
> More and more reasons to prepare very carefully our offer. All we here 
> appreciate those efforts and there are no way to send them to trash
>
>> Personally I think a poll without educating everyone about what exactly
>> each choice would mean is useless. We first need to elaborate detailed
>> alternatives before anyone can make an informed choice.
>
> IMHO, a democracy without education is not democracy, is populism. I agree at 
> all, we need first elaborate a well structured alternatives and then, 
> explicitly after inform and educate our community we can run a poll, or 
> prepare a council, or any other appropriated way.
>
>> backports should be supported for security patches and bug fixes just like
>> the main packages (if not instead of the main packages).
>> Of course the security patch could be simply provided by backporting a
>> newer version of the package, no need to make patches for each version.
>
> That is essential, any upgrade must be supported (other valid reason for an 
> small group of packages).
>
>> What I mean is basically when new updates get presented (which would
>> include new backports) the user could untick specific packages (as is
>> possible now) but also have a second tick-box to store the choice
>> permanently in the skip.list.
>> This would give the user more choice of which packages he wants to always
>> update to the newest version and wich ones he/she prefers to keep frozen
>> at the same version.
>
> Please try to explain that to my grandma, or maybe you could be lucky with 
> some of my students.
>
>> New users who frequented the forums always got to know what backports
>> are pretty fast. And bugzilla is the perfect system for asking for a
>> backport, that worked pretty good.
>
> These users are walking to change into intermediate users, they are no longer 
> basic users. This only for the simple fact that they are posting in a 
> technical forum. Let me remind you: 1,300 millions of Hispanics and only 130 
> votes at the BlogDrake poll.
>
>> I was thinking about writing a pro

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Fernando Parra

Hi everybody.

I feel that the concept of a new way, as it exist into my mind is not 
completely understood. Let me try to re-explain again. Please be patient and 
excuses any mistake with my English (I'm totally out of practice):

I'm talking about to liberate to novice/novel/without experience user, about 
concepts like backports, but I'm not talking about 
close/disappear/eliminate/forgot backports.

Why? because a big share of them will arrive from a very different environment 
(especially windows), and as you now, in there those concepts are not only 
estrange, they simply don't exists.
When a Windows user wants/needs to update a program, as much the only thing 
that he/she must do is unninstall the old/previous version and then install the 
new one.

What programs? Following the same idea, about these kind of users, we should 
ask: what programs they usually upgrade? The answer could be found asking to 
the user's themselves, but certainly could be another ways.

Why not all backports? Reason 1: Because a lot of them don't care about the new 
version of CUPS (in example) or the new version of Maxima (I'm sure there are a 
lot clearly examples).
Reason 2: Because there are packages that may causes some incidents after 
upgrade them.

How we can solve this situation? Offering a default automatic upgrade for a 
small group of packages, especially when they change in an important way, in 
example Firefox 3.6x 3.6x+ or to 4.x

With this in mind:

> What aspects of the Mandriva backports solution are not satisfactory?

> -The fact that not everything is available as a backport?

Not all are in backports, more these users don't want/understand a big share of 
them

> -That users don't know how to request a backport?

That is true, more, they don't want to learn about that, they only want a new 
version of their favourite program.

> -That too many backports are available?

This is matter of who are revising backports, for novice? Yes there are to 
many. For the geek or the expert? Maybe never there will enough of them.
 
> -That all users don't get them by default?
> -That users doing network installs by default don't get the backport on 
> initial installation?

No, they are not get them if we will use a potentially problematic repository.

> -That users aren't aware of backports?
> -Something else?

Panic? Fear? Baal, Luzbel and other demons in their minds?

> Technically speaking?
> Less than 'urpmi --searchmedia Backports chromium' ?

If I was a novice my answer will be: What hell is that?

> Again, before we can decide what *more* we should do (what significant 
> resources we need to commit), maybe we should first understand why the 
> existing features (which have significant effort behind them) are not 
> resulting in user satisfaction.

More and more reasons to prepare very carefully our offer. All we here 
appreciate those efforts and there are no way to send them to trash

> Personally I think a poll without educating everyone about what exactly
> each choice would mean is useless. We first need to elaborate detailed
> alternatives before anyone can make an informed choice.

IMHO, a democracy without education is not democracy, is populism. I agree at 
all, we need first elaborate a well structured alternatives and then, 
explicitly after inform and educate our community we can run a poll, or prepare 
a council, or any other appropriated way. 

> backports should be supported for security patches and bug fixes just like
> the main packages (if not instead of the main packages).
> Of course the security patch could be simply provided by backporting a
> newer version of the package, no need to make patches for each version.

That is essential, any upgrade must be supported (other valid reason for an 
small group of packages).

> What I mean is basically when new updates get presented (which would
> include new backports) the user could untick specific packages (as is
> possible now) but also have a second tick-box to store the choice
> permanently in the skip.list.
> This would give the user more choice of which packages he wants to always
> update to the newest version and wich ones he/she prefers to keep frozen
> at the same version.

Please try to explain that to my grandma, or maybe you could be lucky with some 
of my students.

> New users who frequented the forums always got to know what backports
> are pretty fast. And bugzilla is the perfect system for asking for a
> backport, that worked pretty good.

These users are walking to change into intermediate users, they are no longer 
basic users. This only for the simple fact that they are posting in a technical 
forum. Let me remind you: 1,300 millions of Hispanics and only 130 votes at the 
BlogDrake poll.

> I was thinking about writing a proposal as you suggested, but so far I 
> haven't found the time.
> I don't think this is that urgent, since backports only become an issue 
> once we have the first release out, but I will try to write up

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Margot

On Thu, 14 Oct 2010 16:29:28 +0200
"Romain d'Alverny"  wrote:

> Does anyone take notes to summarize and make a consistent
> proposal (be it in some way or the other) of what should be done,
> as well as defining some sort of personas for users (unaware,
> new, occasional, frequent, expert) for evaluation?
> 
> Romain

Initially, ALL Mageia users will be 'new'!  But there are different
types of 'new'...

When I have persuaded people to try Mandriva in the past, if they
were experienced Linux users I always suggested they join both the
'newbie' and 'expert' mailing lists - even if they knew a lot about
other distros, they might still have needed newbie-level help with
features that were Mandriva-specific.

-- 
Margot
~~ 
**Otford Ducks Computers**
We teach, you learn...
...and, if you don't do your homework, we set the cat on you!
~~

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 13:05, Tux99 a écrit :

On Thu, 14 Oct 2010, Maurice Batey wrote:


However, I then found that the new version of VLC had problems with
DVD menus, and the new CUPS introduced problems (not just in my
installation but at least one other Mandriva user).


I would put this down to the fact that currently in Mandriva backports
are given little attention by the packagers (as has been mentioned by
the Mandriva packagers here themselves).
Of course if we make them more central to the Mageia strategy then more
care and testing is needed before a backport is pushed out.
So I wouldn't consider that a fundamental issue with backports, just a
procedural issue.
Also personally I would consider CUPS a core app so I wouldn't have
included that in backports at all.




Yup. That was my comment on the Mandriva news group. If a package 
affects the core or a large amount of other sofware packages, I, myself, 
would avoid installing it from the "Backports". If the updated CUPS was 
such a great upgrade, then I would imagine that the Mandriva devs would 
have included it as a normal update and not a "Backport" upgrade. 
Backport is great for VLC, Digikam, Amarok updates. But as Maurice 
mentioned the VLC didn't have the dvdnav plugin with the upgrade ... so 
there may be some hiccups from time to time with some of the software 
upgrades.


Marc

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 12:42, Romain d'Alverny a écrit :

On Thu, Oct 14, 2010 at 18:32, Marc Paré  wrote:

Is there a dedicated mailist for the leaders of the different communities?
It would probably make sense to have a closed list for them to coordinate
projects such as polls, marketing, sharing of resource materials agreemtns
etc. Just a place where they could meet and conference to build consensus on
different issues.

Does this exist? Do we have a list of all the communities that have come
on-board to the project?


You mean, the Mageia Community Council? or something else?

We're in the process to setup the Council, but we will need each team
to coordinate on its own first (so we're blocked by the mailing-list
availability, which should come soon - we've been delayed because of
hosting issues).

Romain



Merci Romain

I guess this is it. Ok, work in progress.

Do we have an on-going list the different communities published that 
have joined somewhere on the website? Just curious.


Marc

Re: [Mageia-dev] How will be the realese cycle?

On Thu, 14 Oct 2010, Maurice Batey wrote:

> However, I then found that the new version of VLC had problems with
> DVD menus, and the new CUPS introduced problems (not just in my
> installation but at least one other Mandriva user).

I would put this down to the fact that currently in Mandriva backports 
are given little attention by the packagers (as has been mentioned by 
the Mandriva packagers here themselves).
Of course if we make them more central to the Mageia strategy then more 
care and testing is needed before a backport is pushed out.
So I wouldn't consider that a fundamental issue with backports, just a 
procedural issue.
Also personally I would consider CUPS a core app so I wouldn't have 
included that in backports at all.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Maurice Batey

On Thu, 14 Oct 2010 17:33:31 +0200, Tux99 wrote:

> I have been using backports on all my PCs and enabled them on all PCs of 
> friends whom I installed Mandriva and so far I have yet to see a single 
> breakage caused by backports.

  Having never had Backports enabled, I was encouraged by postings
here to try it.  Several app's were updated (e.g. VLC, CUPS).

However, I then found that the new version of VLC had problems with
DVD menus, and the new CUPS introduced problems (not just in my
installation but at least one other Mandriva user).

So I have reverted my Root partition to its state before the Backports
update, and all is well again.

My experience tells me that I should only use Backports - temporarily
- when looking for an update to some application, i.e. not as a source
for regular overall software updates.

-- 
/\/\aurice 
(Retired in Surrey, UK) Registered Linux User #487649
 Linux Mandriva 2010.0 32-bit  PowerPack (i686 kernel) 
   KDE 4.4.3   Virtualbox 3.2.6 Firefox 3.6.10

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Romain d'Alverny

On Thu, Oct 14, 2010 at 18:32, Marc Paré  wrote:
> Is there a dedicated mailist for the leaders of the different communities?
> It would probably make sense to have a closed list for them to coordinate
> projects such as polls, marketing, sharing of resource materials agreemtns
> etc. Just a place where they could meet and conference to build consensus on
> different issues.
>
> Does this exist? Do we have a list of all the communities that have come
> on-board to the project?

You mean, the Mageia Community Council? or something else?

We're in the process to setup the Council, but we will need each team
to coordinate on its own first (so we're blocked by the mailing-list
availability, which should come soon - we've been delayed because of
hosting issues).

Romain

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 10:50, nicolas vigier a écrit :

On Thu, 14 Oct 2010, Tux99 wrote:



I think they should be enabled by default, since it's my impression that
the majority of 'normal' users wants new versions of apps, those users who
DON'T want them can still always disable them.


If backports repository is enabled by default, it should be stable. How
do you garantee that backports will never break ?


Backports shouldn't be second choice, it should be the default, since that
would make Mageia stand out from other distros as being the distro were
users get the latest versions of apps before any other major distro
provides them.


Just providing the latest version of apps is not enough to "stand out
from other distros". All distros could do it, and they usually already
do it in their developement version. But the problem is always the same:
adding new versions create instability.




Actually, there is a thread on the Mandriva nntp where the latest CUPS 
in backports break the install. So we are passing the word to people 
about this. DO NOT INSTALL THE CUPS backports, it may break your Mdv 
installation.


I think the "Backport" name should just be changed to a more descriptive 
name and an info button (bubble or Wiki link) describing its intended 
use to the users.


There is a thread on the Mandriva nntp discussing the use of "Backport" 
(I started it) as many users had no idea what it meant or the reason 
behind it. We (users) are ill-informed of its purpose. But ... I like 
it, and I think it should stay, but in a renamed form and for all users 
to use ... maybe also add a "user help" link on that particular page 
where users could turn to for help.


IMHO, what makes or breaks a distro is the communication and the help 
users get from their knowledgeable counterparts. Use-help and 
Documentation should be front and centre to the distro.


IMHO, if you have enough experience, then you should be helping out on 
the "user help" mailists and "user help" forums to help out those in 
need of help.


Marc

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 10:56, Sinner from the Prairy a écrit :

Tux99 wrote:


I guess the old rule of polls applies:
depending on how you formulate the poll question and the description of
the options you can hugely influence the results...


This is so true.

I follow the politics blog FiveThirtyEight (warning! statistics nerd alert
activated!) and again and again, strange-resulting polls are caused by
poorly formulated questions, "guided" answers or lack of proper options.


Personally I think a poll without educating everyone about what exactly
each choice would mean is useless. We first need to elaborate detailed
alternatives before anyone can make an informed choice.


This is mostly what Romain has been asking: someone to provide clear
definitions of what Rolling Release is. And why Backports does not work.


Salut,
Sinner




Is there a dedicated mailist for the leaders of the different 
communities? It would probably make sense to have a closed list for them 
to coordinate projects such as polls, marketing, sharing of resource 
materials agreemtns etc. Just a place where they could meet and 
conference to build consensus on different issues.


Does this exist? Do we have a list of all the communities that have come 
on-board to the project?


Marc

Re: [Mageia-dev] How will be the realese cycle?

On Thu, 14 Oct 2010, nicolas vigier wrote:

> Experience tells me that backports break much more than regular
> security/bugfix updates.

Do you have any examples?

I have been using backports on all my PCs and enabled them on all PCs of 
friends whom I installed Mandriva and so far I have yet to see a single 
breakage caused by backports.

My desktop PC is still running 2008.1 to which I have personally 
backported loads of apps even from 2011 cooker, without any issues.
Granted, I was unable to backport some apps due to the great difference 
in lib versions, but that's to be expected when considering 2008.1 is 
2.5 years old. But all apps that built fine, work fine.

There was on the other hand a huge breakage caused by a normal 
bugfix update of KDE4 in 2009.0 that caused KDE3.5 to completely break 
for all users that had chosoen KDE3.5 (which was still supported in 2009.0).

> The software itself can be more stable, but not the integration with
> the other software.

Why do you say that?

It's all a matter of due care and obviously of avoiding backports 
of things like KDE or other core stuff.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread nicolas vigier

On Thu, 14 Oct 2010, Tux99 wrote:

> On Thu, 14 Oct 2010, nicolas vigier wrote:
> 
> > On Thu, 14 Oct 2010, Tux99 wrote:
> >
> > > I think they should be enabled by default, since it's my impression that
> > > the majority of 'normal' users wants new versions of apps, those users who
> > > DON'T want them can still always disable them.
> > 
> > If backports repository is enabled by default, it should be stable. How
> > do you garantee that backports will never break ?
> 
> Nicolas, please re-read old posts of this thread we discussed this 
> already, the conclusion was that there are no guarantees in 
> life. Experience tells us backports don't normally break any more than 
> the regular security/bugfix updates.

Experience tells me that backports break much more than regular
security/bugfix updates.

> > > Backports shouldn't be second choice, it should be the default, since that
> > > would make Mageia stand out from other distros as being the distro were
> > > users get the latest versions of apps before any other major distro
> > > provides them.
> > 
> > Just providing the latest version of apps is not enough to "stand out
> > from other distros".
> 
> I didn't say this should be the ONLY unique feature of Mageia.
> 
> > All distros could do it, and they usually already do it in their 
> > developement version. But the problem is always the same:
> > adding new versions create instability.
> 
> All distros COULD do it but they don't, the dev version doesn't count
> as that is obviously much more unstable, since it's meant for 
> experimenting.

They could do it, but they don't do it in the stable branch. Maybe there
is a reason ?

> Providing new versions usually gives MORE stability since newer version 
> normally include loads of bug fixes too, but again we debated this 
> already, see old posts in this thread.

The software itself can be more stable, but not the integration with
the other software.

This was debated already, but you're still not answering the question
about how you can guarantee that it will be stable enough (the
integration between all the software, not only the software themself).

Re: [Mageia-dev] How will be the realese cycle?

On Thu, 14 Oct 2010, nicolas vigier wrote:

> On Thu, 14 Oct 2010, Tux99 wrote:
>
> > I think they should be enabled by default, since it's my impression that
> > the majority of 'normal' users wants new versions of apps, those users who
> > DON'T want them can still always disable them.
> 
> If backports repository is enabled by default, it should be stable. How
> do you garantee that backports will never break ?

Nicolas, please re-read old posts of this thread we discussed this 
already, the conclusion was that there are no guarantees in 
life. Experience tells us backports don't normally break any more than 
the regular security/bugfix updates.

> > Backports shouldn't be second choice, it should be the default, since that
> > would make Mageia stand out from other distros as being the distro were
> > users get the latest versions of apps before any other major distro
> > provides them.
> 
> Just providing the latest version of apps is not enough to "stand out
> from other distros".

I didn't say this should be the ONLY unique feature of Mageia.

> All distros could do it, and they usually already do it in their 
> developement version. But the problem is always the same:
> adding new versions create instability.

All distros COULD do it but they don't, the dev version doesn't count
as that is obviously much more unstable, since it's meant for 
experimenting.

Providing new versions usually gives MORE stability since newer version 
normally include loads of bug fixes too, but again we debated this 
already, see old posts in this thread.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Sinner from the Prairy

Tux99 wrote:

> I guess the old rule of polls applies:
> depending on how you formulate the poll question and the description of
> the options you can hugely influence the results...

This is so true.

I follow the politics blog FiveThirtyEight (warning! statistics nerd alert 
activated!) and again and again, strange-resulting polls are caused by 
poorly formulated questions, "guided" answers or lack of proper options.

> Personally I think a poll without educating everyone about what exactly
> each choice would mean is useless. We first need to elaborate detailed
> alternatives before anyone can make an informed choice.

This is mostly what Romain has been asking: someone to provide clear 
definitions of what Rolling Release is. And why Backports does not work.

Salut,
Sinner

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread nicolas vigier

On Thu, 14 Oct 2010, Tux99 wrote:

> 
> I think they should be enabled by default, since it's my impression that
> the majority of 'normal' users wants new versions of apps, those users who
> DON'T want them can still always disable them.

If backports repository is enabled by default, it should be stable. How
do you garantee that backports will never break ?

> Backports shouldn't be second choice, it should be the default, since that
> would make Mageia stand out from other distros as being the distro were
> users get the latest versions of apps before any other major distro
> provides them.

Just providing the latest version of apps is not enough to "stand out
from other distros". All distros could do it, and they usually already
do it in their developement version. But the problem is always the same:
adding new versions create instability.

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Sinner from the Prairy

Tux99 wrote:
> Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:00

>> Enabling them by default defies the purpose of having backports at
>> all; it's not for new users, it's more for slightly experienced users
>> or power users who want the latest versions of apps.

> That's exactly the crucial bit that IMHO needs to change, backports are
> very interesting for 'normal' users so we should make sure normal users
> can use them.

I believe you are both right:

* backports are for power users
* Mandriva/Mageia are power users [*]

[*] 1. they chose Linux. 2. They chose a "Not Ubuntu" distro 

So, what about?

1. Changing name of backports to something more dscriptive
2. Making backports part of official repos
3. NOT activating backports repo by default.

Salut,
Sinner

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 10:29, Romain d'Alverny a écrit :

Does anyone take notes to summarize and make a consistent proposal (be
it in some way or the other) of what should be done, as well as
defining some sort of personas for users (unaware, new, occasional,
frequent, expert) for evaluation?

Romain



That was what I was wondering. These discussions are only fruitful if 
someone is taking notes. Sometimes the threads are too "fast and 
furious" and notes/proposals are not even considered.


We should try to organize these discussions a little better to be more 
productive.


Marc

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 09:53, Tux99 a écrit :



Just to add to my last post:
It would be useful if users could disable specifc packages from being
updated via the update GUI.
What I mean is basically when new updates get presented (which would
include new backports) the user could untick specific packages (as is
possible now) but also have a second tick-box to store the choice
permanently in the skip.list.
This would give the user more choice of which packages he wants to always
update to the newest version and wich ones he/she prefers to keep frozen
at the same version.


This is a great idea. Someone should make a note of it.

Marc

Re: [Mageia-dev] How will be the realese cycle?

On Thu, 14 Oct 2010, Romain d'Alverny wrote:

> Does anyone take notes to summarize and make a consistent proposal (be
> it in some way or the other) of what should be done, as well as
> defining some sort of personas for users (unaware, new, occasional,
> frequent, expert) for evaluation?

I was thinking about writing a proposal as you suggested, but so far I 
haven't found the time.
I don't think this is that urgent, since backports only become an issue 
once we have the first release out, but I will try to write up a 
proposal well before that.

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 09:57, Tux99 a écrit :



Quote: marc wrote on Thu, 14 October 2010 15:49


Is it me or is the poll different? The overall feeling on the Spanish
Blogdrake is to "like Mandriva a stable system with upgrades and
backports" at 58%. I imagine this means keeping to Mandriva release
cycle with no changes.

Wouldn't it make sense to have the same poll? I guess, this way we
still
get the results of a poll and a sense of the community feeling anyway.


I guess the old rule of polls applies:
depending on how you formulate the poll question and the description of the
options you can hugely influence the results...

Personally I think a poll without educating everyone about what exactly
each choice would mean is useless. We first need to elaborate detailed
alternatives before anyone can make an informed choice.



I agree. However, I would view these polls as both a way to inform 
people and a short measure of what the community members think at this 
point. It does hold a little value. I am not sure if we all really 
understand the meaning behind "rolling distro", but the polls still do 
give a little value at this point in time.


If we are going to poll communities, the community leaders should really 
get together and decide on the process and questions so that the 
information collected is valuable. But Ok, this way we still get a 
little data to look at.


Marc

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Romain d'Alverny

Does anyone take notes to summarize and make a consistent proposal (be
it in some way or the other) of what should be done, as well as
defining some sort of personas for users (unaware, new, occasional,
frequent, expert) for evaluation?

Romain

Re: [Mageia-dev] How will be the realese cycle?



Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:21

> Then you're not talking about new users any more...

I don't know what you mean by new users, but I was talking about 'normal'
user by which I mean general users without technical background (like my
wife for example :) ), people that have used a computer before, but not
necessarily with Linux, just an average Windows user for example.
-- 
Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Ahmad Samir

On 14 October 2010 16:14, Tux99  wrote:
>
>
> Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:00

[]
>>
>> Enabling them by default defies the purpose of having backports at
>> all; it's not for new users, it's more for slightly experienced users
>> or power users who want the latest versions of apps.
>
> That's exactly the crucial bit that IMHO needs to change, backports are
> very interesting for 'normal' users so we should make sure normal users
> can use them.
> Don't you see how attractive it is especially for 'normal' users to have
> access to the latest versions all the time?
> Sure, not everyone wants them, but by integrating the skip.list in the
> update GUI we could keep 'conservative' users happy too.
>

Then you're not talking about new users any more...

-- 
Ahmad Samir

Re: [Mageia-dev] How will be the realese cycle?



Quote: Ahmad Samir wrote on Thu, 14 October 2010 16:00
>
> I've seen, too many times, trigger-happy packagers backporting
> packages that're not maintained by them (so they know it less than
> those package maintainer(s)), breaking those packages and annoying the
> maintainers of said packages. It's usually irresponsible to backport a
> package without taking that package maintainer's opinion into account.
> (an infamous example on that is gwibber being backported to 2010.1).

I agree it should be preferably the maintainer doing the backport, or he
should at least be consulted.
 
> New users who frequented the forums always got to know what backports
> are pretty fast. And bugzilla is the perfect system for asking for a
> backport, that worked pretty good.

The wast majority of 'normal' users never uses the forum.
Backports shouldn't be something that only users who frequent the forum
find out about.

> That's they way backports has always worked, no specific patches, just
> the latest cooker package pushed to backports "as is with no official
> support", that's reasonable, packagers shouldn't promise to support
> backports when they can't due to various reasons (time, effort.. etc).

But IMHO that should change in Mageia, we should promise support by the way
of timely updates, especially when security issues are present.

> > Backports shouldn't be second choice, it should be the default,
> > since that
> > would make Mageia stand out from other distros as being the distro
> > were
> > users get the latest versions of apps before any other major
> > distro
> > provides them.
> 
> Enabling them by default defies the purpose of having backports at
> all; it's not for new users, it's more for slightly experienced users
> or power users who want the latest versions of apps.

That's exactly the crucial bit that IMHO needs to change, backports are
very interesting for 'normal' users so we should make sure normal users
can use them.
Don't you see how attractive it is especially for 'normal' users to have
access to the latest versions all the time?
Sure, not everyone wants them, but by integrating the skip.list in the
update GUI we could keep 'conservative' users happy too.


-- 
Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/

Re: [Mageia-dev] How will be the realese cycle?

2010-10-14 Thread Ahmad Samir

On 14 October 2010 15:41, Tux99  wrote:
>
>
> Quote: Buchan Milne wrote on Thu, 14 October 2010 15:27
>
>> What aspects of the Mandriva backports solution are not satisfactory?
>>
>> -The fact that not everything is available as a backport?
>
> Yes, more packages should be available
> (and as future packager I will do my part to make that happen)

Well, backporting a package is a one-liner, so it takes less than
minute to be done; that's not the issue. The issue is that a new
version of package A may need a new version or package B to work, so
package B needs to be backported too; and/or that the new version of A
doesn't work with older libs/kernels, so backporting isn't too much
time consuming for packagers, but making sure that that backport has a
good chance of working(tm) is the bigger burden/responsibility.

I've seen, too many times, trigger-happy packagers backporting
packages that're not maintained by them (so they know it less than
those package maintainer(s)), breaking those packages and annoying the
maintainers of said packages. It's usually irresponsible to backport a
package without taking that package maintainer's opinion into account.
(an infamous example on that is gwibber being backported to 2010.1).

>
>> -That users don't know how to request a backport?
>
> It certainly could help publicizing backports and giving the user an easy
> way to request specific packages

New users who frequented the forums always got to know what backports
are pretty fast. And bugzilla is the perfect system for asking for a
backport, that worked pretty good.

[...]

>> -That users aren't aware of backports?
>
> Yes, backports should be promoted better in drakrpm and in the web site.
>
>> -Something else?
>
> backports should be supported for security patches and bug fixes just like
> the main packages (if not instead of the main packages).
> Of course the security patch could be simply provided by backporting a
> newer version of the package, no need to make patches for each version.
>

That's they way backports has always worked, no specific patches, just
the latest cooker package pushed to backports "as is with no official
support", that's reasonable, packagers shouldn't promise to support
backports when they can't due to various reasons (time, effort.. etc).

>> > The end users need to do less than now for to get new versions of
>> > their
>> > favourites applications.
>>
>> Less than 'urpmi --searchmedia Backports chromium' ?
>
> CLI is not ideal for 'normal' users.
>

rpmdrake has a "Backports" filter that shows packages from backports
repos, that's easy to use even for new users.

>> Or, should it be more obvious in rpmdrake or similar?
>
> I think they should be enabled by default, since it's my impression that
> the majority of 'normal' users wants new versions of apps, those users who
> DON'T want them can still always disable them.
>
> Backports shouldn't be second choice, it should be the default, since that
> would make Mageia stand out from other distros as being the distro were
> users get the latest versions of apps before any other major distro
> provides them.
>

Enabling them by default defies the purpose of having backports at
all; it's not for new users, it's more for slightly experienced users
or power users who want the latest versions of apps.

-- 
Ahmad Samir

Re: [Mageia-dev] How will be the realese cycle?



Quote: marc wrote on Thu, 14 October 2010 15:49
>
> Is it me or is the poll different? The overall feeling on the Spanish 
> Blogdrake is to "like Mandriva a stable system with upgrades and 
> backports" at 58%. I imagine this means keeping to Mandriva release 
> cycle with no changes.
> 
> Wouldn't it make sense to have the same poll? I guess, this way we
> still 
> get the results of a poll and a sense of the community feeling anyway.

I guess the old rule of polls applies:
depending on how you formulate the poll question and the description of the
options you can hugely influence the results...

Personally I think a poll without educating everyone about what exactly
each choice would mean is useless. We first need to elaborate detailed
alternatives before anyone can make an informed choice.

-- 
Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/

Re: [Mageia-dev] How will be the realese cycle?



Just to add to my last post:
It would be useful if users could disable specifc packages from being
updated via the update GUI.
What I mean is basically when new updates get presented (which would
include new backports) the user could untick specific packages (as is
possible now) but also have a second tick-box to store the choice
permanently in the skip.list.
This would give the user more choice of which packages he wants to always
update to the newest version and wich ones he/she prefers to keep frozen
at the same version.
-- 
Mageia ML Forum Gateway: http://mageia.linuxtech.net/forum/

Re: [Mageia-dev] How will be the realese cycle?


Le 2010-10-14 09:08, Sinner from the Prairy a écrit :

Marc Paré wrote:


Thanks for posting the site Tux99. There was talk of more user groups
doing the poll/survey. Does anyone know if this is being done? Great
data for the devs to consider.

Marc


This in the Spanish-speaking Mandriva community BlogDrake:


http://blogdrake.net/encuesta/que-tipo-de-ciclo-de-releases-deberia-tener-
mageia

In case the URL gets cut, here it is shortened with Bit.ly:

  http://bit.ly/am7Ivg


Salut,
Sinner




Gracias Sinner:

Is it me or is the poll different? The overall feeling on the Spanish 
Blogdrake is to "like Mandriva a stable system with upgrades and 
backports" at 58%. I imagine this means keeping to Mandriva release 
cycle with no changes.


Wouldn't it make sense to have the same poll? I guess, this way we still 
get the results of a poll and a sense of the community feeling anyway.


Marc

Re: [Mageia-dev] How will be the realese cycle?