Spins keepalive deadline approaching

[Ben Cotton]

FESco previously approved a requirement that Spin/Labs owners send a
keepalive request in order to keep building the spin or lab. I have
opened Pagure issues[1] for all Spins and Labs listed on the wiki[2].

If you are the owner of one of those spins and labs, please reply in
the appropriate ticket by30 January 2019 to indicate the spin should
continue to be produced. If there is a spin or lab that does not have
an open ticket, please create one[3].

The reasoning for this is to not ship spins that are not actively
maintained. Future improvements to the release process that will allow
for teams to self-publish solutions will eventually remove the need
for these keepalives.

[1] https://pagure.io/fedora-project-schedule/issues
[2] https://fedoraproject.org/wiki/Releases/30/Spins
[3] https://pagure.io/fedora-project-schedule/new_issue

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[John Harris]

On Wednesday, January 23, 2019 3:06:17 PM EST Ben Cotton wrote:
>  Future improvements to the release process that will allow for teams
> to
>  self-publish solutions will eventually remove the need for these keepalives. 
Is that really such a great idea? How would release engineering handle that?

-- 
John M. Harris, Jr. <johnmh(a)splentity.com&gt;
Splentity
https://splentity.com/

[Matthew Miller]

On Wed, Jan 23, 2019 at 03:29:44PM -0500, John Harris wrote:
>  > Future improvements to the release process that will allow for
> teams to
>  > self-publish solutions will eventually remove the need for these
>  > keepalives.
>  Is that really such a great idea? How would release engineering handle that? 
I think it's a great idea.

The idea is to move release engineering from being responsible for turning a
crank that puts out releases to owning a *machine* which creates releases
on demand for the groups actually responsible for that release.

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