only keep the latest package in testing?

[Thorsten Leemhuis]

Hi all!

I'm preparing the testing/ -> stable/ move right now; I noticed that in
testing there are often two versions of a package; random example:

koan-0.6.1-2.el5.src.rpm
koan-0.6.2-2.el5.src.rpm

I think that's fine for the proper repo (one can then reinstall the
older version for a short-term-workaround after a update hit the repo
that broke something), but I don't see much need for it in testing, as
one still can go back to the package from testing normally.

Thus I propose we keep only the latest version in testing/ in the
future. If nobody yells loudly over the next few days in response to
this mail I'll "just do it"(tm).

Cu
knurd

[Thorsten Leemhuis]

On 28.10.2007 13:34, Thorsten Leemhuis wrote:
> Hi all!
>
> I'm preparing the testing/ -> stable/ move right now; I noticed that in
> testing there are often two versions of a package; random example:
>
> koan-0.6.1-2.el5.src.rpm
> koan-0.6.2-2.el5.src.rpm
>
> I think that's fine for the proper repo (one can then reinstall the
> older version for a short-term-workaround after a update hit the repo
> that broke something), but I don't see much need for it in testing, as
> one still can go back to the package from testing normally.
>
> Thus I propose we keep only the latest version in testing/ in the
> future. If nobody yells loudly over the next few days in response to
> this mail I'll "just do it"(tm).

I just did it (after Michael made it possible with the push scripts).

Cu
knurd

[Michael DeHaan]

Thorsten Leemhuis wrote:
> Hi all!
>
> I'm preparing the testing/ -> stable/ move right now; I noticed that in
> testing there are often two versions of a package; random example:
>
> koan-0.6.1-2.el5.src.rpm
> koan-0.6.2-2.el5.src.rpm
>
> I think that's fine for the proper repo (one can then reinstall the
> older version for a short-term-workaround after a update hit the repo
> that broke something), but I don't see much need for it in testing, as
> one still can go back to the package from testing normally.
>
> Thus I propose we keep only the latest version in testing/ in the
> future. If nobody yells loudly over the next few days in response to
> this mail I'll "just do it"(tm).
>
> Cu
> knurd
>
> epel-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/epel-devel-list

Not responding because this is my package, just in general.

Thoughts:  Something like F7-updates keeps all the various intermediate 
versions, so should we be more like that?

Personally I use testing like an "updates" repo, just only because 
"testing" is more current than "stable".

If this is based on it being a "testing" repo I am not sure that is 
right as different folks are using it in different ways, but then again, 
I'm not sure
it actually matters that much either.   What are the technical reasons 
for keeping it?

--Michael

[Russell Harrison]

On 11/5/07, Michael DeHaan  wrote:
> If this is based on it being a "testing" repo I am not sure that is
> right as different folks are using it in different ways, but then again,
> I'm not sure
> it actually matters that much either.   What are the technical reasons
> for keeping it?

I can see the use case where a user is testing a fix for package foo
in updates-testing.  As it turns out package foo only partially fixes
the problem.  When the developer pushes out foo +1 to updates-testing
with what he believes is the true fix it turns out to break in the
user's environment for whatever reason.  That user would most likely
like to revert to the original package foo he started with in
updates-testing because it is better than the one in stable for him.
If only one version of a package is in updates-testing at any one time
he wouldn't have that option.

Its the same argument for keeping multiple versions in stable.  Just a
smaller number of users impacted.  It just so happens these are the
users that are most likely helping out the project.  I wonder if there
is a way to age out backup copies of packages.  I don't see any reason
to keep the backup copy after a few weeks, but the hope is that the
package as a whole would have graduated to stable by then anyway.

[Thorsten Leemhuis]

On 06.11.2007 01:57, Russell Harrison wrote:
> On 11/5/07, Michael DeHaan  wrote:
> > If this is based on it being a "testing" repo I am not sure that is
> > right as different folks are using it in different ways, but then again,
> > I'm not sure
> > it actually matters that much either.   What are the technical reasons
> > for keeping it?
>
> I can see the use case where a user is testing a fix for package foo
> in updates-testing.  As it turns out package foo only partially fixes
> the problem.  When the developer pushes out foo +1 to updates-testing
> with what he believes is the true fix it turns out to break in the
> user's environment for whatever reason.  That user would most likely
> like to revert to the original package foo he started with in
> updates-testing because it is better than the one in stable for him.
> If only one version of a package is in updates-testing at any one time
> he wouldn't have that option.

I think we are discussing a hypothetic corner case here that IMHO likely
will happen very rarely and only affect a small number of users.
> Its the same argument for keeping multiple versions in stable.  Just a
> smaller number of users impacted.

Yes.
> It just so happens these are the
> users that are most likely helping out the project.

The same reasons could be applied for rawhide. But for years (until we
got koji) the most important testers were not able to get yesterdays
package. Some people even argued that this is the better approach, as
users that way are forced to report bugs instead of going back as a
workaround.
> [...]

Anyway: currently in testing only one package is kept, as nobody yelled
in the days right after I announced that behavior change. Michael's mail
came right after I flipped the bits iirc. We can change it back -- but I
say we leave it as it is and see what happens.

CU
knurd

[Jeroen van Meeuwen]

Michael DeHaan wrote:
> Thoughts:  Something like F7-updates keeps all the various intermediate 
> versions, so should we be more like that?

Actually F7-updates doesn't keep any other version then the most recent, 
which is a very, very bad thing.

Kind regards,

Jeroen van Meeuwen
-kanarip

[Jesse Keating]

On Tue, 06 Nov 2007 09:45:40 +0100
Jeroen van Meeuwen  wrote:
> Actually F7-updates doesn't keep any other version then the most
> recent, which is a very, very bad thing.

No, it's really not since koji keeps a copy of the build for a good
long time and it can be pulled from there if you really need it.

[Russell Harrison]

On Nov 6, 2007 8:57 AM, Jesse Keating  wrote:
> On Tue, 06 Nov 2007 09:45:40 +0100
> Jeroen van Meeuwen  wrote:
> > Actually F7-updates doesn't keep any other version then the most
> > recent, which is a very, very bad thing.
>
> No, it's really not since koji keeps a copy of the build for a good
> long time and it can be pulled from there if you really need it.

I don't know why I didn't think about koji.  That should be more than
good enough for testing repos.  I do feel that the main updates repos
should have at least the latest two updates available.  I don't know
that as a regular user I would feel confident knowing what the working
version I had was before my update.  As a user installing packages
from testing I should be familiar with koji.  As a normal user, I
don't know that we can expect that.

[Jeroen van Meeuwen]

Russell Harrison wrote:
> On Nov 6, 2007 8:57 AM, Jesse Keating  wrote:
> > On Tue, 06 Nov 2007 09:45:40 +0100
> > Jeroen van Meeuwen  wrote:
> > > Actually F7-updates doesn't keep any other version then the most
> > > recent, which is a very, very bad thing.
> >
> > No, it's really not since koji keeps a copy of the build for a good
> > long time and it can be pulled from there if you really need it.

These builds are not signed in any way though.

Kind regards,

Jeroen van Meeuwen
-kanarip

[Jesse Keating]

On Wed, 14 Nov 2007 14:20:07 +0100
Jeroen van Meeuwen  wrote:
> These builds are not signed in any way though.

Koji keeps a copy of the signed build too, for a period of time before
it's purged.

packages/<name>/<version>/<release>/data/signed/<key>/<arch>/

[Jeroen van Meeuwen]

Jesse Keating wrote:
> On Wed, 14 Nov 2007 14:20:07 +0100
> Jeroen van Meeuwen  wrote:
> > These builds are not signed in any way though.
>
> Koji keeps a copy of the signed build too, for a period of time before
> it's purged.
>
> packages/<name>/<version>/<release>/data/signed/<key>/<arch>/

I'm not sure I'm interpreting this right. Would this be a valid example?

http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/0x4F2...

I tried without '0x' too, but again I'm not even sure I am using the 
correct key.

Thanks in advance for any pointers.

Kind regards,

Jeroen van Meeuwen
-kanarip

[Rob Myers]

On Wed, 2007-11-14 at 16:06 +0100, Jeroen van Meeuwen wrote:
> Jesse Keating wrote:
> > On Wed, 14 Nov 2007 14:20:07 +0100
> > Jeroen van Meeuwen  wrote:
> > > These builds are not signed in any way though.
> >
> > Koji keeps a copy of the signed build too, for a period of time before
> > it's purged.
> >
> > packages/<name>/<version>/<release>/data/signed/<key>/<arch>/
>
> I'm not sure I'm interpreting this right. Would this be a valid example?
>
> http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/0x4F2...
>
> I tried without '0x' too, but again I'm not even sure I am using the 
> correct key.

yes, but the key is lower case:
http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/4f2a6...

rob.

[Jeroen van Meeuwen]

rob myers wrote:
> On Wed, 2007-11-14 at 16:06 +0100, Jeroen van Meeuwen wrote:
> > Jesse Keating wrote:
> > > On Wed, 14 Nov 2007 14:20:07 +0100
> > > Jeroen van Meeuwen  wrote:
> > > > These builds are not signed in any way though.
> > >
> > > Koji keeps a copy of the signed build too, for a period of time before
> > > it's purged.
> > >
> > > packages/<name>/<version>/<release>/data/signed/<key>/<arch>/
> >
> > I'm not sure I'm interpreting this right. Would this be a valid example?
> >
> > http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/0x4F2...
> >
> > I tried without '0x' too, but again I'm not even sure I am using the 
> > correct key.
>
> yes, but the key is lower case:
> http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/4f2a6...
>
> rob.

Thanks, that did it ;-)

Kind regards,

Jeroen van Meeuwen
-kanarip

[Jesse Keating]

On Wed, 14 Nov 2007 16:06:04 +0100
Jeroen van Meeuwen  wrote:
> I'm not sure I'm interpreting this right. Would this be a valid
> example?
>
> http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/0x4F2...
>
> I tried without '0x' too, but again I'm not even sure I am using the 
> correct key.

http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/4f2a6... is correct.

If you just browse to
http://koji.fedoraproject.org/packages/revisor/2.0.5/7.fc7/data/signed/ you can get a directory listing.

[Russell Harrison]

On Nov 14, 2007 8:39 AM, Jesse Keating  wrote:
> Koji keeps a copy of the signed build too, for a period of time before
> it's purged.
>
> packages/<name>/<version>/<release>/data/signed/<key>/<arch>/

You guys think of everything!  I'm impressed yet again.  ;-)