Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Dimitrios Glentadakis
2010/10/7 Kira 

> 在 Thu, 07 Oct 2010 13:29:25 +0800, Ahmad Samir  >寫道:
>
>  No, konqueror is still useful as a file manager (some users don't like
>> dolphin for some  reason), also as a man pages viewer. Also it shares
>> some code with dolphin (some stuff/features don't work in dolphin if
>> konqueror isn't installed).
>>
>>  That part of code should be split as independent share package, isn't it?
>
> Also, is it possible to use other browsers to do the same job? I think
>
> Konqueror should only in the full task package set you install kde4
> (task-kde4),
>
> not in the core task package set (task-kde4-minimal).
>


For me, Konqueror is the main application in my system. file manager and
browser. May be for others too

-- 
Dimitrios Glentadakis


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Graham Lauder
On Thursday 07 Oct 2010 19:11:45 Mihai Dobrescu wrote:
> I think that I read somewhere that Mandriva *started *as KDE centric.
> AFAIK, Gnome, KDE and some other popular DE are supported and Mandriva
> spent an important effort to make them look alike from the main menu and
> other customizations point of view.
> As file browsers I like Dolphin, Konqueror and I use Krusader a lot.
> As internet browser, Firefox is my favorite, although I use Opera
> occasionally (it's ergonomic, free but not open sourced). I would like to
> see Firefox having Chrome's architecture (each tab in its process) and less
> memory consumer (this is due to plugins too - the pluggable architecture is
> what makes me stick with it).


Don't kill konqueror it's my default ftp client.  

There are already a bunch of Gnome centric distros.

KDE centric would be no issue nobody else is so in fact it would be a 
excellent point of difference.  In fact, if it was my decision I'd leave Gnome 
to Ubuntu, Redhat, CentOS, Debian, Solaris and all those Gnome centric distros 
and concentrate on being the best KDE environment.

Cheers
GL 


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Ahmad Samir
On 7 October 2010 09:21, Graham Lauder  wrote:
> On Thursday 07 Oct 2010 19:11:45 Mihai Dobrescu wrote:
>> I think that I read somewhere that Mandriva *started *as KDE centric.
>> AFAIK, Gnome, KDE and some other popular DE are supported and Mandriva
>> spent an important effort to make them look alike from the main menu and
>> other customizations point of view.
>> As file browsers I like Dolphin, Konqueror and I use Krusader a lot.
>> As internet browser, Firefox is my favorite, although I use Opera
>> occasionally (it's ergonomic, free but not open sourced). I would like to
>> see Firefox having Chrome's architecture (each tab in its process) and less
>> memory consumer (this is due to plugins too - the pluggable architecture is
>> what makes me stick with it).
>
>
> Don't kill konqueror it's my default ftp client.
>
> There are already a bunch of Gnome centric distros.
>
> KDE centric would be no issue nobody else is so in fact it would be a
> excellent point of difference.  In fact, if it was my decision I'd leave Gnome
> to Ubuntu, Redhat, CentOS, Debian, Solaris and all those Gnome centric distros
> and concentrate on being the best KDE environment.
>
> Cheers
> GL
>

I think all DE's should be supported as much as possible. Even in
Mandriva, which theoretically was a KDE-centric distro, both KDE and
GNOME were equally supported AFAICS.

-- 
Ahmad Samir


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Sorteal
On Thu, 2010-10-07 at 00:22 -0400, andré wrote:
> Sorteal a écrit :
> > On Thu, 2010-10-07 at 04:01 +0200, Wolfgang Bornath wrote:
> >
> >> 2010/10/7 Marc Paré:
> >>  
> >>> I guess this information would have to come from someone from the core dev
> >>> group. Just so that we know for sure. So, is Mageia going to be 
> >>> principally
> >>> a KDE distro with offers during installation to install GNOME and other
> >>> desktops? Or is it going to be a desktop agnostic distro where the user
> >>> eventually picks the desktop sometime during the installation processs?
> >>>
> >>> This may help with this thread on the talk of browsers.
> >>>
> >> Pls correct me if I'm wrong but I don't know any browser which is DE
> >> dependent - well, there's konqueror, if you want to call this "I want
> >> to be everything" a browser. But for real browsers, what does it
> >> matter which DE is used?
> >>  
> > While Mandriva officially supported both GNOME and KDE, I do remember
> > the last time I tried the GNOME version of Mandriva it was pretty much a
> > raw GNOME install.  It had no changes to the default options such as, a
> > web browser type of tool bar, and opening new folders in the same
> > window.  After trying to get to a video and finding I now had 5 windows
> > opened I assumed Mandriva's focus was most assuredly KDE.  I admit this
> > was a while back, so this could all have been addressed already, but it
> > scared me away from Mandriva-GNOME.
> For a while Gnome 2 had some problems at first, just as did KDE 4, but 
> they have been long solved.  (The upgrade to Gnome 2 was a major rewrite.)
> Most of the things you mention are configuration problems.  It might be 
> a little difficult at first finding exactly where to adjust the specific 
> settings, but that is to be expected.
> >Also, while yes, most browsers are
> > DE independent, Firefox takes a bit of tweeking to work flawlessly
> > within the KDE DE.  Some distros have supplied a very vanilla install
> > and things such as application associations were rather buggy.  Yet, if
> > it's done right (and Mandriva always did it right) Firefox works great
> > on KDE as do all the other major browsers, IE excluded of course.
> >
> Firefox also works well with Gnome.
> 
> ... Wait a minute ... who said that (ms) IE is a major browser ? ;)

Firefox works great with GNOME since it's GTK based.  I love GNOME,
Ubuntu is my main desktop distro with Mandriva being my work desktop,
and Firefox seems tailor made for GNOME.  I'm not sure if its GTK (kind
of) base is the reason some KDE focused distros (Kubuntu, OpenSUSE, and
Linux Mint KDE) have a rough time getting Firefox to work perfectly
right "out-of-the-box".  As long as everything works without me having
to configure it to work right I'm perfectly happy using FF as my default
browser.

Also, yeah I hate that IE is a major browser too. Yet for some reason
60% - 70% of computer users choose it as their main browser.  Sad but
true. :-(

I'm really hoping Mageia focuses on both GNOME & KDE, but I could also
understand if the developers chose to focus on just one for stability
and speed reasons.  Guess I just figured it was a KDE-centric distro
since Mandriva seemed to focus so much on it.




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

2010-10-07 Thread Romain d'Alverny
On Thu, Oct 7, 2010 at 07:34, Gustavo Giampaoli
 wrote:
> Could it be possible to use the same schema that Mandriva use + one
> "LTS" with three years of support?
>
> Regular releases every six months with 18 month support.
>
> But we could include this "kind of" LTS with 36 month.
>
> Difference with Ubuntu will be that our LTS will be launched only
> after the previous LTS ends its cycle.
>
> Something like this: http://img819.imageshack.us/i/mageiareleases.jpg/
>
> My doubt is will Magea community be able to handle the support for
> four releases at the same time in semesters when it happen?
>
> If you add the LTS, should regular release support be reduced to 12
> months? This way, you'll never have more than 3 releases "alive" at
> the same time.
>
>
>
> Gustavo Giampaoli (aka tavillo1980)
>
It has been posted before but I guess it's a good read for anyone
willing to push an argument in this debate:
http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/

It is a nice post explaining the existing different point of views
(bonus to clever points about updates frequency and presentation).

Now, in the same vein, let's put the discussion at rest a little and
have each interested person write down an article with arguments for
the why's and how's. So here is a page for that:
http://mageia.org/wiki/doku.php?id=rollingdebate

Please write down your point of view, detail it as explained on the
wiki page, link it and a week from now, everyone involved in the
discussion can have a look at it for a summary.

That won't trigger a change decision at once (way too soon anyway, we
have to roll a first release to assess our new build system and
infrastructure and organisation) but it may at least lay down all
arguments and allow to have a better view of what everyone understand,
agree on definitions and see what is really at stake here. For later
reference, discussion and decision.

Thanks a lot.

Cheers,

Romain


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

2010-10-07 Thread Samuel Verschelde

Le jeudi 7 octobre 2010 11:20:04, Buchan Milne a écrit :
> The fact that almost no-one on this list seems to have known about backports 
> at all doesn't mean that the backports feature is not useful, it may be that 
> it wasn't accessible enough to end users.

+1

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

+1


> 
> 
> Alternatively, maybe a "What's new" view?

Oh yes, let's do it !

> 
> Maybe a rating/voting/popularity system should be available, however in the 
> past people had complained about privacy issues, which I think may have 
> resulted in little effort being put into completion of drakstats.
> 
> So, maybe a web site should also be developed, which allows users to also 
> access package rating information, and which provides some kind of 
> installation feature.

Yes this web site could :
- allow package rating
- show download stats (if possible)
- show recent versions updates (with the highest rating packages more visible 
than an obscure lib :))
- allow backport / new package requests (I know, bugzilla used to be the place 
where you did that previously, but can't we find a way to link both). This way 
packagers would have more visibility on the user's needs. 

> I think one problem Mandriva had was that users refused to believe that:
> -Mandriva was open
> -Contributors could easily improve the distribution
> -Mandriva probably already had most of what they wanted, and if it didn't, 
> they should do what they can do to help
> 
> For example, many people complained about bugs that get no attention, but *1* 
> contributor managed to change that perception to some extent. However, if 
> more 
> people contributed, more bugs would actually be fixed.
> 
> Mandriva the company may have been a barrier to contribution to some, and I 
> think one of the most important aspects of Mageia is ensuring that 
> contributors know exactly what happens to their contribution, and knowing 
> that 
> the financial state of a company does not impact the future availability of 
> the project to which they contributed.
> 

OK, buchan, how do we start ? Shall we put improvements proposals (UI, website, 
...) on the wiki, on 
http://mageia.org/wiki/doku.php?id=rollingdebate ?

> 
> The problem is to make it *easier* for users to get new versions of software, 
> not to force everyone to upgrade constantly.

+1

Samuel



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

2010-10-07 Thread Romain d'Alverny
On Thu, Oct 7, 2010 at 11:36, Samuel Verschelde  wrote:
> Le jeudi 7 octobre 2010 11:20:04, Buchan Milne a écrit :
>> Maybe a rating/voting/popularity system should be available, however in the
>> past people had complained about privacy issues, which I think may have
>> resulted in little effort being put into completion of drakstats.
>>
>> So, maybe a web site should also be developed, which allows users to also
>> access package rating information, and which provides some kind of
>> installation feature.
>
> Yes this web site could :
> - allow package rating
> - show download stats (if possible)
> - show recent versions updates (with the highest rating packages more visible 
> than an obscure lib :))
> - allow backport / new package requests (I know, bugzilla used to be the 
> place where you did that previously, but can't we find a way to link both). 
> This way packagers would have more visibility on the user's needs.

You describe quite what Kiosk was designed for (and what most App
Store are nowadays anyway).

> OK, buchan, how do we start ? Shall we put improvements proposals (UI, 
> website, ...) on the wiki, on
> http://mageia.org/wiki/doku.php?id=rollingdebate ?

No, these are two different things. Above wiki page is for stating a
perceived problem, and detailing what people view should be (or not
be) done.

Stating the need for, and specifying/scratching a web-based (or
semi-web-based) UI for a socially augmented software library is
another thing.


Romain


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

2010-10-07 Thread Eatdirt

On 07/10/10 11:26, Buchan Milne wrote:


Well, this has been possible since at least Mandrake 9.0, maybe even before
(8.1? 8.2?), and since about 2009.0 has been available even without using the
command line.


Talking about easy way to do stuff, I have been using mdv since then, I 
am gentoo-like user and I never found out this stuff. Just how to tell 
you how clear it is and available for normal users. The only thing I 
used was urpmi--auto-update from version a to b ending up in serious pbs.


The other thread would not be so long if the release cycle was not an 
issue. So I am arguing as an user, you arguing as what? A sys admin who 
likes his system in read-only?


Cheers,
Chris.



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

2010-10-07 Thread Marc Paré

Le 2010-10-07 04:55, Romain d'Alverny a écrit :

On Thu, Oct 7, 2010 at 07:34, Gustavo Giampaoli
  wrote:

Could it be possible to use the same schema that Mandriva use + one
"LTS" with three years of support?

Regular releases every six months with 18 month support.

But we could include this "kind of" LTS with 36 month.

Difference with Ubuntu will be that our LTS will be launched only
after the previous LTS ends its cycle.

Something like this: http://img819.imageshack.us/i/mageiareleases.jpg/

My doubt is will Magea community be able to handle the support for
four releases at the same time in semesters when it happen?

If you add the LTS, should regular release support be reduced to 12
months? This way, you'll never have more than 3 releases "alive" at
the same time.



Gustavo Giampaoli (aka tavillo1980)


It has been posted before but I guess it's a good read for anyone
willing to push an argument in this debate:
http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/

It is a nice post explaining the existing different point of views
(bonus to clever points about updates frequency and presentation).

Now, in the same vein, let's put the discussion at rest a little and
have each interested person write down an article with arguments for
the why's and how's. So here is a page for that:
http://mageia.org/wiki/doku.php?id=rollingdebate

Please write down your point of view, detail it as explained on the
wiki page, link it and a week from now, everyone involved in the
discussion can have a look at it for a summary.

That won't trigger a change decision at once (way too soon anyway, we
have to roll a first release to assess our new build system and
infrastructure and organisation) but it may at least lay down all
arguments and allow to have a better view of what everyone understand,
agree on definitions and see what is really at stake here. For later
reference, discussion and decision.

Thanks a lot.

Cheers,

Romain



Merci Romain:

This should help a lot. So perhaps a return to this discussion later (a 
a new thread!), with a reference to the wiki page for devs and users 
alike? Then Mageia will get a better feel for what is the "hoped" 
expectation from the devs and users? If people in the new thread were to 
argue a statement, we could then offer them the


> http://mageia.org/wiki/doku.php?id=rollingdebate

page as reference.

Sounds great!

Marc



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

2010-10-07 Thread Marc Paré

Le 2010-10-07 05:36, Samuel Verschelde a écrit :


Le jeudi 7 octobre 2010 11:20:04, Buchan Milne a écrit :

The fact that almost no-one on this list seems to have known about backports
at all doesn't mean that the backports feature is not useful, it may be that
it wasn't accessible enough to end users.


+1



I am amazed and admit at how little I knew of the Backport services, and 
I consider myself a little more knowledgeable of the past Mandriva 
Distro's. "Backport" should then have been more properly advertised as 
what it was really intended, rather than just put on the repo choice in 
the MCC. "Backport" for a regular user brings to mind "old releases" 
that you would want to keep for some kind of reason.


I would challenge people to find a regular user who knew what the 
"Backport" option was for, you may find some but clearly, they would be 
in the minority. Otherwise, it would have been used quite extensively by 
users. This is exactly what a user is usually interested in updating 
his/her installation.


I believe this is a case where a person's belief of the word "Backport" 
was a commonly understood word in the "user world", which it is 
definitely not!


I have been looking at my Mdv2010.1 installation and sure enough there 
are the "Amarok" updates that I was hoping for, and not to mention all 
of the others that I was hoping to get at the next distro upgrade. This 
is exactly what users look for.


Could the "Backport" name then be changed to a more appropriate and 
descriptive name (along with a proper description of its use)?



Marc (using his new version of Amarok!)



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Marc Paré




No, konqueror is still useful as a file manager (some users don't like
dolphin for some  reason), also as a man pages viewer. Also it shares
some code with dolphin (some stuff/features don't work in dolphin if
konqueror isn't installed).



I usually use Konqueror as my ftp agent. It works flawlessly. I just 
recently started to try Dolphin ((Ctrl-l) brings up the URL field) but 
it just kept kicking me off my sites for some reason.


Marc



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Michael Scherer
Le mercredi 06 octobre 2010 à 23:18 -0400, Sorteal a écrit :
> On Thu, 2010-10-07 at 04:01 +0200, Wolfgang Bornath wrote:
> > 2010/10/7 Marc Paré :
> > >
> > > I guess this information would have to come from someone from the core dev
> > > group. Just so that we know for sure. So, is Mageia going to be 
> > > principally
> > > a KDE distro with offers during installation to install GNOME and other
> > > desktops? Or is it going to be a desktop agnostic distro where the user
> > > eventually picks the desktop sometime during the installation processs?
> > >
> > > This may help with this thread on the talk of browsers.
> > 
> > Pls correct me if I'm wrong but I don't know any browser which is DE
> > dependent - well, there's konqueror, if you want to call this "I want
> > to be everything" a browser. But for real browsers, what does it
> > matter which DE is used?
> 
> While Mandriva officially supported both GNOME and KDE, I do remember
> the last time I tried the GNOME version of Mandriva it was pretty much a
> raw GNOME install. 

Yeah, that's in fact a feature. GNOME was manager by Frederic Crozat,
who is a gnome developer, so he followed quite closely gnome decisions.

Some people may argue that a distro is here to enhance software, but the
first goal is to distribute. And since everybody think distro should
collaborate more, pushing upstream is exactly this kind of
collaboration.

-- 
Michael Scherer



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Marc Paré



I saw that suggestion from somebody (in a post to this or the
mageia-discuss list). Mandriva officially supports both KDE and Gnome,
to my understanding.
Since I came to Mandriva from RedHat, I'm more used to Gnome.
I've tried KDE; it take a lot more space, and Gnome suits me better.
So evidently, I'd like Mageia to support both.

- André (andre999)




But we still haven't heard from someone on the core Mageia group? Or is 
this issue still unsettled? Is there anyone from the core group who 
could jump in and straighten us out?


Marc



Re: [Mageia-dev] Identifying Target Markets

2010-10-07 Thread Marc Paré

Le 2010-10-07 04:03, Olivier Méjean a écrit :

>
>  Actually, Mandriva did do this, but on a smaller scale, when installing
>  the ISO you got the the choice of desktop KDE, GNOME or personalized
>  (http://wiki.mandriva.com/fr/Installer_Mandriva_Free#Choix_du_bureau).
>  In the personalized section, you could still choose (in my case) the KDE
>  but also any other "distro type" of pick that you wanted. It would make
>  sense to offer the choices here. For example "Gamer"; "Business";
>  "Music"; "Video"; "Education" etc. The users could, at this point,
>  tailor the installation to one that would suit them best according to
>  their needs. All on one DVD! No need to have multiple type of DVD's.
>
>  This would be simple enough.
>
>  Marc
>

something like :http://www.juzt-innovations.ie/fedora-linux-backup/linux-
fedora-custom-install.jpg


Yes. We essentially already have this with the step in the installation 
process at the "Pick your desktop":


KDE(checkbox)..Gnome(checkbox)..Personalized (checkbox)

(Note that on this page I would have a "Help" link describing what each 
of these choices represent)


But once inside the "Personalized" section, we could have the extra options.

Marc



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Oliver Burger
Marc Paré  schrieb am 2010-10-07
> > Since I came to Mandriva from RedHat, I'm more used to Gnome.
> > I've tried KDE; it take a lot more space, and Gnome suits me better.
> > So evidently, I'd like Mageia to support both.
> But we still haven't heard from someone on the core Mageia group? Or is
> this issue still unsettled? Is there anyone from the core group who
> could jump in and straighten us out?

I think, it's quite simple. If there are packagers wanting to do KDE, GNOME, 
XFCE or LXDE: fine.

If not: not so fine.

You don't believe that a packager using GNOME will build KDE just because some 
users have the opinion GNOME shell be dropped?
Before that happens this packager will leave to another distro where he can 
package GNOME.

So what is the sense of this descussion?
Remember: this is a community project. you can't force a packager to do, what 
he choses not to.

Oliver


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

2010-10-07 Thread Michael Scherer
Le jeudi 07 octobre 2010 à 02:34 -0300, Gustavo Giampaoli a écrit :
> Could it be possible to use the same schema that Mandriva use + one
> "LTS" with three years of support?
> 
> Regular releases every six months with 18 month support.
> 
> But we could include this "kind of" LTS with 36 month.
> 
> Difference with Ubuntu will be that our LTS will be launched only
> after the previous LTS ends its cycle.

This would force the upgrade of users if they want to be supported, so
that's not a good idea.

> Something like this: http://img819.imageshack.us/i/mageiareleases.jpg/
> 
> My doubt is will Magea community be able to handle the support for
> four releases at the same time in semesters when it happen?
> If you add the LTS, should regular release support be reduced to 12
> months? This way, you'll never have more than 3 releases "alive" at
> the same time.

While the reasoning is good, we should first see how much releases can
be supported when we will be able to start to support one. So before
that, all projections are moot.


-- 
Michael Scherer



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

2010-10-07 Thread Samuel Verschelde

Le jeudi 7 octobre 2010 12:10:11, Romain d'Alverny a écrit :
> 
> On Thu, Oct 7, 2010 at 11:36, Samuel Verschelde  wrote:
> > Le jeudi 7 octobre 2010 11:20:04, Buchan Milne a écrit :
> >> Maybe a rating/voting/popularity system should be available, however in the
> >> past people had complained about privacy issues, which I think may have
> >> resulted in little effort being put into completion of drakstats.
> >>
> >> So, maybe a web site should also be developed, which allows users to also
> >> access package rating information, and which provides some kind of
> >> installation feature.
> >
> > Yes this web site could :
> > - allow package rating
> > - show download stats (if possible)
> > - show recent versions updates (with the highest rating packages more 
> > visible than an obscure lib :))
> > - allow backport / new package requests (I know, bugzilla used to be the 
> > place where you did that previously, but can't we find a way to link both). 
> > This way packagers would have more visibility on the user's needs.
> 
> You describe quite what Kiosk was designed for (and what most App
> Store are nowadays anyway).
> 
> > OK, buchan, how do we start ? Shall we put improvements proposals (UI, 
> > website, ...) on the wiki, on
> > http://mageia.org/wiki/doku.php?id=rollingdebate ?
> 
> No, these are two different things. Above wiki page is for stating a
> perceived problem, and detailing what people view should be (or not
> be) done.
> 
> Stating the need for, and specifying/scratching a web-based (or
> semi-web-based) UI for a socially augmented software library is
> another thing.
> 

Well, it's different, but to me part of the debate on the release cycle. As 
Buchan stated, better perception of backports by users could bring the benefits 
that some people see in a rolling release. Plus, I'm not only talking about 
web-based UI, but also rpmdrake improvements regarding backports.
However, if you think we shouldn't put an entry saying "no rolling release, but 
improve current backports scheme, see proposal below", I won't do it.

Regards

Samuel



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Marc Paré

Le 2010-10-07 07:27, Oliver Burger a écrit :

Marc Paré  schrieb am 2010-10-07

Since I came to Mandriva from RedHat, I'm more used to Gnome.
I've tried KDE; it take a lot more space, and Gnome suits me better.
So evidently, I'd like Mageia to support both.

But we still haven't heard from someone on the core Mageia group? Or is
this issue still unsettled? Is there anyone from the core group who
could jump in and straighten us out?


I think, it's quite simple. If there are packagers wanting to do KDE, GNOME,
XFCE or LXDE: fine.

If not: not so fine.

You don't believe that a packager using GNOME will build KDE just because some
users have the opinion GNOME shell be dropped?
Before that happens this packager will leave to another distro where he can
package GNOME.

So what is the sense of this descussion?
Remember: this is a community project. you can't force a packager to do, what
he choses not to.

Oliver



Thanks. That makes sense. Sorry, I was still thinking the "Mandriva 
corporate" way. So, we are pretty well left at the mercy of the devs 
interest with this regard. (I don't mean to sound negative, but more 
realist in saying this.)


Do you know, out of interest, if there are more KDE or Gnome devs 
interested in the Mageia project or if this is till too early to tell?


Also, out of interest, how hard is it to maintain both from a dev point 
of view (time-wise etc.)? (I'm sure others will jump in and ask for 
other desktop manager here too.)


Marc



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

2010-10-07 Thread Marc Paré

Le 2010-10-07 07:23, Olivier Méjean a écrit :

Le jeudi 7 octobre 2010 13:00:21, Marc Paré a écrit :


I would challenge people to find a regular user who knew what the
"Backport" option was for, you may find some but clearly, they would be
in the minority. Otherwise, it would have been used quite extensively by
users. This is exactly what a user is usually interested in updating
his/her installation.


Backport was a media added for Mandriva 2007 in order to provide latest
versions of software. However, backport rpms were (and are) not officially
supported by Mandriva on the contrary of rpms in main (either /main/release or
/main/updates)

That make sense for a company based distribution to operate such a
discrimination, i am not sure that we have to follow such a way in a
community-driven distribution.

Olivier



I have to say though, that after having browsed through the Mdv2010.1 
backports by hand, there is a lot, from a user point of view, that would 
interest users. All of the sexy upgrades to software are there.


I think it would be nice to keep as long as it didn't cause major 
problems with the installation. Maybe an option to "roll-back" a 
software update would be something to consider for users?


Marc



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Oliver Burger
Marc Paré  schrieb am 2010-10-07
> Thanks. That makes sense. Sorry, I was still thinking the "Mandriva
> corporate" way. So, we are pretty well left at the mercy of the devs
> interest with this regard. (I don't mean to sound negative, but more
> realist in saying this.)
> 
> Do you know, out of interest, if there are more KDE or Gnome devs
> interested in the Mageia project or if this is till too early to tell?
Looking into the wiki: 
http://www.mageia.org/wiki/doku.php?id=packaging#list_of_categories there are 
more packagers interested in KDE thean the others. Actually there's not a 
single packager interested in GNOME which I think is a pitty. Although I do 
prefer KDE, I'm using apps from all DEs. I don't see any reason, not to use 
some app just because it is from another DE
I hope there will be someone taking over GNOME. (after all I am the guy 
building the Ubuntu-netbook-launcher for the German Mandriva community repo 
because I do really like the launcher).

> Also, out of interest, how hard is it to maintain both from a dev point
> of view (time-wise etc.)? (I'm sure others will jump in and ask for
> other desktop manager here too.)
I think the main packagers from one of the DEs are quite bussy with that. 
Especially if you try to fit them into a distro specific look and feel.
In this respect it is perhaps a good decision not to customize them too much. 
Makes the work much easier.
Packagers as myself who were - at least till now - building only single 
applications can do that for any number of DEs as long as they have the time 
doing it.

But I'm not a professional in this respect, I'm just an ambitioned amateur who 
is doing his best in the time that's free for me to do so.

Oliver


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

2010-10-07 Thread Oliver Burger
Marc Paré  schrieb am 2010-10-07
> I have to say though, that after having browsed through the Mdv2010.1
> backports by hand, there is a lot, from a user point of view, that would
> interest users. All of the sexy upgrades to software are there.
I have been using the backports as regular repos for years now and some 
(solvable) version conflicts with kernel modules put aside, I never had any 
problems with them.

> I think it would be nice to keep as long as it didn't cause major
> problems with the installation. Maybe an option to "roll-back" a
> software update would be something to consider for users?
That would be a nice feature for urpmi. But it's only useful in certain 
borders. Sometimes newer versions are changing things about the configuration 
in the user's HOME, the older versions can't work with. So there will be 
problems with some packages if you do a "rollback upgrade".

Oliver


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Rtp
Marc Paré  writes:

Hi,

>> I saw that suggestion from somebody (in a post to this or the
>> mageia-discuss list). Mandriva officially supports both KDE and Gnome,
>> to my understanding.
>> Since I came to Mandriva from RedHat, I'm more used to Gnome.
>> I've tried KDE; it take a lot more space, and Gnome suits me better.
>> So evidently, I'd like Mageia to support both.
>>
>> - André (andre999)
>>
>>
>
> But we still haven't heard from someone on the core Mageia group? Or
> is this issue still unsettled? Is there anyone from the core group who
> could jump in and straighten us out?

imho, I don't see any reason why one DE should be prefered to one an
other. There will be people working on GNOME or KDE or whatever. Mageia
is handled by a community so this give the possibility to have versions
with KDE or GNOME installed (or something else). We have choices so why
should it be reduced to no choice at all ?

As regards having it as default/"prefered" choice, it's something else...


Arnaud


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Ahmad Samir
On 7 October 2010 13:10, Michael Scherer  wrote:
> Le mercredi 06 octobre 2010 à 23:18 -0400, Sorteal a écrit :
>> On Thu, 2010-10-07 at 04:01 +0200, Wolfgang Bornath wrote:
>> > 2010/10/7 Marc Paré :
>> > >
>> > > I guess this information would have to come from someone from the core 
>> > > dev
>> > > group. Just so that we know for sure. So, is Mageia going to be 
>> > > principally
>> > > a KDE distro with offers during installation to install GNOME and other
>> > > desktops? Or is it going to be a desktop agnostic distro where the user
>> > > eventually picks the desktop sometime during the installation processs?
>> > >
>> > > This may help with this thread on the talk of browsers.
>> >
>> > Pls correct me if I'm wrong but I don't know any browser which is DE
>> > dependent - well, there's konqueror, if you want to call this "I want
>> > to be everything" a browser. But for real browsers, what does it
>> > matter which DE is used?
>>
>> While Mandriva officially supported both GNOME and KDE, I do remember
>> the last time I tried the GNOME version of Mandriva it was pretty much a
>> raw GNOME install.
>
> Yeah, that's in fact a feature. GNOME was manager by Frederic Crozat,
> who is a gnome developer, so he followed quite closely gnome decisions.
>

And KDE was managed by whom? all the Mandriva KDE team were/are KDE developers.

It's just different packaging philosophies, KDE guys like to customize
stuff (that's a bit generalising); while GNOME guys didn't (note that
the whole GNOME philosophy is "conservative", e.g. in the options in
provides in GUI). Both philosophies had its pros and cons.

One big advantage of sticking as close to upstream as possible is that
GNOME team in mdv eased their maintenance burdens, which is logical as
they weren't that many and were always overworked (note that fcrozat,
for example, didn't just maintain only GNOME, but many other aspects
of the distro too, including a good number of core stuff).

> Some people may argue that a distro is here to enhance software, but the
> first goal is to distribute. And since everybody think distro should
> collaborate more, pushing upstream is exactly this kind of
> collaboration.
>
> --
> Michael Scherer
>
>



-- 
Ahmad Samir


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

2010-10-07 Thread Tux99
On Thu, 7 Oct 2010, Buchan Milne wrote:

> I don't believe that merely changing to some kind of rolling release will 
> improve matters for end users, they will just be more confused when they find 
> out that to install database support for OpenOffice.org, they need to upgrade 
> all of OpenOffice.org (taking an hour to download ~ 70MB), instead of just 
> being able to install openoffice.org-base (with a 2 minute download of 2MB).

This is a misconception, even today with the current Mandriva system the 
user has to download the same 70MB, since security updates are not diffs 
but whole packages.

To make it clearer, if the user wants to install oo-base at a later 
point with the currend Mdv model he would have to download 20MB if there 
has been no security updates since release, or 70MB if there has been a 
security update in the meantime.

Exactly the same would be the case with a light rolling distro.

People who say that a light rolling distro (i.e. where only app upgrades 
are made available mid-cycle, not the core packages) will increase 
downloads for users are simply not thinking this through.

No one is forced to download and install the upgrades, a user can just 
only install those upgrades which are also security updates, just like 
he/she would do with the current Mdv model.

A security update or an upgrade imply roughly the same download size, 
since in both cases the whole package is downloaded again, what differs 
is only the version that's being downloaded not the size.

The only real difference between the light rolling distro model 
deescribed earlier in this thread by a few people (including myself) and 
the current Mdv release model, is that security updates of apps are 
provided through version upgrades whenever this is possible, i.e. 
when the version upgrade is not a major upgrade with incompatible 
changes.



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Ahmad Samir
On 7 October 2010 13:50, Oliver Burger  wrote:
> Marc Paré  schrieb am 2010-10-07
>> Thanks. That makes sense. Sorry, I was still thinking the "Mandriva
>> corporate" way. So, we are pretty well left at the mercy of the devs
>> interest with this regard. (I don't mean to sound negative, but more
>> realist in saying this.)
>>
>> Do you know, out of interest, if there are more KDE or Gnome devs
>> interested in the Mageia project or if this is till too early to tell?
> Looking into the wiki:
> http://www.mageia.org/wiki/doku.php?id=packaging#list_of_categories there are
> more packagers interested in KDE thean the others. Actually there's not a
> single packager interested in GNOME which I think is a pitty. Although I do
> prefer KDE, I'm using apps from all DEs. I don't see any reason, not to use
> some app just because it is from another DE
> I hope there will be someone taking over GNOME. (after all I am the guy
> building the Ubuntu-netbook-launcher for the German Mandriva community repo
> because I do really like the launcher).
>

Götz Waschk said he'll package for Mageia, it just seems he doesn't
care about putting his names in lists :)

-- 
Ahmad Samir


Re: [Mageia-dev] News about the forum

2010-10-07 Thread Maât
Le 04/10/2010 00:14, Maât a écrit :
> Stay tuned,
>   
Hi,

News about forums progress :

We are currently starting to work on mageia ldap and forum connection.

If properly working that will avoid contributors to have to create
accounts everywhere (forums, build system, bugtracker...)

A common web identity manager like http://identity.kde.org will allow
people to suscribe, manage their passwords and other profile data \o/

To avoid problems during ldap and forums connection phase (which could
force us to reset forum posts and user accounts) we have been asked to
delay a little bit before forum opening.

What we need now is to build the support team... so that they can be
ready when forum opens...

Cheers,
Maât

 


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

2010-10-07 Thread Marc Paré


To make it clearer, if the user wants to install oo-base at a later
point with the currend Mdv model he would have to download 20MB if there
has been no security updates since release, or 70MB if there has been a
security update in the meantime.



FYI, there is currently a discussion on the LibO discussion list this 
very point. You may want to join in and have a say. There is talk of an 
incremental update or other methods.


They are on Gmane too!

Marc



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

2010-10-07 Thread Gustavo Giampaoli
> It has been posted before but I guess it's a good read for anyone
> willing to push an argument in this debate:
> http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/

Really excellent article. I enjoyed reading it because it's based on
people-from-real-life.

Even when I'm not developer nor advanced user, I know I'm above basic
users. And sometimes I (and I guess most of us) forget that most
people are like our moms or our sisters (not moms that are software
engineer X). People who only read their "hotmail" mail, use
messenger, facebook, tweeter, listen some MP3, write a doc for school.

So, I agree we must bring some order to this "storm".

Cheers!


Gustavo Giampaoli (aka tavillo1980)


Re: [Mageia-dev] News about the forum

2010-10-07 Thread Tux99


Quote: maat-ml wrote on Thu, 07 October 2010 14:50
> 
> We are currently starting to work on mageia ldap and forum connection.
> 
> If properly working that will avoid contributors to have to create
> accounts everywhere (forums, build system, bugtracker...)
> 
> A common web identity manager like http://identity.kde.org will allow
> people to suscribe, manage their passwords and other profile data \o/

Sounds great, please try to include mailman into the ldap setup, so that a
registered forum member can also post to the MLs (via the forum ML gw)
without having to subscribe separately to the ML.

I assume the phpBB3 forum sw has the capability (like most forum sw) to
define various categories of users so that (if necessary) the posting to
some MLs can be restricted to specific categories of users (for exampled
devs).

While I don't think such restrictions will be necessary, including them in
the planning should calm fears of people who are fear a flooding of the
MLs by hordes of uneducated noobs.

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


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

2010-10-07 Thread Sinner from the Prairy
Marc Paré wrote:

> I have to say though, that after having browsed through the Mdv2010.1
> backports by hand, there is a lot, from a user point of view, that would
> interest users. All of the sexy upgrades to software are there.

That's my point exactly.

IMHO , with backports there is no need for 
(light/heavy/overweight/vegetarian) rolling distribution.

As I see it, if you want a rolling distro, just use backports, see if 
backports work for you, and if they do not work for you, then explain why 
not and why rolling distro will work for you (and how will it work).

I know that rolling distro, .deb, Ubuntu, synergy, SEO, 2.0 et all are 
powerfull marketing words. But have no real value added to Mageia.

There is no free lunch! To increase results (rolling distro) one must 
increase the work (packagers, QA).

Besides absolute lack of knowledge about backports, I still have failed to 
read an answer how backports are not filling the needs for  bleeding-edge 
users.

P.S.: Buchan Milne, +1;  you have your beverage of choice paid by me 
anytime you come to North Carolina

Salut,
Sinner



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

2010-10-07 Thread Ahmad Samir
On 7 October 2010 15:08, Gustavo Giampaoli  wrote:
>> It has been posted before but I guess it's a good read for anyone
>> willing to push an argument in this debate:
>> http://mairin.wordpress.com/2010/09/01/a-story-about-updates-and-people/
>
> Really excellent article. I enjoyed reading it because it's based on
> people-from-real-life.
>
> Even when I'm not developer nor advanced user, I know I'm above basic
> users. And sometimes I (and I guess most of us) forget that most
> people are like our moms or our sisters (not moms that are software
> engineer X). People who only read their "hotmail" mail, use
> messenger, facebook, tweeter, listen some MP3, write a doc for school.
>
> So, I agree we must bring some order to this "storm".
>
> Cheers!
>
>
> Gustavo Giampaoli (aka tavillo1980)
>

You keep omitting who you're quoting from the top of your replies...
(the part that should look like "On 7 October 2010 15:08, Gustavo
Giampaoli  wrote:" above).

-- 
Ahmad Samir


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

2010-10-07 Thread Tux99
On Thu, 7 Oct 2010, Sinner from the Prairy wrote:

> Besides absolute lack of knowledge about backports, I still have failed to 
> read an answer how backports are not filling the needs for  bleeding-edge 
> users.

It's the focus that changes, currently with Mandriva backports are a 
barely known unsupported afterthought.
With a light rolling release scheme backports would be supported with 
regards to security fixes, since backports would be the preferred way to 
provide security fixes.
It actually reduces workload since instead of the Mageia devs having to 
create themselves security patches for older releases, we just use the 
newer version of the sw from upstream that already includes the security 
patches.



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

2010-10-07 Thread Greg Harris

 On 10/7/2010 7:23 AM, Olivier Méjean wrote:

Le jeudi 7 octobre 2010 13:00:21, Marc Paré a écrit :

I would challenge people to find a regular user who knew what the
"Backport" option was for, you may find some but clearly, they would be
in the minority. Otherwise, it would have been used quite extensively by
users. This is exactly what a user is usually interested in updating
his/her installation.

Backport was a media added for Mandriva 2007 in order to provide latest
versions of software. However, backport rpms were (and are) not officially
supported by Mandriva on the contrary of rpms in main (either /main/release or
/main/updates)

That make sense for a company based distribution to operate such a
discrimination, i am not sure that we have to follow such a way in a
community-driven distribution.

Olivier
You hit the point precisely. Mandriva's backports was a terrific idea 
that does not succeed because (1) it is disabled by default and the 
means to enable it as an update medium are made obscure by intention and 
design and (2) the strange attitude taken, by some maintainers at least, 
that anyone using backports is on their own ("Backports are not 
supported!").




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

2010-10-07 Thread Gustavo Giampaoli
IMHO that if we want that "backports" be more "popular", we must stop
promoting like "for advanced users":
http://wiki.mandriva.com/en/Docs/Basic_tasks/Installing_and_removing_software#Advanced_use:_Backports_and_candidate_updates

Quote:

"The testing and backports repositories for each section will be
configured on your system but disabled (they are disabled by default
to ensure you do not install packages from these repositories by
accident, since they could potentially not work as well as those from
the release and updates repositories). To use these repositories,
simply run the Software Media Manager as discussed in #Making more
applications available and check the boxes to enable them. We
recommend that you do not leave either repository permanently enabled,
but enable them if you wish to install a specific package from them,
install the package, and then disable them again."

If you give this kind of description to non-advanced / geek users, of
course they will be afraid to try backports. And, if they don't try
backports, you'll have lot of people knocking at your door asking for
rolling distro.

Of course, I'm not saying "let's lie to people".

If backports are "dangerous", we can't think in tell everyone "you
want updated packages? Try backports" because not everyone will have
the ability to handle problems or system instability.

But, if backports aren't that dangerous, why to show them with red
lights and warnings?

Cheers!



Gustavo Giampaoli (aka tavillo1980)


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

2010-10-07 Thread Marc Paré





P.S.: Buchan Milne, +1;  you have your beverage of choice paid by me
anytime you come to North Carolina

Salut,
Sinner




+10

Yay! Can I come too now?

Marc



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

2010-10-07 Thread nicolas vigier
On Thu, 07 Oct 2010, Tux99 wrote:

> On Thu, 7 Oct 2010, Sinner from the Prairy wrote:
> 
> > Besides absolute lack of knowledge about backports, I still have failed to 
> > read an answer how backports are not filling the needs for  bleeding-edge 
> > users.
> 
> It's the focus that changes, currently with Mandriva backports are a 
> barely known unsupported afterthought.
> With a light rolling release scheme backports would be supported with 
> regards to security fixes, since backports would be the preferred way to 
> provide security fixes.
> It actually reduces workload since instead of the Mageia devs having to 
> create themselves security patches for older releases, we just use the 
> newer version of the sw from upstream that already includes the security 
> patches.

So what you're asking is basically to remove the updates repository
because you don't need it ?

But what about the people who don't need new versions, but want stability
and security updates ?

For instance, if you're using Mageia on your computer for important
tasks, you don't want everything to change constantly, because every new
version require some testing to check that it is still working for you
(even when it does not introduce new bugs, the behavior of a lot of
software change with new versions).



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

2010-10-07 Thread Tux99
On Thu, 7 Oct 2010, nicolas vigier wrote:

> > It's the focus that changes, currently with Mandriva backports are a 
> > barely known unsupported afterthought.
> > With a light rolling release scheme backports would be supported with 
> > regards to security fixes, since backports would be the preferred way to 
> > provide security fixes.
> > It actually reduces workload since instead of the Mageia devs having to 
> > create themselves security patches for older releases, we just use the 
> > newer version of the sw from upstream that already includes the security 
> > patches.
> 
> So what you're asking is basically to remove the updates repository
> because you don't need it ?

The updates repo won't be removed since it's still needed for 
security updates for the core distro packages, which won't be updated
to  newer versions during a release cycle, only the apps that don't have 
child dependencies (and where there are no major version changes with 
incompatibilities).

> But what about the people who don't need new versions, but want stability
> and security updates ?

As many people here have said already, version updates doesn't 
automatically mean instability and/or incompatibilities, in fact such a 
risk is very small, as anyone who has used backports in Mdv can confirm.

Someone who needs absolute stability (for example for important 
servers), will always use other distros that specifically focus on that, 
like Centos.

We cannot cater to everyone, I'm assuming that Mageia is primarily an 
end-user desktop distro (like Mandriva was) so we might as well improve 
it for that purpose. 

If we try to cater for everyone we won't excell in anything, everything 
will be compromises and the result will be mediocre.



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

2010-10-07 Thread Michael Scherer
Le jeudi 07 octobre 2010 à 10:22 -0400, Greg Harris a écrit :

> You hit the point precisely. Mandriva's backports was a terrific idea 
> that does not succeed because (1) it is disabled by default and the 
> means to enable it as an update medium are made obscure by intention and 
> design and (2) the strange attitude taken, by some maintainers at least, 
> that anyone using backports is on their own ("Backports are not 
> supported!").

Well, when the backport was made without asking to developers first ( as
it happened with gwibber back at mandriva ), yes, the only thing I can
say is "I do not support it, because I didn't do it, nor was able to
test it correctly'.

If we tell "we do not have the ressources to fully test a backport, so
let's not do it", people are unhappy.
If we say "ok, here it is, but we didn't test, you are on your own",
people are unhappy. 

As said by sinnerBOFH, if people want better backports, this requires
more ressources, there is no magic.

-- 
Michael Scherer



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

2010-10-07 Thread Greg Harris

 On 10/7/2010 11:00 AM, Michael Scherer wrote:

Le jeudi 07 octobre 2010 à 10:22 -0400, Greg Harris a écrit :


You hit the point precisely. Mandriva's backports was a terrific idea
that does not succeed because (1) it is disabled by default and the
means to enable it as an update medium are made obscure by intention and
design and (2) the strange attitude taken, by some maintainers at least,
that anyone using backports is on their own ("Backports are not
supported!").

Well, when the backport was made without asking to developers first ( as
it happened with gwibber back at mandriva ), yes, the only thing I can
say is "I do not support it, because I didn't do it, nor was able to
test it correctly'.

If we tell "we do not have the ressources to fully test a backport, so
let's not do it", people are unhappy.
If we say "ok, here it is, but we didn't test, you are on your own",
people are unhappy.

As said by sinnerBOFH, if people want better backports, this requires
more ressources, there is no magic.

I certainly agree, and mean no disrespect to you and other maintainers 
who generously contribute their time and energy. But the Mandriva 
implementation of backports is not a solution for those who want a 
continuously updated distro. It works for me and I appreciate that it's 
there. But if you are going to design a new and appealing alternative, 
the effort required to make backports really known and useful needs to 
be taken into account.




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

2010-10-07 Thread Romain d'Alverny
On Thu, Oct 7, 2010 at 13:27, Samuel Verschelde  wrote:
>
> Le jeudi 7 octobre 2010 12:10:11, Romain d'Alverny a écrit :
>>
>> You describe quite what Kiosk was designed for (and what most App
>> Store are nowadays anyway).
>>
>> > OK, buchan, how do we start ? Shall we put improvements proposals
>> > (UI, website, ...) on the wiki, on 
>> > http://mageia.org/wiki/doku.php?id=rollingdebate ?
>>
>> No, these are two different things. Above wiki page is for stating a
>> perceived problem, and detailing what people view should be (or not
>> be) done.
>>
>> Stating the need for, and specifying/scratching a web-based (or
>> semi-web-based) UI for a socially augmented software library is
>> another thing.
>
> Well, it's different, but to me part of the debate on the release cycle. As 
> Buchan
> stated, better perception of backports by users could bring the benefits that
> some people see in a rolling release. Plus, I'm not only talking about 
> web-based
> UI, but also rpmdrake improvements regarding backports.

Well, rpmdrake is a software library UI. Be it Web-based or not,
that's another issue.

I totally agree that the library contents and possibilities perception has to be
improved. At least that we need to clarify/simplify/change how
existing/new software
and updates/upgrades are presented to the user.

Maybe shifting from a strictly system-related point of view (current
rpmdrake UI)
to a more application/task/user-related one. Or maybe it's a deeper issue than
just presentation/UI (like really handling differently how software
gets integrated
and packaged on/above/within the operating system).

But I just don't know. And I believe we're several in this case.

It is just not clear at all that this discussion about "rolling" distro,
backports, etc. is directly linked to that.

So the above linked wiki page is about stating and nailing down the problem
several people here seem to agree there is:
 - first, make sure everyone speak about the same thing; so everyone should
   state her own point of view, detailed;
 - second, work this refined problem in depth, so that we see what is really
   the problem, and not only the symptoms;
 - third, once the problem is clearly stated, the solution(s) may be more
   obvious to see/discute/define.

Note that at this current stage of discussion, it may as well be that there are
_several_ issues mixed as one. So we could as well split the problem into
relevant parts.

> However, if you think we shouldn't put an entry saying "no rolling release,
> but improve current backports scheme, see proposal below", I won't do it.

You can too. But then let's make sure this is related to the discussion (it may,
I am not sure) and then, let's define the bigger picture that links all this
together (would need a separate section in the wiki page then, or yet another
page to state the big view of the issue).


Romain


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

2010-10-07 Thread nicolas vigier
On Thu, 07 Oct 2010, Tux99 wrote:

> 
> > But what about the people who don't need new versions, but want stability
> > and security updates ?
> 
> As many people here have said already, version updates doesn't 
> automatically mean instability and/or incompatibilities, in fact such a 
> risk is very small, as anyone who has used backports in Mdv can confirm.
> 
> Someone who needs absolute stability (for example for important 
> servers), will always use other distros that specifically focus on that, 
> like Centos.

They could use Mandriva for good stability (not absolute). Why do you
want to exclude them from Mageia ?

> We cannot cater to everyone, I'm assuming that Mageia is primarily an 
> end-user desktop distro (like Mandriva was) so we might as well improve 
> it for that purpose. 

And what makes you think end-users want new versions rather than
stability ?

I know a lot of people that don't care about new versions, but are very
annoyed when an update breaks something.

For example me, if I setup a computer for my parents, they ask me when
something is broken so I need to spend some time to fix it. And they
don't care about new versions, they can wait 6 months or 1 year to have
the latest KDE.



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Thierry Vignaud
On 7 October 2010 14:35, Ahmad Samir  wrote:
> Götz Waschk said he'll package for Mageia, it just seems he doesn't
> care about putting his names in lists :)

s/Götz/SuperGötz/ !


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

2010-10-07 Thread Tux99


Quote: nicolas vigier wrote on Thu, 07 October 2010 17:16
> > Someone who needs absolute stability (for example for important 
> > servers), will always use other distros that specifically focus on
> > that, 
> > like Centos.
> 
> They could use Mandriva for good stability (not absolute). Why do you
> want to exclude them from Mageia ?

I don't want to exclude anyone, but Mandriva (apart from MES which is a
separate product) never was the best choice for a long-term stable server
install, sure some people used it but it was a small minority compared to
those that use Centos/Redhat, Suse or even Ubuntu LTS.

We have debated that already earlier in this thread, most people that need
Centos/Redhat like stability also need long-term support which we cannot
provide anyway (at least for now).

> And what makes you think end-users want new versions rather than
> stability ?

Like I mentioned in my previous post (and others here confirmed), many
years of spending on Linux related forums. Most non-geek users just want
to be able to install new app versions, not upgrade the whole distro.

> I know a lot of people that don't care about new versions, but are
> very
> annoyed when an update breaks something.

Distro upgrades tend to break a lot more things.

> For example me, if I setup a computer for my parents, they ask me when
> something is broken so I need to spend some time to fix it. And they
> don't care about new versions, they can wait 6 months or 1 year to
> have
> the latest KDE.

I'm repeating myself: we don't want to upgrade the core packages like KDE
between releases, only apps without child-dependencies and where the
upgrade is not a major upgrade with incomaptible changes.

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


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

2010-10-07 Thread Samuel Verschelde

Le jeudi 7 octobre 2010 17:15:45, Romain d'Alverny a écrit :
> So the above linked wiki page is about stating and nailing down the problem
> several people here seem to agree there is:
>  - first, make sure everyone speak about the same thing; so everyone should
>state her own point of view, detailed;
>  - second, work this refined problem in depth, so that we see what is really
>the problem, and not only the symptoms;
>  - third, once the problem is clearly stated, the solution(s) may be more
>obvious to see/discute/define.
> 
> Note that at this current stage of discussion, it may as well be that there 
> are
> _several_ issues mixed as one. So we could as well split the problem into
> relevant parts.
> 

I think I see what you mean : you want the thing to be more globally thought 
that just pointing at some specifif improvements (whatever needed they may be). 
I'll try to stay in the frame, and will try to show that backports perception 
indeed has something to do with the feeling that updating your "favorite" 
applications is impossible or difficult in today's model :)

Regards

Samuel Verschelde



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

2010-10-07 Thread Michael Scherer
Le jeudi 07 octobre 2010 à 11:14 -0400, Greg Harris a écrit :

> I certainly agree, and mean no disrespect to you and other maintainers 
> who generously contribute their time and energy. But the Mandriva 
> implementation of backports is not a solution for those who want a 
> continuously updated distro. It works for me and I appreciate that it's 
> there. But if you are going to design a new and appealing alternative, 
> the effort required to make backports really known and useful needs to 
> be taken into account.

Well, that's a long running task. First, we have added meta data to
repository so we could design a better interface for the software ( ie,
how to detect that a packages is a backport and how to see a software is
a update, a test update, or something else ), then we need to implement
the soft, etc.

You spoke of having backport by default. We used to do it, but too much
people faced issue and complained. So we 1) said the truth, aka backport
didn't have the same rigorous testing 2) disabled it by default.

Now, if things change ( ie, if we have a process with more QA ), we can
change again.

-- 
Michael Scherer



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

2010-10-07 Thread SinnerBOFH

On Oct 7, 2010, at 10:44 AM, Marc Paré  wrote:
> 
>> P.S.: Buchan Milne, +1;  you have your beverage of choice paid by me
>> anytime you come to North Carolina
>> 
>> Salut,
>> Sinner
>> 
>> 
> 
> +10
> 
> Yay! Can I come too now?
> 
> Marc

Sure. Get your penguin-darriere over here and we'll talk shop with beers in our 
hand. 

Salut,
Sinner

Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Renaud MICHEL
On jeudi 07 octobre 2010 at 09:15, Dimitrios Glentadakis wrote :
> For me, Konqueror is the main application in my system. file manager and
> browser. May be for others too

Yep, konqueror is my filemanager, web browser, (s)ftp client and quick 
previewer (with kparts integration).
It is just great to be able to split a view and have a web page on one side 
and an sftp connection on the other to quickly copy linked documents from 
the first to the second :-)

(actually, splitting views is one of my favourite konqueror killer feature)

-- 
Renaud Michel


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

2010-10-07 Thread Marc Paré

Le 2010-10-07 15:00, SinnerBOFH a écrit :


On Oct 7, 2010, at 10:44 AM, Marc Paré  wrote:



P.S.: Buchan Milne, +1;  you have your beverage of choice paid by me
anytime you come to North Carolina

Salut,
Sinner




+10

Yay! Can I come too now?

Marc


Sure. Get your penguin-darriere over here and we'll talk shop with beers in our 
hand.

Salut,
Sinner


I'll bring along the beer nuts! ... ahem ... and some Canadian beer!

Marc



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Marc Paré

Le 2010-10-07 16:18, Renaud MICHEL a écrit :

On jeudi 07 octobre 2010 at 09:15, Dimitrios Glentadakis wrote :

For me, Konqueror is the main application in my system. file manager and
browser. May be for others too


Yep, konqueror is my filemanager, web browser, (s)ftp client and quick
previewer (with kparts integration).
It is just great to be able to split a view and have a web page on one side
and an sftp connection on the other to quickly copy linked documents from
the first to the second :-)

(actually, splitting views is one of my favourite konqueror killer feature)



That's how I do it too. Really cool! Also, the KDE4.5.X where you drag 
the window into the left side and it re-draws it to a half-monitor size 
and you can then open another window with it re-drawing on the other 
half. Really efficient!


However, Dolphin seems to me a little less clunkier than Konqueror. 
Which is why I am trying out Dolphin as an ftp agent. I find it 
(Dolphin) still a little temperamental and keep going back to Konqueror 
though. I do my file managing with Dolphin though. Mdv2010.1 KDE4.5.0.


Cheers

Marc



Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Graham Lauder
On Friday 08 Oct 2010 09:18:03 Renaud MICHEL wrote:
> On jeudi 07 octobre 2010 at 09:15, Dimitrios Glentadakis wrote :
> > For me, Konqueror is the main application in my system. file manager and
> > browser. May be for others too
> 
> Yep, konqueror is my filemanager, web browser, (s)ftp client and quick
> previewer (with kparts integration).
> It is just great to be able to split a view and have a web page on one side
> and an sftp connection on the other to quickly copy linked documents from
> the first to the second :-)
> 
> (actually, splitting views is one of my favourite konqueror killer feature)

Yep, agreed it is the most versatile piece of kit on my comp, for website 
admin it is killer.  Page preview, ftp and local directory all in there 
together using split screen just rox. 

Nothing else comes close

Cheers
GL

-- 
Graham Lauder,
OpenOffice.org MarCon (Marketing Contact) NZ
http://marketing.openoffice.org/contacts.html

OpenOffice.org Migration and training Consultant.

INGOTs Assessor Trainer
(International Grades in Open Technologies)
www.theingots.org


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Sorteal

 On 10/7/2010 4:41 PM, Marc Paré wrote:

Le 2010-10-07 16:18, Renaud MICHEL a écrit :

On jeudi 07 octobre 2010 at 09:15, Dimitrios Glentadakis wrote :
For me, Konqueror is the main application in my system. file manager 
and

browser. May be for others too


Yep, konqueror is my filemanager, web browser, (s)ftp client and quick
previewer (with kparts integration).
It is just great to be able to split a view and have a web page on 
one side
and an sftp connection on the other to quickly copy linked documents 
from

the first to the second :-)

(actually, splitting views is one of my favourite konqueror killer 
feature)




That's how I do it too. Really cool! Also, the KDE4.5.X where you drag 
the window into the left side and it re-draws it to a half-monitor 
size and you can then open another window with it re-drawing on the 
other half. Really efficient!


However, Dolphin seems to me a little less clunkier than Konqueror. 
Which is why I am trying out Dolphin as an ftp agent. I find it 
(Dolphin) still a little temperamental and keep going back to 
Konqueror though. I do my file managing with Dolphin though. Mdv2010.1 
KDE4.5.0.


Cheers

Marc

Why are we even talking about removing Konqueror??  So many people use 
it as their default file manager and ftp client that removing it seems 
crazy.  While I do agree that Konqueror is not the greatest web browser 
around and Rekonq is a much better choice for a pure Qt/KDE browser, I 
do not think we should be excluding Konqueror at all.  Plus, Dolphin 
still requires certain parts of Konqueror to function correctly if I'm 
not mistaken.


While at first I found Dolphin rather weak in comparison to Konqueror, 
as far as file management went, it has improved over the last couple of 
years.  Now, I actually prefer Dolphin over Konqueror when it comes to 
file management but I still use Konqueror for ftp or when I need a all 
in one kind of tool.  If Konqueror could render web pages as well as 
Rekonq, Firefox, or Chromium I'd definitely use it as my default web 
browser.


Thanks
-Jason


Re: [Mageia-dev] Talk of Browsers

2010-10-07 Thread Renaud MICHEL
On jeudi 07 octobre 2010 at 23:39, Sorteal wrote :
> Why are we even talking about removing Konqueror??  So many people use 
> it as their default file manager and ftp client that removing it seems 
> crazy.  While I do agree that Konqueror is not the greatest web browser 
> around and Rekonq is a much better choice for a pure Qt/KDE browser, I 
> do not think we should be excluding Konqueror at all.

I don't think anybody suggested to remove konqueror, but rather to provide 
firefox as the default browser on a new install.
Although I prefer konqueror, I think it is reasonable as most people expect 
to have firefox (and I use it for the few sites that I visit and render 
badly in konqueror (actually, it is more about javascript than rendering)).

> Plus, Dolphin still requires certain parts of Konqueror to function
> correctly if I'm not mistaken.

Right, but those parts are in separate libraries which can (and will) be 
installed without installing konqueror itself.

> While at first I found Dolphin rather weak in comparison to Konqueror, 
> as far as file management went, it has improved over the last couple of 
> years.  Now, I actually prefer Dolphin over Konqueror when it comes to 
> file management but I still use Konqueror for ftp or when I need a all 
> in one kind of tool.  If Konqueror could render web pages as well as 
> Rekonq, Firefox, or Chromium I'd definitely use it as my default web 
> browser.

There is a webkit kpart which can be used instead of the standard khtml one. 
In mdv2010.1 it is provided by package webkitkde.
I think I read somewhere that it was greatly improved in KDE 4.5 (or was it 
during a summer of code after KDE 4.5 release?) with better KDE integration.

-- 
Renaud Michel


[Mageia-dev] Proposal: Updating released versions (long post)

2010-10-07 Thread Frank Griffin
Part of the recent thread about what the desirable release cycle should
be devolved into a discussion of how backports works and whether or not
it's suitable.  I'd like to examine this issue.

The current urpmi repository architecture serves purposes that were
meaningful to Mandriva.  It segregates main from contrib for statement
of support reasons, it separates non-free from main for philosophical
reasons, and it separates restricted from main for legal and business
reasons. 

This works pretty well for cooker, where you either want a particular
category of package considered or you don't, but the reuse of this model
for updates, backports, and testing in released versions isn't as good a
fit.

The root of the problem is that the user base is different.  Users of
cooker want the latest and greatest of everything, and have accepted
that if something breaks in cooker, it may stay broken for awhile. 
Users of released versions vary all over the map, from people who never
want anything to change to people who want some specific updates to
people who want everything new but want it stable.  Users of cooker
rarely think about security updates, because in grabbing everything
available constantly, the security updates are "just there".  With users
of released versions, they may have to opt-in for security updates, and
usually want to treat other updates differently.

I'd like to propose the following model for updating released versions:

1) Users should not have to see, except in minor ways, the different
repositories.  Urpmi may see them, and advanced or ideologically polar
users may care about them (e.g. free vs non-free), but most users
won't.  Instead, let urpmi or rpmdrake have knowledge about all
repositories whether enabled or not, and display the offerings with an
icon, tooltip, or extra column that indicates the status of the package.

2) The update tool we give these users should distinguish between
security updates and backports/testing, but present them both.  This is
very much like the Windows Update model, where all available fixes are
divided into "Critical System Updates" and "Software Updates".  We don't
really have the same support constraints as Mandriva, and there's no
need to automatically disable backports across the board, and not even
present the backports as possibilities.

3) Users should be able to enable options for each category
independently.  Most users would probably want security updates applied
automatically, but would want to be notified of availability of
backports or testing and choose those manually.

(Here's the biggie :-) )
4) We need to enhance the urpmi.recover functionality and bring it fully
into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS
PREVIOUS VERSION (sorry for the caps).  If we don't want to be stuck
with trying to reconcile our desire to QA some packages better than
others with some users' desires to at least *try* the newest stuff, then
we need to allow them to move forwards and backwards in the package
history as easily as possible.

Yes, I know this is problematic.  It means that we have to do a really
good job of getting dependencies right.  But if the dependencies *are*
right, then this should be doable. 

It means that we need to expand the logic in urpmi that can currently
identify the packages that need to be uninstalled if some other package
is uninstalled so that it can take into account the package it will be
installing in its place (and the other older versions of packages that
it will require), and compare the two lists to produce a "diff".

It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires
"B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3
with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the
same transaction.  This may have a cascading effect.  In any event, the
user should be told what's going to be backlevelled, but specifically
*not* see the current urpmi list of everything that will have to be
removed if "A" 1.3 is removed if most of that stuff is simply going to
be replaced with its own previous versions.  In other words, rather than
tell the user that removing "A" 1.3 is going to remove half of KDE and
scare the sh*t out of him, just tell him that the following packages are
going to have to be backlevelled as well.  If there really are things
that can't be undone and redone, that should be a separate highly
visible prompt.

This will require some extended transactional support in urpmi, I would
think, because we'd literally have to overrule rpm about pulling stuff
out from under the feet of other packages if we knew we were going to
put it back.  That would mean that we'd have the responsibility of
ensuring that the transaction either committed fully from our
perspective, or got fully rolled back.

This also means that packagers would have to be aware of packages that
reformat their  application files as the version increases, and would
have to archive previous vers

Re: [Mageia-dev] Proposal: Updating released versions (long post)

2010-10-07 Thread Marc Paré

Le 2010-10-07 19:49, Frank Griffin a écrit :

Part of the recent thread about what the desirable release cycle should
be devolved into a discussion of how backports works and whether or not
it's suitable.  I'd like to examine this issue.

The current urpmi repository architecture serves purposes that were
meaningful to Mandriva.  It segregates main from contrib for statement
of support reasons, it separates non-free from main for philosophical
reasons, and it separates restricted from main for legal and business
reasons.

This works pretty well for cooker, where you either want a particular
category of package considered or you don't, but the reuse of this model
for updates, backports, and testing in released versions isn't as good a
fit.

The root of the problem is that the user base is different.  Users of
cooker want the latest and greatest of everything, and have accepted
that if something breaks in cooker, it may stay broken for awhile.
Users of released versions vary all over the map, from people who never
want anything to change to people who want some specific updates to
people who want everything new but want it stable.  Users of cooker
rarely think about security updates, because in grabbing everything
available constantly, the security updates are "just there".  With users
of released versions, they may have to opt-in for security updates, and
usually want to treat other updates differently.

I'd like to propose the following model for updating released versions:

1) Users should not have to see, except in minor ways, the different
repositories.  Urpmi may see them, and advanced or ideologically polar
users may care about them (e.g. free vs non-free), but most users
won't.  Instead, let urpmi or rpmdrake have knowledge about all
repositories whether enabled or not, and display the offerings with an
icon, tooltip, or extra column that indicates the status of the package.

2) The update tool we give these users should distinguish between
security updates and backports/testing, but present them both.  This is
very much like the Windows Update model, where all available fixes are
divided into "Critical System Updates" and "Software Updates".  We don't
really have the same support constraints as Mandriva, and there's no
need to automatically disable backports across the board, and not even
present the backports as possibilities.

3) Users should be able to enable options for each category
independently.  Most users would probably want security updates applied
automatically, but would want to be notified of availability of
backports or testing and choose those manually.

(Here's the biggie :-) )
4) We need to enhance the urpmi.recover functionality and bring it fully
into mainstream urpmi so that ANY PACKAGE CAN BE ROLLED BACK TO ITS
PREVIOUS VERSION (sorry for the caps).  If we don't want to be stuck
with trying to reconcile our desire to QA some packages better than
others with some users' desires to at least *try* the newest stuff, then
we need to allow them to move forwards and backwards in the package
history as easily as possible.

Yes, I know this is problematic.  It means that we have to do a really
good job of getting dependencies right.  But if the dependencies *are*
right, then this should be doable.

It means that we need to expand the logic in urpmi that can currently
identify the packages that need to be uninstalled if some other package
is uninstalled so that it can take into account the package it will be
installing in its place (and the other older versions of packages that
it will require), and compare the two lists to produce a "diff".

It needs to decide which changes can be "quiet", e.g. "A" 1.3 requires
"B" 1.3" and "A" 1.2 requires "B" 1.2, so a request to replace "A" 1.3
with "A" 1.2 would cause a replacement of "B" 1.3 with "B" 1.2 in the
same transaction.  This may have a cascading effect.  In any event, the
user should be told what's going to be backlevelled, but specifically
*not* see the current urpmi list of everything that will have to be
removed if "A" 1.3 is removed if most of that stuff is simply going to
be replaced with its own previous versions.  In other words, rather than
tell the user that removing "A" 1.3 is going to remove half of KDE and
scare the sh*t out of him, just tell him that the following packages are
going to have to be backlevelled as well.  If there really are things
that can't be undone and redone, that should be a separate highly
visible prompt.

This will require some extended transactional support in urpmi, I would
think, because we'd literally have to overrule rpm about pulling stuff
out from under the feet of other packages if we knew we were going to
put it back.  That would mean that we'd have the responsibility of
ensuring that the transaction either committed fully from our
perspective, or got fully rolled back.

This also means that packagers would have to be aware of packages that
reformat their  application files as the version increa

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

2010-10-07 Thread Fernando Parra
On Thu, 7 Oct 2010 17:43:23 +0200
Samuel Verschelde  wrote:

> 
> Le jeudi 7 octobre 2010 17:15:45, Romain d'Alverny a écrit :
> > So the above linked wiki page is about stating and nailing down the problem
> > several people here seem to agree there is:
> >  - first, make sure everyone speak about the same thing; so everyone should
> >state her own point of view, detailed;
> >  - second, work this refined problem in depth, so that we see what is really
> >the problem, and not only the symptoms;
> >  - third, once the problem is clearly stated, the solution(s) may be more
> >obvious to see/discute/define.
> > 
> > Note that at this current stage of discussion, it may as well be that there 
> > are
> > _several_ issues mixed as one. So we could as well split the problem into
> > relevant parts.
> > 
> 
> I think I see what you mean : you want the thing to be more globally thought 
> that just pointing at some specifif improvements (whatever needed they may 
> be). I'll try to stay in the frame, and will try to show that backports 
> perception indeed has something to do with the feeling that updating your 
> "favorite" applications is impossible or difficult in today's model :)
> 
> Regards
> 
> Samuel Verschelde
> 
> 
Hi Everybody.

Now I'm really happy, finally I think we are talking about the big goal: 
Usability and End User Satisfaction!

I propose close this particular thread at it's present state, at now it's hard 
to follow each one points of view.

I think is time to push harder, we need go to the desk and prepare a better 
structured documents as Marc proposed.

A final recommendation. We must think in the End User first, and later in 
technical issues, there is no matter how it can be sound impossible, remember 
When Jules Verne wrote about a trip to the moon, everyone thought it would be 
impossible, and now we see that it is 40 years since man landed on the lunar 
surface.

Think new, think magic, think Mageia

 <