7:34 a.m.
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
3:17 p.m.
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
4:13 p.m.
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
epel-devel-list(a)redhat.com
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
6:57 p.m.
On 11/5/07, Michael DeHaan <mdehaan(a)redhat.com> 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.
--
Russell Harrison
Systems Administrator -- Linux Desktops
Cisco Systems, Inc.
Note: The positions or opinions expressed in this email are my own.
They are not necessarily those of my employer.
1:05 p.m.
On 06.11.2007 01:57, Russell Harrison wrote:
On 11/5/07, Michael DeHaan <mdehaan(a)redhat.com> 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
2:45 a.m.
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
7:57 a.m.
On Tue, 06 Nov 2007 09:45:40 +0100
Jeroen van Meeuwen <kanarip(a)kanarip.com> 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.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:04 a.m.
On Nov 6, 2007 8:57 AM, Jesse Keating <jkeating(a)redhat.com> wrote:
On Tue, 06 Nov 2007 09:45:40 +0100
Jeroen van Meeuwen <kanarip(a)kanarip.com> 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.
--
Russell Harrison
Systems Administrator -- Linux Desktops
Cisco Systems, Inc.
Note: The positions or opinions expressed in this email are my own.
They are not necessarily those of my employer.
7:20 a.m.
Russell Harrison wrote:
On Nov 6, 2007 8:57 AM, Jesse Keating <jkeating(a)redhat.com>
wrote:
> On Tue, 06 Nov 2007 09:45:40 +0100
> Jeroen van Meeuwen <kanarip(a)kanarip.com> 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
7:39 a.m.
On Wed, 14 Nov 2007 14:20:07 +0100
Jeroen van Meeuwen <kanarip(a)kanarip.com> 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>/
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:06 a.m.
Jesse Keating wrote:
On Wed, 14 Nov 2007 14:20:07 +0100
Jeroen van Meeuwen <kanarip(a)kanarip.com> 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/0x...
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
9:17 a.m.
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 <kanarip(a)kanarip.com> 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/0x...
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/4f...
rob.
9:27 a.m.
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 <kanarip(a)kanarip.com> 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/0x...
>
> 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/4f...
rob.
Thanks, that did it ;-)
Kind regards,
Jeroen van Meeuwen
-kanarip
9:21 a.m.
On Wed, 14 Nov 2007 16:06:04 +0100
Jeroen van Meeuwen <kanarip(a)kanarip.com> 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/0x...
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/4f... 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.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:27 a.m.
On Nov 14, 2007 8:39 AM, Jesse Keating <jkeating(a)redhat.com> 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. ;-)
--
Russell Harrison
Systems Administrator -- Linux Desktops
Cisco Systems, Inc.
Note: The positions or opinions expressed in this email are my own.
They are not necessarily those of my employer.
5995
days inactive
6018
days old
epel-devel@lists.fedoraproject.org
14 comments
6 participants
participants (6)
-
Jeroen van Meeuwen -
Jesse Keating -
Michael DeHaan -
Rob Myers -
Russell Harrison -
Thorsten Leemhuis