Please remember to update rawhide

[Kyle McMartin]

Hi folks,

FESCo has heard a few complaints of cases where packages were newer (in
some cases several versions newer) in F-14 than in rawhide. So this is
just a friendly reminder that you should be updating rawhide
(dist-f15) in addition to branched (dist-f14.) Inheritence from F-14
into rawhide isn't automatic if there's been a separate build in
dist-f15 since the branching, so please keep in mind updating rawhide
as well.

While I'm reminding, just another friendly reminder that you must submit
update requests using bodhi for updates in F-14 as well, as there has
been a bit of confusion about that as well.

regards, Kyle M. for the Fedora Engineering Steering Committee.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Harald Hoyer]

On 09/02/2010 03:02 AM, Kyle McMartin wrote:
>  Hi folks,
>
>  FESCo has heard a few complaints of cases where packages were newer (in
>  some cases several versions newer) in F-14 than in rawhide. So this is
>  just a friendly reminder that you should be updating rawhide
>  (dist-f15) in addition to branched (dist-f14.) Inheritence from F-14
>  into rawhide isn't automatic if there's been a separate build in
>  dist-f15 since the branching, so please keep in mind updating rawhide
>  as well.
>
>  While I'm reminding, just another friendly reminder that you must submit
>  update requests using bodhi for updates in F-14 as well, as there has
>  been a bit of confusion about that as well.
>
>  regards, Kyle M. for the Fedora Engineering Steering Committee.
>  _______________________________________________
>  devel-announce mailing list
>  devel-announce(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel-announce 
Well, can't we automatically forbid to build a package, if the version is higher 
than the existing version in higher Fedora _base_ releases?

This would prevent also that in F12-updates higher versions exist than in 
F13-release, which prevents clean updates sometimes.

Another approach is to put the %{dist} in the epoch :)

[Tom Lane]

Harald Hoyer <harald(a)redhat.com&gt; writes:
>  On 09/02/2010 03:02 AM, Kyle McMartin wrote:
> > FESCo has heard a few complaints of cases where packages were newer (in
> > some cases several versions newer) in F-14 than in rawhide. So this is
> > just a friendly reminder that you should be updating rawhide 
>  Well, can't we automatically forbid to build a package, if the
> version is higher 
>  than the existing version in higher Fedora _base_ releases? 
That would get in the way of a number of useful cases.  For instance,
what if you try to launch builds for several branches in parallel, and
one of the back branches happens to execute first?

What I think would be useful would be to extend the broken-dependency
nagbot so that it also nags if you have a back-branch that's NVR-newer
than any later branch.

IOW: nag good, preventing people from doing their work bad.

			regards, tom lane

[Toshio Kuratomi]

On Wed, Sep 01, 2010 at 09:02:43PM -0400, Kyle McMartin wrote:
>  Hi folks,
>  
>  FESCo has heard a few complaints of cases where packages were newer (in
>  some cases several versions newer) in F-14 than in rawhide. So this is
>  just a friendly reminder that you should be updating rawhide
>  (dist-f15) in addition to branched (dist-f14.) Inheritence from F-14
>  into rawhide isn't automatic if there's been a separate build in
>  dist-f15 since the branching, so please keep in mind updating rawhide
>  as well.
>  
>  While I'm reminding, just another friendly reminder that you must submit
>  update requests using bodhi for updates in F-14 as well, as there has
>  been a bit of confusion about that as well.
>   
This doesn't mention the important problem that prompted the discussion in
FESCo the other day:

When you do an update in F-14 and rely on inheritance to get the package
into rawhide, there is a problem.  That package will not go to rawhide until
it hits stable in F-14.  That means, for the typical F-14 workflow of:

* build for f14.
* Push to testing in f14
* Wait one to two weeks for the package to receive some testing
* Push to stable

rawhide is left with an older inherited build until it is pushed to stable.

i ran into this a few weeks ago when trying to get started on F15
development.  I was experiencing an ICE in gcc that was fixed with a newer
build.  However, that build was done for F14 and inheritance was being
relied upon to get it into F15.  So I couldn't work on the F15 problems
until the build went to stable.

-Toshio

[Tom Lane]

Toshio Kuratomi <a.badger(a)gmail.com&gt; writes:
>  When you do an update in F-14 and rely on inheritance to get the
> package
>  into rawhide, there is a problem.  That package will not go to rawhide until
>  it hits stable in F-14. 
... um ... and why exactly is that the policy?

>  That means, for the typical F-14 workflow of: 
>  * build for f14.
>  * Push to testing in f14
>  * Wait one to two weeks for the package to receive some testing
>  * Push to stable 
>  rawhide is left with an older inherited build until it is pushed to
> stable. 
Which is why this shouldn't be the policy.  Rawhide should inherit the
latest completed build.  It's rawhide, after all.

			regards, tom lane

[Rex Dieter]

Tom Lane wrote:

>  Toshio Kuratomi <a.badger(a)gmail.com&gt; writes:
> > When you do an update in F-14 and rely on inheritance to get the package
> > into rawhide, there is a problem.  That package will not go to rawhide
> > until it hits stable in F-14.
>  
>  ... um ... and why exactly is that the policy? 
I figure one reason is because sometimes updates-testing candidates get 
pulled (and we don't want rawhide to go backwards).

-- Rex

[Tom Lane]

Rex Dieter <rdieter(a)math.unl.edu&gt; writes:
>  Tom Lane wrote:
> > Toshio Kuratomi <a.badger(a)gmail.com&gt; writes:
> >> When you do an update in F-14 and rely on inheritance to get the package
> >> into rawhide, there is a problem.  That package will not go to rawhide
> >> until it hits stable in F-14.
> > 
> > ... um ... and why exactly is that the policy? 
>  I figure one reason is because sometimes updates-testing candidates
> get 
>  pulled (and we don't want rawhide to go backwards). 
No, rawhide shouldn't go backwards.  What I suggested was that rawhide
should be the latest successful build, just as it would be if you *had*
built for rawhide.  Whether it's in updates-testing, updates, or nowhere
shouldn't matter.

If this isn't practical, then people will always have to build rawhide
separately (and we really need the nagbot mentioned elsewhere in this
thread).  But when there is no real need for a separate build, that's
just making extra work for the packager and for the buildfarm.

			regards, tom lane

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/2/10 7:43 AM, Tom Lane wrote:
>  Toshio Kuratomi <a.badger(a)gmail.com&gt; writes:
> > When you do an update in F-14 and rely on inheritance to get the package
> > into rawhide, there is a problem.  That package will not go to rawhide until
> > it hits stable in F-14.
>  
>  ... um ... and why exactly is that the policy?
>  
> > That means, for the typical F-14 workflow of:
>  
> > * build for f14.
> > * Push to testing in f14
> > * Wait one to two weeks for the package to receive some testing
> > * Push to stable
>  
> > rawhide is left with an older inherited build until it is pushed to stable.
>  
>  Which is why this shouldn't be the policy.  Rawhide should inherit the
>  latest completed build.  It's rawhide, after all.
>  
>  			regards, tom lane 
Please see the ticket for why that is not an easy thing to do.

- -- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkx/y+cACgkQ4v2HLvE71NWUiACfSIH90+95BTXsIAwiKhFCBoVv
> HWMAnR0PHkw1/8n8NHEbsubQwRo/LQiN
> =Ov/k
> -----END PGP SIGNATURE-----

[Toshio Kuratomi]

On Thu, Sep 02, 2010 at 10:43:40AM -0400, Tom Lane wrote:
>  Toshio Kuratomi <a.badger(a)gmail.com&gt; writes:
>  > When you do an update in F-14 and rely on inheritance to get the package
>  > into rawhide, there is a problem.  That package will not go to rawhide until
>  > it hits stable in F-14.
>  
>  ... um ... and why exactly is that the policy?
>  
>  > That means, for the typical F-14 workflow of:
>  
>  > * build for f14.
>  > * Push to testing in f14
>  > * Wait one to two weeks for the package to receive some testing
>  > * Push to stable
>  
>  > rawhide is left with an older inherited build until it is pushed to stable.
>  
>  Which is why this shouldn't be the policy.  Rawhide should inherit the
>  latest completed build.  It's rawhide, after all.
>   
Details of why koji makes it hard to do this were put forward by Jesse on
the FESCo ticket.  here's the link:
  https://fedorahosted.org/fesco/ticket/452#comment:4

  -Toshio

[Kyle McMartin]

On Thu, Sep 02, 2010 at 10:38:05AM -0400, Toshio Kuratomi wrote:
>  This doesn't mention the important problem that prompted the
> discussion in
>  FESCo the other day:
>  
>  When you do an update in F-14 and rely on inheritance to get the package
>  into rawhide, there is a problem.  That package will not go to rawhide until
>  it hits stable in F-14.  That means, for the typical F-14 workflow of:
>  
>  * build for f14.
>  * Push to testing in f14
>  * Wait one to two weeks for the package to receive some testing
>  * Push to stable
>  
>  rawhide is left with an older inherited build until it is pushed to stable.
>  
Right, I guess I over simplified things.

Thanks for pointing that out, Toshio.

--Kyle