subject:"Re\: \[Mageia\-dev\] Missing packages"

'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
 On 9 June 2011 14:22, Oliver Burger oliver@googlemail.com wrote:
 Dexter Morgan dmorga...@gmail.com schrieb am 09.06.2011

 On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie mag...@colin.guthr.ie
 wrote:

 I think updates would be the right place.



 Please no 3rd repo :)

 But i agree with you for updates for new packages ( no new

 versions ;) )


 I would prefer using updates over backports as well. If we use backports we
 would get more problems then benefit (like people not having backports
 enabled or people having backports enabled and thus getting problems they
 can't handle e.g. with new kernels, graphic drivers and so on).


 Perhaps we could upload them to updates/testing for a really short qa before
 moving them to updates/ ?


 Oliver
 
 If it's pushed to /updates then it should be imported to the stable
 release SVN tree; note that at some point Cauldron could get a newer
 version than the one in /updates, and maybe it's not backportable, new
 deps, regressions... etc. But now if there's a bug in the version in
 the stable */updates, and it needs a patch, what are you gonna base
 the patch on if you submit directly from the Cauldron SVN checkout to
 */updates, and the Cauldron package has already changed?
 
 But if new package can go directly to updates.. that doesn't look
 right to me, because at which point will new packages stop going to
 a stable release */updates? if it goes on and on, then we're talking
 about a semi-cauldron-like repo.

So just svn cp it to the /1/updates tree in svn and job's a good 'un.
(well svn cp is no longer just one step due to source separation, but
the principle is the same!).


 Also note that a new package in Cauldron gets tested for a while
 (depending at which point it was imported during the release cycle),
 but if gets pushed to /updates and not backports (which is not
 supported), that testing period is short-circuited.

Yeah but then the examples I've got so far are:

 * trac
 * supybot
 * supybot-Meetbot
 * passwd-gen
 * dd_rescue

In all these cases, these are packages I use. I will be testing them on
that version of the distro. And when I don't use them every day, (e.g.
passwd-gen, dd_rescue), they are pretty standard, stable and standalone
apps.

IMO we can over-analyse the risk factor here massive to the detriment
of the overall offering.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Samuel Verschelde


Le vendredi 10 juin 2011 10:56:35, Colin Guthrie a écrit :
 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
  On 9 June 2011 14:22, Oliver Burger oliver@googlemail.com wrote:
  Dexter Morgan dmorga...@gmail.com schrieb am 09.06.2011
  
  On Thu, Jun 9, 2011 at 11:54 AM, Colin Guthrie mag...@colin.guthr.ie
  
  wrote:
  I think updates would be the right place.
  
  Please no 3rd repo :)
  
  But i agree with you for updates for new packages ( no new
  
  versions ;) )
  
  I would prefer using updates over backports as well. If we use backports
  we would get more problems then benefit (like people not having
  backports enabled or people having backports enabled and thus getting
  problems they can't handle e.g. with new kernels, graphic drivers and
  so on).
  
  
  Perhaps we could upload them to updates/testing for a really short qa
  before moving them to updates/ ?
  
  
  Oliver
  
  If it's pushed to /updates then it should be imported to the stable
  release SVN tree; note that at some point Cauldron could get a newer
  version than the one in /updates, and maybe it's not backportable, new
  deps, regressions... etc. But now if there's a bug in the version in
  the stable */updates, and it needs a patch, what are you gonna base
  the patch on if you submit directly from the Cauldron SVN checkout to
  */updates, and the Cauldron package has already changed?
  
  But if new package can go directly to updates.. that doesn't look
  right to me, because at which point will new packages stop going to
  a stable release */updates? if it goes on and on, then we're talking
  about a semi-cauldron-like repo.
 
 So just svn cp it to the /1/updates tree in svn and job's a good 'un.
 (well svn cp is no longer just one step due to source separation, but
 the principle is the same!).
 
  Also note that a new package in Cauldron gets tested for a while
  (depending at which point it was imported during the release cycle),
  but if gets pushed to /updates and not backports (which is not
  supported), that testing period is short-circuited.
 
 Yeah but then the examples I've got so far are:
 
  * trac
  * supybot
  * supybot-Meetbot
  * passwd-gen
  * dd_rescue
 
 In all these cases, these are packages I use. I will be testing them on
 that version of the distro. And when I don't use them every day, (e.g.
 passwd-gen, dd_rescue), they are pretty standard, stable and standalone
 apps.
 
 IMO we can over-analyse the risk factor here massive to the detriment
 of the overall offering.
 
 Col

I agree with Colin here.

Samuel

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
 Hi,
 
 As I upgrade my various machines (I only really have about 5, so not
 that many) I'm running into a few packages that are missing (this is
 inevitable).
 
 Nothing major just little things like trac and supybot etc.
 
 What is the best way to add these packages to the v1 tree?
 
 Using backports seems a little odd as this is unsupported and we don't
 really want to encourage using it as a means to get the missing packages.

If we do not want to have people use backports, we wouldn't have added
it in the first place.

I do think backport is perfectly suited for that.


 release is obviously frozen so no go there.
 
 The only real option is updates, but that should obviously have some QA
 on it.

Updates is not for new version of software, not for new softwares. And
backporting something from cauldron is not a update.

 Perhaps we need to have some kind of exemption to get these missing
 packages added?
 
 Does anyone have any opinions on this?

Yes, I do.

We have used backports in the past for that, and I see no reason to
change that. 

If the problem is that backports were too buggy in the past, then we
should fix backports process, not bypassing them.

And if we start by pushing new version in update, people will soon
wonder why the new version of X is in updates, while the new version of
Y is not, just because we didn't have X in release and Y was there.


-- 
Michael Scherer

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit :
 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:

  But if new package can go directly to updates.. that doesn't look
  right to me, because at which point will new packages stop going to
  a stable release */updates? if it goes on and on, then we're talking
  about a semi-cauldron-like repo.
 
 So just svn cp it to the /1/updates tree in svn and job's a good 'un.
 (well svn cp is no longer just one step due to source separation, but
 the principle is the same!).

The bin repository is a different svn, so it will not work.


-- 
Michael Scherer

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

'Twas brillig, and Michael Scherer at 10/06/11 11:29 did gyre and gimble:
 Le vendredi 10 juin 2011 à 09:56 +0100, Colin Guthrie a écrit :
 'Twas brillig, and Ahmad Samir at 09/06/11 17:42 did gyre and gimble:
 
 But if new package can go directly to updates.. that doesn't look
 right to me, because at which point will new packages stop going to
 a stable release */updates? if it goes on and on, then we're talking
 about a semi-cauldron-like repo.

 So just svn cp it to the /1/updates tree in svn and job's a good 'un.
 (well svn cp is no longer just one step due to source separation, but
 the principle is the same!).
 
 The bin repository is a different svn, so it will not work.

Isn't that what I said? (I referred to the binary sources as just
source). I maintain the principle is still the same albeit we need to
do a bit more tweaking/scripting, or am I missing something?

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
 Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
 Hi,

 As I upgrade my various machines (I only really have about 5, so not
 that many) I'm running into a few packages that are missing (this is
 inevitable).

 Nothing major just little things like trac and supybot etc.

 What is the best way to add these packages to the v1 tree?

 Using backports seems a little odd as this is unsupported and we don't
 really want to encourage using it as a means to get the missing packages.
 
 If we do not want to have people use backports, we wouldn't have added
 it in the first place.
 
 I do think backport is perfectly suited for that.

So the user that just wants to install supybot has to expose themselves
to the risk of updating to a backported version of gnome or KDE this
is hardly ideal. Especially for novice users.

 release is obviously frozen so no go there.

 The only real option is updates, but that should obviously have some QA
 on it.
 
 Updates is not for new version of software, not for new softwares. And
 backporting something from cauldron is not a update.

This seems like a strange statement as */updates on mdv was allowed to
have new packages in some cases (I've done it before, although I think
only for * == contrib), so I don't see why we have to restrict this
possibility in Mageia.

 Perhaps we need to have some kind of exemption to get these missing
 packages added?

 Does anyone have any opinions on this?
 
 Yes, I do.
 
 We have used backports in the past for that, and I see no reason to
 change that.

This is fine in the regular course of distro evolution, but here we're
talking about users migrating from Mdv to Mga and finding stale Mdv
packages still installed on their system when they want (and we want to
provide) a Mageia version. This is very much a special case for this
transitional period but I feel it's an important one, particularly
*because* it's the first release.

I think you're thinking in absolute terms rather than transitional
terms. In absolute terms I agree with you on principle, but I think we
need to deal with transitional issues gracefully and not treat them as
second class considerations.

 If the problem is that backports were too buggy in the past, then we
 should fix backports process, not bypassing them.

I don't think this is particularly relevant. Backports are unsupported
generally. That's a given. If we encourage people to enable backports to
get missing packages (this is very distinct and separate from the
unsupported backports).

 And if we start by pushing new version in update, people will soon
 wonder why the new version of X is in updates, while the new version of
 Y is not, just because we didn't have X in release and Y was there.

I very much consider nothing - version X quite different from
version X - version Y. I don't think it's a hard concept for anyone
to grasp.

Col


-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

[Didn't finish this sentence]

'Twas brillig, and Colin Guthrie at 10/06/11 11:44 did gyre and gimble:
 I don't think this is particularly relevant. Backports are unsupported
 generally. That's a given. If we encourage people to enable backports to
 get missing packages (this is very distinct and separate from the
 unsupported backports)

... then we will end up having to support people who have accidentally
updated to a backported package they didn't intend or want to install.
This is likely more hassle for us in the long run.

Col



-- 

Colin Guthrie
mageia(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

2011-06-10 Thread Wolfgang Bornath

2011/6/10 Michael Scherer m...@zarb.org:

 We have used backports in the past for that, and I see no reason to
 change that.

 If the problem is that backports were too buggy in the past, then we
 should fix backports process, not bypassing them.

 And if we start by pushing new version in update, people will soon
 wonder why the new version of X is in updates, while the new version of
 Y is not, just because we didn't have X in release and Y was there.

Problem I see:
So far (in Mandriva), example:  we have used 2010.0/main/backports to
offer new versions of software which had an older version in 2010/main
but the newer version in 2010.1/main, or as the name says: backporting
a newer version of a software from the current release to a previous
release, as often used for Firefox.

For Mageia it means, /backports should hold backports of software
which has an older version in 1/core but a newer version in cauldron.
If we put new software (aka missing packages) in /backports and the
user activates /backports he also runs the risk that existing packages
of his stable installation will be replaced by real backports of newer
versions, backported from Cauldron - which he may not want to do.

I wonder why we do not put these missing packages in /testing and
after a while in /core or /non-free or /tainted (wherever they
belong). These packages are software which were supposed to be in
/core or /non-free or /tainted, they were just forgotten|came too
late|whatever for Mageia 1 release freeze.

-- 
wobo

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Thomas Backlund


Wolfgang Bornath skrev 10.6.2011 14:44:

2011/6/10 Michael Schererm...@zarb.org:


We have used backports in the past for that, and I see no reason to
change that.

If the problem is that backports were too buggy in the past, then we
should fix backports process, not bypassing them.

And if we start by pushing new version in update, people will soon
wonder why the new version of X is in updates, while the new version of
Y is not, just because we didn't have X in release and Y was there.


Problem I see:
So far (in Mandriva), example:  we have used 2010.0/main/backports to
offer new versions of software which had an older version in 2010/main
but the newer version in 2010.1/main, or as the name says: backporting
a newer version of a software from the current release to a previous
release, as often used for Firefox.

For Mageia it means, /backports should hold backports of software
which has an older version in 1/core but a newer version in cauldron.
If we put new software (aka missing packages) in /backports and the
user activates /backports he also runs the risk that existing packages
of his stable installation will be replaced by real backports of newer
versions, backported from Cauldron - which he may not want to do.

I wonder why we do not put these missing packages in /testing and
after a while in /core or /non-free or /tainted (wherever they
belong). These packages are software which were supposed to be in
/core or /non-free or /tainted, they were just forgotten|came too
late|whatever for Mageia 1 release freeze.



well, media/*/release tree is frozen, so _nothing_ new goes in there.

So the path would then be */updates_testing - */updates _if_ we decide
that's the way to go...

Problem is that a missing package introcuced in updates also can 
introduce regressions with wrong obsoletes/provides or %pre/%post scripts.


So it has to go through the same qa as the rest of the stuff heading for 
*/updates


So question becomes, do we have enough qa/security people to make it work ?

And if we introduce filtering on what goes in and what does not,
then who decides ?

--
Thomas

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Oliver Burger

Thomas Backlund t...@mageia.org schrieb am 10.06.2011
 So the path would then be */updates_testing - */updates _if_ we
 decide that's the way to go...
As I see it, it's the only user friendly way. Using backports is fine 
for experienced users who do know what to install from backports or 
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to 
backports he is in great danger of wrecking his system by installing 
some new kernel, graphics driver, desktop or whatever, precisely 
because there is no real qa on backports.

Oliver

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
 'Twas brillig, and Michael Scherer at 10/06/11 11:27 did gyre and gimble:
  Le jeudi 09 juin 2011 à 10:14 +0100, Colin Guthrie a écrit :
  Hi,
 
  As I upgrade my various machines (I only really have about 5, so not
  that many) I'm running into a few packages that are missing (this is
  inevitable).
 
  Nothing major just little things like trac and supybot etc.
 
  What is the best way to add these packages to the v1 tree?
 
  Using backports seems a little odd as this is unsupported and we don't
  really want to encourage using it as a means to get the missing packages.
  
  If we do not want to have people use backports, we wouldn't have added
  it in the first place.
  
  I do think backport is perfectly suited for that.
 
 So the user that just wants to install supybot has to expose themselves
 to the risk of updating to a backported version of gnome or KDE this
 is hardly ideal. Especially for novice users.

One alternative would be to make sure that backports for version 1 are
fully supported and break nothing. 

  release is obviously frozen so no go there.
 
  The only real option is updates, but that should obviously have some QA
  on it.
  
  Updates is not for new version of software, not for new softwares. And
  backporting something from cauldron is not a update.
 
 This seems like a strange statement as */updates on mdv was allowed to
 have new packages in some cases (I've done it before, although I think
 only for * == contrib), so I don't see why we have to restrict this
 possibility in Mageia.

contrib/updates was basically not watched at all. People could send
anything without trouble, and there was no policy ( nor any enforcement
). That's not really the best example to use :)


  Perhaps we need to have some kind of exemption to get these missing
  packages added?
 
  Does anyone have any opinions on this?
  
  Yes, I do.
  
  We have used backports in the past for that, and I see no reason to
  change that.
 
 This is fine in the regular course of distro evolution, but here we're
 talking about users migrating from Mdv to Mga and finding stale Mdv
 packages still installed on their system when they want (and we want to
 provide) a Mageia version. This is very much a special case for this
 transitional period but I feel it's an important one, particularly
 *because* it's the first release.

All releases are equal. And we warned that we would not be able to do
everything, so of course, we will have problem with those that lived on
Mars under a rock, but I think that most people know that we couldn't
have all.

 I think you're thinking in absolute terms rather than transitional
 terms. In absolute terms I agree with you on principle, but I think we
 need to deal with transitional issues gracefully and not treat them as
 second class considerations.

It was not clear for me from your mail that this would be temporary. 

So I assume we can agree to enforce the new packages go to backports
unless very specific and defined exceptions policy for version 2 of the
release ? 

If this is temporary, it would be ok, provided we follows the usual
rules about handling updates.

As we do not want to have untested rpms backported in */updates, this
mean that package must be checked by QA before ( and proper testing for
a new rpm is more that just checking it doesn't break ). 

So it should follow the proper policy ( once we agreed on that ).

As discussed in the previous thread, that would for example mean that
the packager that submit the backport is not the one testing it and
giving the go, even if he can test before submitting to avoid wasting QA
time.

Since we want to restrict to package that people have used and missed
for upgrade, I would also add that this part should be checked and
requires :
- a bug report saying upgrade failed due to that
- if we want to be inclusive, a forum post could do the trick ( provided
it is in english, or a bug referencing the forum )
- package must be kept upgradable from mandriva 2010.1
- ideally, the upgrade path should be tested, but I am pretty sure that
people will not :).

Finally, I would also add that as soon a package is in updates or
release, the usual rules should apply ( ie, no more exception ). If I
push the package to */updates once getmail because it is missing, but
the next package do not go to */updates unless it fullfill the usual
rules. Any following backports goes to */backports. 

And, just to be clear, the policy only apply to version 1, for x86_64
and i586.

One question would be what is a pacakge requires a complex backport,
for example, someone yesterday asked for darcs, that requires ghc, that
requires bootstrapping. 

Yes, no ? Why ?

  If the problem is that backports were too buggy in the past, then we
  should fix backports process, not bypassing them.
 
 I don't think this is particularly relevant. Backports are unsupported
 generally. That's a given. 

Before, it

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
 Thomas Backlund t...@mageia.org schrieb am 10.06.2011
  So the path would then be */updates_testing - */updates _if_ we
  decide that's the way to go...
 As I see it, it's the only user friendly way. Using backports is fine 
 for experienced users who do know what to install from backports or 
 who are capable of facing the consequences.
 If a total newbie asks fort a package in the forums and is pointed to 
 backports he is in great danger of wrecking his system by installing 
 some new kernel, graphics driver, desktop or whatever, precisely 
 because there is no real qa on backports.

He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.

-- 
Michael Scherer

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?


On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlundt...@mageia.org  schrieb am 10.06.2011

So the path would then be */updates_testing -  */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.


He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.



Even though backports are disabled rpmdrake can display a list of 
available backports. (The sources are automatically updated by 
mgaonline.) A selected backport can then be installed, without enabling 
the backports source. (I've just tested this on mdv 2010.0, the only mdv 
system that I have available.)


Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?


On 10/06/11 15:09, James Kerr wrote:

On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlundt...@mageia.org schrieb am 10.06.2011

So the path would then be */updates_testing - */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.


He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.



Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.) A selected backport can then be installed, without enabling
the backports source. (I've just tested this on mdv 2010.0, the only mdv
system that I have available.)



I've just realised there is a potential problem with this. Because 
Mageia has /backports_testing repo's (mdv does not) packages from 
/backports_testing may also be displayed. Mgaonline is updating those 
sources.


Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Oliver Burger

James Kerr j...@jkerr82508.free-online.co.uk schrieb am 10.06.2011
 Even though backports are disabled rpmdrake can display a list of
 available backports. (The sources are automatically updated by
 mgaonline.)
I make you parden, but: no!

When a repo is disabled it doesn't get updated automatically and its 
packages are not to be found in rpmdrake.
Did you confuse disabling repos and marking a repo for updates 
(sorry, me doesn't know the exact English strings).


So you have to enable the backports repos and even though you don't 
mark them as update repos, urpmi will ignore that (rpmdrake won't 
but urpmi will) and will update everything from those repos...

Oliver

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?


On 10/06/11 15:27, Oliver Burger wrote:

James Kerrj...@jkerr82508.free-online.co.uk  schrieb am 10.06.2011

Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.)

I make you parden, but: no!

When a repo is disabled it doesn't get updated automatically and its
packages are not to be found in rpmdrake.
Did you confuse disabling repos and marking a repo for updates
(sorry, me doesn't know the exact English strings).


So you have to enable the backports repos and even though you don't
mark them as update repos, urpmi will ignore that (rpmdrake won't
but urpmi will) and will update everything from those repos...



I meant exactly what I wrote. Select Backports from the first filter in 
rpmdrake and packages from disabled backports sources will be displayed.


Check /var/log/auth.log to see what mgaonline is doing.

Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

'Twas brillig, and Michael Scherer at 10/06/11 13:51 did gyre and gimble:
 Le vendredi 10 juin 2011 à 11:44 +0100, Colin Guthrie a écrit :
 So the user that just wants to install supybot has to expose themselves
 to the risk of updating to a backported version of gnome or KDE this
 is hardly ideal. Especially for novice users.
 
 One alternative would be to make sure that backports for version 1 are
 fully supported and break nothing. 

That's certainly worth considering.

 This seems like a strange statement as */updates on mdv was allowed to
 have new packages in some cases (I've done it before, although I think
 only for * == contrib), so I don't see why we have to restrict this
 possibility in Mageia.
 
 contrib/updates was basically not watched at all. People could send
 anything without trouble, and there was no policy ( nor any enforcement
 ). That's not really the best example to use :)

Hmm, I can't really disagree with that statement :D

 We have used backports in the past for that, and I see no reason to
 change that.

 This is fine in the regular course of distro evolution, but here we're
 talking about users migrating from Mdv to Mga and finding stale Mdv
 packages still installed on their system when they want (and we want to
 provide) a Mageia version. This is very much a special case for this
 transitional period but I feel it's an important one, particularly
 *because* it's the first release.
 
 All releases are equal. And we warned that we would not be able to do
 everything, so of course, we will have problem with those that lived on
 Mars under a rock, but I think that most people know that we couldn't
 have all.

Quite. But if the only reason for not providing a particular service or
offering is due to a policy (i.e. people want to provide and others want
to consume) then it's perhaps the policy that need re-evaluating. Just
because it's policy, doesn't mean it's the best solution. Pragmatism
often solves a lot of problems. As I said before I think we can easily
over analyse things...

 I think you're thinking in absolute terms rather than transitional
 terms. In absolute terms I agree with you on principle, but I think we
 need to deal with transitional issues gracefully and not treat them as
 second class considerations.
 
 It was not clear for me from your mail that this would be temporary. 
 
 So I assume we can agree to enforce the new packages go to backports
 unless very specific and defined exceptions policy for version 2 of the
 release ? 

Yeah I'd personally be more than happy with that.

 If this is temporary, it would be ok, provided we follows the usual
 rules about handling updates.
 
 As we do not want to have untested rpms backported in */updates, this
 mean that package must be checked by QA before ( and proper testing for
 a new rpm is more that just checking it doesn't break ). 
 
 So it should follow the proper policy ( once we agreed on that ).
 
 As discussed in the previous thread, that would for example mean that
 the packager that submit the backport is not the one testing it and
 giving the go, even if he can test before submitting to avoid wasting QA
 time.

That all seems reasonable to me (although I think the QA people can also
be a bit fast and loose with some requests (obviously at their own
discretion) - e.g. I doubt they really need to massively test the impact
to other packages of adding something like dd_rescue, more just test
that it runs OK)

 Since we want to restrict to package that people have used and missed
 for upgrade, I would also add that this part should be checked and
 requires :
 - a bug report saying upgrade failed due to that
 - if we want to be inclusive, a forum post could do the trick ( provided
 it is in english, or a bug referencing the forum )
 - package must be kept upgradable from mandriva 2010.1
 - ideally, the upgrade path should be tested, but I am pretty sure that
 people will not :).

Yeah I agree to that. I think that while you're right about testing the
upgrade and that it will likely not be fully tested, we can still do a
what version does mdv 2010.2 have?, what version do we have? Will it
upgrade? conceptual test (i.e. ask the questions!) which should cover
98.23% of the cases). (made up stat obviously!)


 Finally, I would also add that as soon a package is in updates or
 release, the usual rules should apply ( ie, no more exception ). If I
 push the package to */updates once getmail because it is missing, but
 the next package do not go to */updates unless it fullfill the usual
 rules. Any following backports goes to */backports. 

Makes sense yes.


 And, just to be clear, the policy only apply to version 1, for x86_64
 and i586.

WFM.

 One question would be what is a pacakge requires a complex backport,
 for example, someone yesterday asked for darcs, that requires ghc, that
 requires bootstrapping. 
 
 Yes, no ? Why ?

If this kind of thing crops up, I think we can discuss it at the time.
As we will have to

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

Le vendredi 10 juin 2011 à 16:27 +0200, Oliver Burger a écrit :
 James Kerr j...@jkerr82508.free-online.co.uk schrieb am 10.06.2011
  Even though backports are disabled rpmdrake can display a list of
  available backports. (The sources are automatically updated by
  mgaonline.)
 I make you parden, but: no!
 
 When a repo is disabled it doesn't get updated automatically and its 
 packages are not to be found in rpmdrake.
 Did you confuse disabling repos and marking a repo for updates 
 (sorry, me doesn't know the exact English strings).
 
 
 So you have to enable the backports repos and even though you don't 
 mark them as update repos, urpmi will ignore that (rpmdrake won't 
 but urpmi will) and will update everything from those repos...

UI wise, I think it would make sense to have that ( even if a idea is
not sufficient, and we need a patch ) :

User search for a package, he should see the latest recommended version
( ie, release/updates ). 

If he say also provides newer versions, then we could show backports,
with some indication that we provides a tested version, and a
potentially newer ones. 

We can agree that everybody want something newer for some rpms, but few
people want everything to be newer ( ie, now one run backports as a
update media, I think ). So as much as I am against asking to users
questions, we must show them the choice somewhere, in a non obstrusive
way. 

And for testing integration, I think we could have a different workflow,
maybe something linked to a bug reporting tool. I have a bug on kde and
use some custom bug reporting tool, the tools notice that something
could be tested, and say to the user we have a update candidate, do you
want to test ? If unsure, say no ?

-- 
Michael Scherer

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Maarten Vanraes

Op vrijdag 10 juni 2011 17:18:54 schreef Michael Scherer:
[...]
 UI wise, I think it would make sense to have that ( even if a idea is
 not sufficient, and we need a patch ) :
 
 User search for a package, he should see the latest recommended version
 ( ie, release/updates ).
 
 If he say also provides newer versions, then we could show backports,
 with some indication that we provides a tested version, and a
 potentially newer ones.
 
 We can agree that everybody want something newer for some rpms, but few
 people want everything to be newer ( ie, now one run backports as a
 update media, I think ). So as much as I am against asking to users
 questions, we must show them the choice somewhere, in a non obstrusive
 way.
 
 And for testing integration, I think we could have a different workflow,
 maybe something linked to a bug reporting tool. I have a bug on kde and
 use some custom bug reporting tool, the tools notice that something
 could be tested, and say to the user we have a update candidate, do you
 want to test ? If unsure, say no ?

+1

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

2011-06-10 Thread nicolas vigier

On Fri, 10 Jun 2011, Michael Scherer wrote:

  release is obviously frozen so no go there.
  
  The only real option is updates, but that should obviously have some QA
  on it.
 
 Updates is not for new version of software, not for new softwares. And
 backporting something from cauldron is not a update.

Maybe we could change the definition of updates repository. Rather than
a strict rule no new version and no new software in updates, we could
have something like this :

 - updates : no regression, and no changes in interfaces / protocols /
   config files since last package. You could have a cron script updating
   from this repository and nothing should stop working.

 - backports : possible regressions and/or changes in interfaces /
   protocols / config files. Updates from this repository should not be
   installed automatically but checked by user.

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Ahmad Samir

On 10 June 2011 16:46, James Kerr j...@jkerr82508.free-online.co.uk wrote:
 On 10/06/11 15:27, Oliver Burger wrote:

 James Kerrj...@jkerr82508.free-online.co.uk  schrieb am 10.06.2011

 Even though backports are disabled rpmdrake can display a list of
 available backports. (The sources are automatically updated by
 mgaonline.)

 I make you parden, but: no!

 When a repo is disabled it doesn't get updated automatically and its
 packages are not to be found in rpmdrake.
 Did you confuse disabling repos and marking a repo for updates
 (sorry, me doesn't know the exact English strings).


 So you have to enable the backports repos and even though you don't
 mark them as update repos, urpmi will ignore that (rpmdrake won't
 but urpmi will) and will update everything from those repos...


 I meant exactly what I wrote. Select Backports from the first filter in
 rpmdrake and packages from disabled backports sources will be displayed.

 Check /var/log/auth.log to see what mgaonline is doing.

 Jim



Jim is right; rpmdrake treats backports in a special way, and they
do get updated even when they're disabled. urpmi won't install
packages from them by default (unless you explicitly enable them or
use e.g. 'urpmi --searchmedia Core\ Backports'); rpmdrake can show
packages from disabled backports repos when you select the
Backports filter, assuming they were correctly updated by mgaonline
which is what mgaonline does by default.

-- 
Ahmad Samir

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread Anssi Hannula

On 10.06.2011 17:28, Thorsten van Lil wrote:
 Am 10.06.2011 16:09, schrieb James Kerr:
 On 10/06/11 13:54, Michael Scherer wrote:
 Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :
 Thomas Backlundt...@mageia.org schrieb am 10.06.2011
 So the path would then be */updates_testing - */updates _if_ we
 decide that's the way to go...
 As I see it, it's the only user friendly way. Using backports is fine
 for experienced users who do know what to install from backports or
 who are capable of facing the consequences.
 If a total newbie asks fort a package in the forums and is pointed to
 backports he is in great danger of wrecking his system by installing
 some new kernel, graphics driver, desktop or whatever, precisely
 because there is no real qa on backports.

 He can also wait for the release. Or he can enable backport just for the
 time needed to install and then disable it. I think rpmdrake have some
 stuff for that.


 Even though backports are disabled rpmdrake can display a list of
 available backports. (The sources are automatically updated by
 mgaonline.) A selected backport can then be installed, without enabling
 the backports source. (I've just tested this on mdv 2010.0, the only mdv
 system that I have available.)

 Jim

 
 I've tested it on Mageia right now. I've activated Core-testing and see
 that there is one package inside it: iputils_20101006_3.mga1. After that
 I've disabled the testing repo and searched for iputils. Rpmdrake lists
 me the version 2.mga1. Therefore, rpmdrake only lists packages of the
 activated repos.

Core-testing is not backports. The behavior depends on media name.

-- 
Anssi Hannula

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport? (was: Finalizing update process)

2011-06-10 Thread Ahmad Samir

On 10 June 2011 13:44, Wolfgang Bornath molc...@googlemail.com wrote:
 2011/6/10 Michael Scherer m...@zarb.org:

 We have used backports in the past for that, and I see no reason to
 change that.

 If the problem is that backports were too buggy in the past, then we
 should fix backports process, not bypassing them.

 And if we start by pushing new version in update, people will soon
 wonder why the new version of X is in updates, while the new version of
 Y is not, just because we didn't have X in release and Y was there.

 Problem I see:
 So far (in Mandriva), example:  we have used 2010.0/main/backports to
 offer new versions of software which had an older version in 2010/main
 but the newer version in 2010.1/main, or as the name says: backporting
 a newer version of a software from the current release to a previous
 release, as often used for Firefox.


Firefox should always go to /updates, not backports, usually it has
many sec fixed, so firefox and thunderbird are special cases.

 For Mageia it means, /backports should hold backports of software
 which has an older version in 1/core but a newer version in cauldron.
 If we put new software (aka missing packages) in /backports and the
 user activates /backports he also runs the risk that existing packages
 of his stable installation will be replaced by real backports of newer
 versions, backported from Cauldron - which he may not want to do.


Then he shouldn't use backports; but the point is if a totally new
package, to Mageia 1, that never existed in core, is in backports, the
user shouldn't see any regression with regard to that package as his
experience with it before using backports is null, it didn't exist.

 I wonder why we do not put these missing packages in /testing and
 after a while in /core or /non-free or /tainted (wherever they
 belong). These packages are software which were supposed to be in
 /core or /non-free or /tainted, they were just forgotten|came too
 late|whatever for Mageia 1 release freeze.


There will always be late packages, always. One example is a new
version of foo that was released two days before Mageia's release, it
won't be submitted through freeze, but will go to backports.

IMHO, backports is way to offer late packages to user, whether
they're new packages or newer versions of packages in
core/nonfree/tainted, instead of the user installing them from 3rd
party repos or having to build them himself (not all users are savvy
with [re]building src.rpm's).

 --
 wobo




-- 
Ahmad Samir

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

2011-06-10 Thread andre999

James Kerr a écrit :

On 10/06/11 15:09, James Kerr wrote:

On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlundt...@mageia.org schrieb am 10.06.2011

So the path would then be */updates_testing - */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.

He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.

Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.) A selected backport can then be installed, without enabling
the backports source. (I've just tested this on mdv 2010.0, the only mdv
system that I have available.)

I've just realised there is a potential problem with this. Because
Mageia has /backports_testing repo's (mdv does not) packages from
/backports_testing may also be displayed. Mgaonline is updating those
sources.

Jim

That was a bug in rpmdrake.
If you had updated the repos with backports media enabled, when the backports media was
subsequently disabled, the previously available backports packages remained displayed/installable.
But new backports were not added if the repos were updated with backports disabled. There was
the same problem for other media (like non-free).

Otherwise enabling/disabling backports (or any other media) wouldn't make any
sense.

--
André

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?