[Rdo-list] Juno vs Kilo in Fedora 22

[Mohammed Arafa]

Is there no way to identify how many times the openstack packages have been
downloaded?
With a life cycle of 18 months max I cannot see any sane organisation ... I
take it back I have seen "sane" organisations deploy fedora in production.
And large ones too.

In that case, why not make f21 the last version.
My 0.02$
Thanks
On Apr 13, 2015 9:29 AM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/13/2015 12:46 PM, Alan Pevec wrote:
> > 2015-04-10 19:23 GMT+02:00 Matthias Runge <mrunge at redhat.com>:
> >> Did we had an outcome of this?
> >
> > Status is that we missed F22 Beta freeze on Mar 31, now fesco
> > freeze exception is required and Kilo import is still not completed
> > in Rawhide. I'm also having second thoughts after thinking about
> > Ihar's feedback last week on IRC where he questioned whether the
> > price of maintaining openstack-* packages in stable Fedora is worth
> > it when nobody is actually using them. Until proven otherwise,
> > we're assuming typical OpenStack user on Fedora is interested in
> > development and wants only latest packages, so CVE fixes and
> > upstream stable point release updates are wasted. Production users
> > are expected to run OpenStack on EL platform, which we provide
> > through RDO.
> >
> > Instead of rushing Kilo into F22, I was thinking about the
> > following model: (1) keep latest OpenStack release in Fedora
> > Rawhide, starting from milestone2. Delorean stays RDO Trunk as a
> > place for tracking changes on OpenStack master branch. (2)
> > deprecate openstack-* in released Fedora to avoid maintenance
> > overhead for no use (3) provide Fedora Rawhide builds for current
> > and previous Fedora in RDO repo e.g. Kilo would be available for
> > F22 and F21 through RDO (4) document that for production EL
> > platform is recommended
> >
> > We cannot retire packages in released Fedora, so I'm not sure
> > about the process for (2). f20 branches should definitely be closed
> > since Havana is EOL upstream and in RDO, so there will be no
> > further updates.
>
> If there are security bugs, we should have an ability to patch those.
> So -1 to retiring branches.
>
> I'm fine supporting those packages that are already released in
> current releases (f20 and f21) while those releases are alive, if
> that's a temporary transition thing.
>
> > When I tried fedpkg retire in openstack-keystone f20 branch,
> > "dead.package" commit in dist-git worked[*] but then pkgdb step
> > failed. Ideally, we would push an "empty" update which would warn
> > installed user base that they're running EOLed packages and should
> > migrate to RDO but I'm not sure there's such mechanism in Fedora
> > Bodhi. I'd appreciate any and all feedback on the above plan,
> > please point out the holes it might have. If the plan makes sense,
> > F22 would stay Juno and it would be irrelevant which OpenStack
> > release ends up in Fedora >= 23.
> >
> >
> > Cheers, Alan
> >
> > [*]
> >
> http://pkgs.fedoraproject.org/cgit/openstack-keystone.git/commit/?h=f20&id=2fdfdd6c8eac32334c2a5018fef196b041468979
> >
> >  _______________________________________________ Rdo-list mailing
> > list Rdo-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/rdo-list
> >
> > To unsubscribe: rdo-list-unsubscribe at redhat.com
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVK8RaAAoJEC5aWaUY1u57jA4H/iy0w5DRJ8RsebOm6mPhGeRj
> SCBppYcukqh9zZTAuULHq7RNlIf633hQGiniDgK5f2DhspW4Tpc7f6WqYRDRq7Fy
> jTy+5Gnf80Gq3sulB3lq04fKCGeuAcmp9CulnVlxDtBP3hsvpJl50A1diOXamXvz
> 4M4ng9w3EI2iBm64vcVLUmQSBlGxwiMO++8y77NPIRT4MJsBl4JmAyb9ax09c0m8
> kzbbk07v4Orm2UkHmp6RBMj1TvvNETyYG+aCfZld5og0P0s9rdWVJbcNa7y+Fsxx
> i1kliZuB6QRgoNuMzfazoUEIxQbrOAyIzB6W9N6srPXHs1PuV+nckfIugS7ZeuU=
> =YXaC
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Rdo-list mailing list
> Rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rdoproject.org/pipermail/dev/attachments/20150413/f3186b9e/attachment.html>