RPM version goes backward in Rawhide
On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote:
> On 7/26/11 1:14 PM, Michael Schwendt wrote: > > Yes, It got untagged. See last week's thread on this list: > > Subject: rpm builds failing with "Installed (but unpackaged) file(s) found" > > I thought there was a hard rule about not having nvrs go backwards, and > if a bad build was put out, it should be fixed with epoch or other such > NVR things to make sure the upgrade path continues. (that is once a > build makes it out in the nightly repos) > Yep. You are correct. If I'm doing proper forensics of fesco meeting notes and tickets and google searches of the wiki, this policy was approved twice by fesco but didn't get documented either time: https://fedorahosted.org/fesco/ticket/96 http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313 The original proposal fell out of the no frozen rawhide FAD if I remember correctly. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Tue, 26 Jul 2011 14:42:09 -0700, TK (Toshio) wrote:
> On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote: > > On 7/26/11 1:14 PM, Michael Schwendt wrote: > > > Yes, It got untagged. See last week's thread on this list: > > > Subject: rpm builds failing with "Installed (but unpackaged) file(s) found" > > > > I thought there was a hard rule about not having nvrs go backwards, and > > if a bad build was put out, it should be fixed with epoch or other such > > NVR things to make sure the upgrade path continues. (that is once a > > build makes it out in the nightly repos) > > > Yep. You are correct. If I'm doing proper forensics of fesco meeting notes > and tickets and google searches of the wiki, this policy was approved twice > by fesco but didn't get documented either time: > > https://fedorahosted.org/fesco/ticket/96 > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313 > > The original proposal fell out of the no frozen rawhide FAD if I remember > correctly. Ticket 96 is very imprecise, unfortunately. There is a big difference between "a package going backwards in its EVR and staying there" and "a package getting untagged because it breaks koji buildroot and with the plan to go forward in EVR as soon as the bug is found and fixed". In this case, the bad rpm-build broke koji builds, and since Rawhide may eat babies, it can happen that Rawhide users need downgrade manually while they have to wait for the fixed rpm-build. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, 2011-07-27 at 11:03 +0200, Michael Schwendt wrote:
> On Tue, 26 Jul 2011 14:42:09 -0700, TK (Toshio) wrote: > > > On Tue, Jul 26, 2011 at 01:24:58PM -0700, Jesse Keating wrote: > > > On 7/26/11 1:14 PM, Michael Schwendt wrote: > > > > Yes, It got untagged. See last week's thread on this list: > > > > Subject: rpm builds failing with "Installed (but unpackaged) file(s) found" > > > > > > I thought there was a hard rule about not having nvrs go backwards, and > > > if a bad build was put out, it should be fixed with epoch or other such > > > NVR things to make sure the upgrade path continues. (that is once a > > > build makes it out in the nightly repos) > > > > > Yep. You are correct. If I'm doing proper forensics of fesco meeting notes > > and tickets and google searches of the wiki, this policy was approved twice > > by fesco but didn't get documented either time: > > > > https://fedorahosted.org/fesco/ticket/96 > > http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090313 > > > > The original proposal fell out of the no frozen rawhide FAD if I remember > > correctly. > > Ticket 96 is very imprecise, unfortunately. > > There is a big difference between "a package going backwards in its EVR > and staying there" and "a package getting untagged because it breaks koji > buildroot and with the plan to go forward in EVR as soon as the bug is > found and fixed". > > In this case, the bad rpm-build broke koji builds, and since Rawhide > may eat babies, it can happen that Rawhide users need downgrade manually > while they have to wait for the fixed rpm-build. +1, this should be only temporary breakage, although the fix is unfortunately not there yet. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On 7/27/11 2:03 AM, Michael Schwendt wrote:
> There is a big difference between "a package going backwards in its EVR > and staying there" and "a package getting untagged because it breaks koji > buildroot and with the plan to go forward in EVR as soon as the bug is > found and fixed". If it goes backwards to await a fix, that fix needs to be happening within the same day or so. Not prolonged so that updates fail on users' systems. > In this case, the bad rpm-build broke koji builds, and since Rawhide > may eat babies, it can happen that Rawhide users need downgrade manually > while they have to wait for the fixed rpm-build. We are trying very hard to kill the notion that "rawhide may eat babies". It's non-productive. There are multiple ways to throw baby-eating updates over the wall for testing before they get into rawhide. Stop treating it like a dumping ground. -- Jesse Keating Fedora -- Freedomē is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, Jul 27, 2011 at 20:46:25 +0200,
drago01 <drago01@gmail.com> wrote: > > The proper fix would have been to just use epoch. People can call them > evil all they want they are perfectly suitable for that kind of > problems. Or just rebuild the old version again. (Which should work unless something external to the package was causing problems.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote:
> On 7/27/11 2:03 AM, Michael Schwendt wrote: > > There is a big difference between "a package going backwards in its EVR > > and staying there" and "a package getting untagged because it breaks koji > > buildroot and with the plan to go forward in EVR as soon as the bug is > > found and fixed". > > If it goes backwards to await a fix, that fix needs to be happening > within the same day or so. Panu has mentioned that he will be looking into fixing this unexpected breakage. If that isn't acceptable to you, feel free to provide a fix faster. > Not prolonged so that updates fail on users' > systems. Do they fail in this case? Do you prefer rpm-build in koji buildroot to fail even longer? An issue with rpm-build on Rawhide installations is minor compared with Fedora's offical buildsys. > > In this case, the bad rpm-build broke koji builds, and since Rawhide > > may eat babies, it can happen that Rawhide users need downgrade manually > > while they have to wait for the fixed rpm-build. > > We are trying very hard to kill the notion that "rawhide may eat > babies". It's non-productive. There are multiple ways to throw > baby-eating updates over the wall for testing before they get into > rawhide. Stop treating it like a dumping ground. Take off your pink glasses. Rawhide *is* a dumping ground. It breaks users' installations regularly because of package maintainers using it as exactly that, a dumping ground for potentially untested builds. And in either case, I'm the wrong target of your flames. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, Jul 27, 2011 at 8:39 PM, Michael Schwendt <mschwendt@gmail.com> wrote:
> On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote: > >> On 7/27/11 2:03 AM, Michael Schwendt wrote: >> > There is a big difference between "a package going backwards in its EVR >> > and staying there" and "a package getting untagged because it breaks koji >> > buildroot and with the plan to go forward in EVR as soon as the bug is >> > found and fixed". >> >> If it goes backwards to await a fix, that fix needs to be happening >> within the same day or so. > > Panu has mentioned that he will be looking into fixing this unexpected > breakage. If that isn't acceptable to you, feel free to provide a fix > faster. > >> Not prolonged so that updates fail on users' >> systems. > > Do they fail in this case? > Do you prefer rpm-build in koji buildroot to fail even longer? > An issue with rpm-build on Rawhide installations is minor compared with > Fedora's offical buildsys. > >> > In this case, the bad rpm-build broke koji builds, and since Rawhide >> > may eat babies, it can happen that Rawhide users need downgrade manually >> > while they have to wait for the fixed rpm-build. The proper fix would have been to just use epoch. People can call them evil all they want they are perfectly suitable for that kind of problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, 2011-07-27 at 20:39 +0200, Michael Schwendt wrote:
> Take off your pink glasses. Rawhide *is* a dumping ground. It breaks > users' installations regularly because of package maintainers using it > as exactly that, a dumping ground for potentially untested builds. And how would we stop that? by...encouraging people not to use it as a dumping ground. What's the best way to achieve that? Try and change the perception of it as a dumping ground... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:
> On Wed, 2011-07-27 at 20:39 +0200, Michael Schwendt wrote: > > > Take off your pink glasses. Rawhide *is* a dumping ground. It breaks > > users' installations regularly because of package maintainers using it > > as exactly that, a dumping ground for potentially untested builds. > > And how would we stop that? by...encouraging people not to use it as a > dumping ground. What's the best way to achieve that? Try and change the > perception of it as a dumping ground... Communication, education, guidelines, policies. Start there? Not even Fedora's official Wiki page is 'trying very hard to kill the notion that "rawhide may eat babies"' (quoting Jesse). http://fedoraproject.org/wiki/Releases/Rawhide | End users should not use Rawhide as their main day-to-day workstation. | Because Rawhide is a development branch, many changes are not heavily | tested (or tested at all) before being released to Rawhide, and packages | in Rawhide can and do break without warning. It is even possible that | bugs in Rawhide could cause data loss. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
RPM version goes backward in Rawhide
On 07/28/2011 04:54 AM, Michael Schwendt wrote:
> On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote: > >> And how would we stop that? by...encouraging people not to use it as a >> dumping ground. What's the best way to achieve that? Try and change the >> perception of it as a dumping ground... > > Communication, education, guidelines, policies. Start there? > > Not even Fedora's official Wiki page is 'trying very hard to kill the > notion that "rawhide may eat babies"' (quoting Jesse). > > http://fedoraproject.org/wiki/Releases/Rawhide Maybe a more nuanced logo, e.g. "rawhide: tries hard to NOT eat babies" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel |
| All times are GMT. The time now is 01:07 PM. |
VBulletin, Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.