No Fedora 24 container?

[Josh Berkus]

https://hub.docker.com/_/fedora/

This seems like a big loss, especially for getting folks to test Fedora 24.

-- 
--
Josh Berkus
Project Atomic
Red Hat OSAS

[Matthew Miller]

On Tue, Jun 14, 2016 at 09:43:26PM -0700, Josh Berkus wrote:
>  https://hub.docker.com/_/fedora/
>  This seems like a big loss, especially for getting folks to test Fedora 24. 
Previously, it's been uploaded on release day. I can see an argument
for adding a "devel" tag too.

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Adam Miller]

On Wed, Jun 15, 2016 at 10:39 AM, Matthew Miller
<mattdm(a)fedoraproject.org&gt; wrote:
>  On Tue, Jun 14, 2016 at 09:43:26PM -0700, Josh Berkus wrote:
> > https://hub.docker.com/_/fedora/
> > This seems like a big loss, especially for getting folks to test Fedora 24.
>
>  Previously, it's been uploaded on release day. I can see an argument
>  for adding a "devel" tag too. 
We have rawhide, but normally don't do pre-release branched. Is there
a desire to do so?

-AdamM

>
> --
> Matthew Miller
> <mattdm(a)fedoraproject.org&gt;
> Fedora Project Leader
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Dusty Mabe]

On 06/22/2016 08:35 AM, Adam Miller wrote:
>  On Wed, Jun 15, 2016 at 10:39 AM, Matthew Miller
>  <mattdm(a)fedoraproject.org&gt; wrote:
> > On Tue, Jun 14, 2016 at 09:43:26PM -0700, Josh Berkus wrote:
> >> https://hub.docker.com/_/fedora/
> >> This seems like a big loss, especially for getting folks to test Fedora 24.
> >
> > Previously, it's been uploaded on release day. I can see an argument
> > for adding a "devel" tag too.
>  
>  We have rawhide, but normally don't do pre-release branched. Is there
>  a desire to do so?
>  
>  -AdamM
>   
I could definitely see value in having these images be more
accessible. We could even make it be a different name than `fedora`
so that people know they are using something that is pre-release.

`fedora24prerelease` with tags of date timestamps and `latest` follows
latest prerelease.

I don't know how hard this is to achieve, just describing ideal
scenarios.

Dusty

[Joe Brockmeier]

On Wed, Jun 22, 2016 at 8:43 AM, Dusty Mabe <dusty(a)dustymabe.com&gt; wrote:
>  I could definitely see value in having these images be more
>  accessible. We could even make it be a different name than `fedora`
>  so that people know they are using something that is pre-release.
>
>  `fedora24prerelease` with tags of date timestamps and `latest` follows
>  latest prerelease.
>
>  I don't know how hard this is to achieve, just describing ideal
>  scenarios. 
tl;dr - I'm going to suggest we add a 'next' tag for the upcoming
releases if that's feasible.

Anybody know how other projects handle this? What's the most useful
flow for people building on our container images?

* Alpine has tags for 3.1 -> 3.4 (also "latest") and then "edge"
* Debian has 8.5, 8, jessie, latest and then oldstable, sid, stretch,
testing, unstable...
* Ubuntu, afaik, doesn't have any pre-release images. They have 16.04,
15.10, 14.04, etc. (also with their release names, xenial, wily,
trusty, etc.)

My thought is we'd want all current versions still receiving updates,
plus rawhide, plus the upcoming release. My suggestion would be to add
a tag for "next" that is the upcoming Fedora release.

Thoughts, comments, flames?

Best,

jzb
-- 
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

[Adam Miller]

On Wed, Jun 22, 2016 at 8:17 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote:
>  On Wed, Jun 22, 2016 at 8:43 AM, Dusty Mabe
> <dusty(a)dustymabe.com&gt; wrote:
> >
> > I could definitely see value in having these images be more
> > accessible. We could even make it be a different name than `fedora`
> > so that people know they are using something that is pre-release.
> >
> > `fedora24prerelease` with tags of date timestamps and `latest` follows
> > latest prerelease.
> >
> > I don't know how hard this is to achieve, just describing ideal
> > scenarios.
>
>  tl;dr - I'm going to suggest we add a 'next' tag for the upcoming
>  releases if that's feasible.
>
>  Anybody know how other projects handle this? What's the most useful
>  flow for people building on our container images?
>
>  * Alpine has tags for 3.1 -> 3.4 (also "latest") and then "edge"
>  * Debian has 8.5, 8, jessie, latest and then oldstable, sid, stretch,
>  testing, unstable...
>  * Ubuntu, afaik, doesn't have any pre-release images. They have 16.04,
>  15.10, 14.04, etc. (also with their release names, xenial, wily,
>  trusty, etc.)
>
>  My thought is we'd want all current versions still receiving updates,
>  plus rawhide, plus the upcoming release. My suggestion would be to add
>  a tag for "next" that is the upcoming Fedora release.
>
>  Thoughts, comments, flames? 

My main concern is that we would then introduce a concept of "next"
that isn't well defined within the Release Engineering vocabulary or
the Fedora Project at large as any sort of milestone deliverable.
(Where as in debian land "stable", "testing", and
"unstable"/"sid" are
well defined streams of code/content).

What we could do is release Fedora N+1 at Alpha, Beta, and Final times
and tag is as N-alpha, N-beta, and then finally just N (and latest).

Example:

Fedora 24 is current stable -> docker image:tag fedora:24 and
fedora:latest point to this.

Fedora 25 Alpha is released -> push docker image:tag fedora:25-alpha to the Hub

Fedora 25 Beta is released -> push docker image:tag fedora:25-beta to
the Hub (removing fedora:25-alpha tag)

Fedora 25 GA is released -> push docker image:tag fedora:25 (removing
the fedora:25-beta tag and update fedora:latest to point to fedora:25)

Fedora Rawhide continues rolling along as it does fedora:rawhide (we
tend to update this roughly once a month right now)

Thoughts?

Also, as an aside. Whatever we decide should be brought up with Fedora
RelEng as a meeting ticket to make sure the proposal is workable from
a release perspective (though I suspect it will be and will volunteer
to take that on). I'll also volunteer write up a SOP doc for Fedora
RelEng Documentation so that this information persists and is well
defined if there's future questions about it.

-AdamM

>
> Best,
>
> jzb
> --
> Joe Brockmeier | Community Team, OSAS
> jzb(a)redhat.com | http://community.redhat.com/
> Twitter: @jzb  | http://dissociatedpress.net/
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Jan Pazdziora]

On Wed, Jun 22, 2016 at 10:28:32AM -0500, Adam Miller wrote:
>  
>  My main concern is that we would then introduce a concept of "next"
>  that isn't well defined within the Release Engineering vocabulary or
>  the Fedora Project at large as any sort of milestone deliverable.
>  (Where as in debian land "stable", "testing", and
> "unstable"/"sid" are
>  well defined streams of code/content).
>  
>  What we could do is release Fedora N+1 at Alpha, Beta, and Final times
>  and tag is as N-alpha, N-beta, and then finally just N (and latest).
>  
>  Example:
>  
>  Fedora 24 is current stable -> docker image:tag fedora:24 and
>  fedora:latest point to this.
>  
>  Fedora 25 Alpha is released -> push docker image:tag fedora:25-alpha to the Hub
>  
>  Fedora 25 Beta is released -> push docker image:tag fedora:25-beta to
>  the Hub (removing fedora:25-alpha tag)
>  
>  Fedora 25 GA is released -> push docker image:tag fedora:25 (removing
>  the fedora:25-beta tag and update fedora:latest to point to fedora:25)
>  
>  Fedora Rawhide continues rolling along as it does fedora:rawhide (we
>  tend to update this roughly once a month right now)
>  
>  Thoughts? 
Having easy way to get the next release container after Alpha and not
just rawhide (which is next next by that time) would definitely be
appreciated. Having the name reasonably stable for a couple of weeks
would be a nice benefit, especially for automated testing. Therefore,
fedora:25-alpha, fedora:25-beta would be really good.

I just don't like the proposal of removing fedora:25-alpha the moment
fedora:25-beta is released -- there might be a need to debug some
regression and easy way to get Alpha even after Beta is out might be
useful. I'd propose to remove all pre-release tags one month after the
GA (fedora:25 in this example) has been made available.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

[Adam Miller]

On Thu, Jun 23, 2016 at 1:47 AM, Jan Pazdziora <jpazdziora(a)redhat.com&gt; wrote:
>  On Wed, Jun 22, 2016 at 10:28:32AM -0500, Adam Miller wrote:
> >
> > My main concern is that we would then introduce a concept of "next"
> > that isn't well defined within the Release Engineering vocabulary or
> > the Fedora Project at large as any sort of milestone deliverable.
> > (Where as in debian land "stable", "testing", and
> "unstable"/"sid" are
> > well defined streams of code/content).
> >
> > What we could do is release Fedora N+1 at Alpha, Beta, and Final times
> > and tag is as N-alpha, N-beta, and then finally just N (and latest).
> >
> > Example:
> >
> > Fedora 24 is current stable -> docker image:tag fedora:24 and
> > fedora:latest point to this.
> >
> > Fedora 25 Alpha is released -> push docker image:tag fedora:25-alpha to the Hub
> >
> > Fedora 25 Beta is released -> push docker image:tag fedora:25-beta to
> > the Hub (removing fedora:25-alpha tag)
> >
> > Fedora 25 GA is released -> push docker image:tag fedora:25 (removing
> > the fedora:25-beta tag and update fedora:latest to point to fedora:25)
> >
> > Fedora Rawhide continues rolling along as it does fedora:rawhide (we
> > tend to update this roughly once a month right now)
> >
> > Thoughts?
>
>  Having easy way to get the next release container after Alpha and not
>  just rawhide (which is next next by that time) would definitely be
>  appreciated. Having the name reasonably stable for a couple of weeks
>  would be a nice benefit, especially for automated testing. Therefore,
>  fedora:25-alpha, fedora:25-beta would be really good.
>
>  I just don't like the proposal of removing fedora:25-alpha the moment
>  fedora:25-beta is released -- there might be a need to debug some
>  regression and easy way to get Alpha even after Beta is out might be
>  useful. I'd propose to remove all pre-release tags one month after the
>  GA (fedora:25 in this example) has been made available. 
+1 - Removing pre-release tags when GA becomes available, I think that
makes sense.

-AdamM

>
> --
> Jan Pazdziora
> Senior Principal Software Engineer, Identity Management Engineering, Red Hat
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Joe Brockmeier]

On Wed, Jun 22, 2016 at 11:28 AM, Adam Miller
<maxamillion(a)fedoraproject.org&gt; wrote:
>  My main concern is that we would then introduce a concept of
> "next"
>  that isn't well defined within the Release Engineering vocabulary or
>  the Fedora Project at large as any sort of milestone deliverable.
>  (Where as in debian land "stable", "testing", and
> "unstable"/"sid" are
>  well defined streams of code/content).
>
>  What we could do is release Fedora N+1 at Alpha, Beta, and Final times
>  and tag is as N-alpha, N-beta, and then finally just N (and latest).
>
>  Example:
>
>  Fedora 24 is current stable -> docker image:tag fedora:24 and
>  fedora:latest point to this.
>
>  Fedora 25 Alpha is released -> push docker image:tag fedora:25-alpha to the Hub
>
>  Fedora 25 Beta is released -> push docker image:tag fedora:25-beta to
>  the Hub (removing fedora:25-alpha tag)
>
>  Fedora 25 GA is released -> push docker image:tag fedora:25 (removing
>  the fedora:25-beta tag and update fedora:latest to point to fedora:25)
>
>  Fedora Rawhide continues rolling along as it does fedora:rawhide (we
>  tend to update this roughly once a month right now)
>
>  Thoughts? 
So this fits with our engineering processes, I guess, but I'm
considering the end consumer.

If I'm building images and just want to test with "the next release of
Fedora" I don't know I want to be fiddling with the tags continually.
Especially if I'm doing some kind of workflow with CI/CD and just
checking "did something break"? This feels like a lot of manual
fiddling required. We'll also wind up with a LOT of tags on Docker Hub
(can we delete those?).

I'm mostly hypothesizing, though - I would be interested in hearing
from people consuming the images.

>  Also, as an aside. Whatever we decide should be brought up with
> Fedora
>  RelEng as a meeting ticket to make sure the proposal is workable from
>  a release perspective (though I suspect it will be and will volunteer
>  to take that on). I'll also volunteer write up a SOP doc for Fedora
>  RelEng Documentation so that this information persists and is well
>  defined if there's future questions about it. 
+1

Best,

jzb

-- 
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

[Adam Miller]

On Thu, Jun 23, 2016 at 9:19 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote:
>  On Wed, Jun 22, 2016 at 11:28 AM, Adam Miller
>  <maxamillion(a)fedoraproject.org&gt; wrote:
> > My main concern is that we would then introduce a concept of "next"
> > that isn't well defined within the Release Engineering vocabulary or
> > the Fedora Project at large as any sort of milestone deliverable.
> > (Where as in debian land "stable", "testing", and
> "unstable"/"sid" are
> > well defined streams of code/content).
> >
> > What we could do is release Fedora N+1 at Alpha, Beta, and Final times
> > and tag is as N-alpha, N-beta, and then finally just N (and latest).
> >
> > Example:
> >
> > Fedora 24 is current stable -> docker image:tag fedora:24 and
> > fedora:latest point to this.
> >
> > Fedora 25 Alpha is released -> push docker image:tag fedora:25-alpha to the Hub
> >
> > Fedora 25 Beta is released -> push docker image:tag fedora:25-beta to
> > the Hub (removing fedora:25-alpha tag)
> >
> > Fedora 25 GA is released -> push docker image:tag fedora:25 (removing
> > the fedora:25-beta tag and update fedora:latest to point to fedora:25)
> >
> > Fedora Rawhide continues rolling along as it does fedora:rawhide (we
> > tend to update this roughly once a month right now)
> >
> > Thoughts?
>
>  So this fits with our engineering processes, I guess, but I'm
>  considering the end consumer.
>
>  If I'm building images and just want to test with "the next release of
>  Fedora" I don't know I want to be fiddling with the tags continually.
>  Especially if I'm doing some kind of workflow with CI/CD and just
>  checking "did something break"? This feels like a lot of manual
>  fiddling required. We'll also wind up with a LOT of tags on Docker Hub
>  (can we delete those?). 
I think we can delete them for the base images. I'm not sure about for
layered images.

I can see the end user desire for a moving target to test things
against. This is something we're going to have to fix for Atomic
Two-Week Release soon-ish also.

Following the moving target idea of a "next" tag, would "next" then
point to Rawhide when we're in the limbo period of "post GA, pre
Branched" ?

-AdamM

>
> I'm mostly hypothesizing, though - I would be interested in hearing
> from people consuming the images.
>
>> Also, as an aside. Whatever we decide should be brought up with Fedora
>> RelEng as a meeting ticket to make sure the proposal is workable from
>> a release perspective (though I suspect it will be and will volunteer
>> to take that on). I'll also volunteer write up a SOP doc for Fedora
>> RelEng Documentation so that this information persists and is well
>> defined if there's future questions about it.
>
> +1
>
> Best,
>
> jzb
>
> --
> Joe Brockmeier | Community Team, OSAS
> jzb(a)redhat.com | http://community.redhat.com/
> Twitter: @jzb  | http://dissociatedpress.net/
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Joe Brockmeier]

On Thu, Jun 23, 2016 at 11:37 AM, Adam Miller
<maxamillion(a)fedoraproject.org&gt; wrote:
>  Following the moving target idea of a "next" tag, would
> "next" then
>  point to Rawhide when we're in the limbo period of "post GA, pre
>  Branched" ? 
I think so, yes?

And again - I'm just trying to think through this as a potential
consumer, so folks doing work with the images in this fashion please
chime in. Or if I propose something insanely complicated for rel-eng.

Best,

jzb

-- 
Joe Brockmeier | Community Team, OSAS
jzb(a)redhat.com | http://community.redhat.com/
Twitter: @jzb  | http://dissociatedpress.net/

[Adam Miller]

On Thu, Jun 23, 2016 at 11:09 AM, Joe Brockmeier <jzb(a)redhat.com&gt; wrote:
>  On Thu, Jun 23, 2016 at 11:37 AM, Adam Miller
>  <maxamillion(a)fedoraproject.org&gt; wrote:
> > Following the moving target idea of a "next" tag, would "next"
> then
> > point to Rawhide when we're in the limbo period of "post GA, pre
> > Branched" ?
>
>  I think so, yes?
>
>  And again - I'm just trying to think through this as a potential
>  consumer, so folks doing work with the images in this fashion please
>  chime in. Or if I propose something insanely complicated for rel-eng. 
Oh no, I don't think the proposal is going to be problematic. I just
wanted to write it all out so that I understand it fully and don't
make any incorrect assumptions.

-AdamM

>
> Best,
>
> jzb
>
> --
> Joe Brockmeier | Community Team, OSAS
> jzb(a)redhat.com | http://community.redhat.com/
> Twitter: @jzb  | http://dissociatedpress.net/
> _______________________________________________
> cloud mailing list
> cloud(a)lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/[e-mail]

[Kushal Das]

On 14/06/16, Josh Berkus wrote:
>  https://hub.docker.com/_/fedora/
>
>  This seems like a big loss, especially for getting folks to test Fedora 24.
>   
We push there only after GA. You can see the latest nightly build at
[1].

[1]
https://kojipkgs.fedoraproject.org/compose/branched/latest-Fedora-/compos...

Kushal
-- 
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.in
https://dgplug.org