Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Tue, 2018-06-19 at 17:33 -0700, Adam Williamson wrote:
> 
> A further update here: it appears releng, at least for the present, is
> inclined to favour manual tagging of just the kickstarts for the actual
> release compose. Given that, I think we should still have a release
> criterion (since this will be a manual process we'd better have
> something to trigger us to make sure it happens). I propose we replace
> the existing criterion with this:
> 
> "At the time of the release, the [https://pagure.io/fedora-kickstarts
> fedora-kickstarts git repository] must have a tag matching the commit used to 
> produce the accepted release candidate compose. The tag's name must clearly 
> and unambiguously match the release number."
> 
> It'd probably be ideal to tag the repo for Beta releases too, but we
> probably only need to *require* the tag to be done for Final.
> 
> How's that sound?

As there were no complaints, I'm going ahead and making this change
now.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/5HKFB6VZDRQNGGCPNEX2UPPQLEZWUJ2A/

Re: Release criteria proposal: drop kickstart package criterion

[Dusty Mabe]

On 06/19/2018 08:33 PM, Adam Williamson wrote:

> 
> A further update here: it appears releng, at least for the present, is
> inclined to favour manual tagging of just the kickstarts for the actual
> release compose. Given that, I think we should still have a release
> criterion (since this will be a manual process we'd better have
> something to trigger us to make sure it happens). I propose we replace
> the existing criterion with this:
> 
> "At the time of the release, the [https://pagure.io/fedora-kickstarts
> fedora-kickstarts git repository] must have a tag matching the commit used to 
> produce the accepted release candidate compose. The tag's name must clearly 
> and unambiguously match the release number."
> 
> It'd probably be ideal to tag the repo for Beta releases too, but we
> probably only need to *require* the tag to be done for Final.
> 
> How's that sound?
> 

+1 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/FEC2P5EETMIFRTKWGQHWNUUIHTNCYPQK/

Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Tue, 2018-06-12 at 12:11 -0700, Adam Williamson wrote:
> On Mon, 2018-06-04 at 16:39 -0700, Adam Williamson wrote:
> > Hi, folks!
> > 
> > We currently have a Final release criterion that reads as follows:
> > 
> > "A spin-kickstarts package which contains the exact kickstart files
> > used to build the release must be present in the release repository.
> > The included kickstarts must define the correct set of release
> > repositories.
> > 
> > Why?
> > 
> > This is considered part of Fedora's duty to be 'self-hosting': the
> > kickstarts used to produce the release images are a vital piece of
> > information required to duplicate that release, so they must be
> > preserved along with the release."
> > 
> > Lately this requirement has been fairly annoying in practice. Updating
> > the package prior to release does not appear to be in anyone's regular
> > schedule, so invariably what happens is shortly before the release
> > deadline I realize we haven't built a 'release' spin-kickstarts package
> > and have to file a blocker bug and ping people with the necessary
> > permissions (of which there are only a few) to build one in a tearing
> > hurry. Then we have to approve the blocker bug and push the updated
> > package through the freeze, all wasting time we could be spending on
> > more important fixes.
> > 
> > The benefit here is really fairly tiny, as well. It's arguable whether
> > anyone cares particularly whether a Fedora release, as a frozen
> > artifact, is 100% internally reproducible (and I'm not sure whether our
> > releases actually *are* reproducible in any case, these days, I'm not
> > at all sure we ship all the necessary metadata and so on for *every
> > single deliverable* within the distribution).
> > 
> > These days I'd suggest it should be quite acceptable to simply use git
> > tags for this purpose. It should be quite easy for rel-eng to adjust
> > the release scripts to create a tag in the fedora-kickstarts repo (and
> > why not fedora-comps too, while we're at it) for each 'candidate'
> > compose, named for the compose ID. That would make it very easy to
> > access the correct kickstarts for any Fedora candidate compose just by
> > a 'git checkout', with no need for the cumbersome work of getting the
> > package into the compose.
> > 
> > Naturally this would go along with updates to any relevant docs or wiki
> > pages, recommending to use the git repository instead of the RPM
> > packages, and explaining the tagging scheme. As for the package, we
> > could either keep it but not sweat about updating it for each release,
> > retire it entirely, or change it to contain only a text file pointing
> > to the git repository (or to the doc / wiki page that explains the git
> > repo location and tagging strategy).
> > 
> > Thoughts? Thanks!
> 
> So an update on this: as the response has generally been positive I'm
> planning to go ahead with it, but I think we should make sure the repo
> tagging thing is done *before* we remove the criterion. So I've filed
> https://pagure.io/releng/issue/7568 for that. Once that's resolved I'll
> go ahead with the criterion removal and docs updates.

A further update here: it appears releng, at least for the present, is
inclined to favour manual tagging of just the kickstarts for the actual
release compose. Given that, I think we should still have a release
criterion (since this will be a manual process we'd better have
something to trigger us to make sure it happens). I propose we replace
the existing criterion with this:

"At the time of the release, the [https://pagure.io/fedora-kickstarts
fedora-kickstarts git repository] must have a tag matching the commit used to 
produce the accepted release candidate compose. The tag's name must clearly and 
unambiguously match the release number."

It'd probably be ideal to tag the repo for Beta releases too, but we
probably only need to *require* the tag to be done for Final.

How's that sound?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/TYO75UEQZI4O4VLWZ7L4A46CVZASDCPY/

Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Mon, 2018-06-04 at 16:39 -0700, Adam Williamson wrote:
> Hi, folks!
> 
> We currently have a Final release criterion that reads as follows:
> 
> "A spin-kickstarts package which contains the exact kickstart files
> used to build the release must be present in the release repository.
> The included kickstarts must define the correct set of release
> repositories.
> 
> Why?
> 
> This is considered part of Fedora's duty to be 'self-hosting': the
> kickstarts used to produce the release images are a vital piece of
> information required to duplicate that release, so they must be
> preserved along with the release."
> 
> Lately this requirement has been fairly annoying in practice. Updating
> the package prior to release does not appear to be in anyone's regular
> schedule, so invariably what happens is shortly before the release
> deadline I realize we haven't built a 'release' spin-kickstarts package
> and have to file a blocker bug and ping people with the necessary
> permissions (of which there are only a few) to build one in a tearing
> hurry. Then we have to approve the blocker bug and push the updated
> package through the freeze, all wasting time we could be spending on
> more important fixes.
> 
> The benefit here is really fairly tiny, as well. It's arguable whether
> anyone cares particularly whether a Fedora release, as a frozen
> artifact, is 100% internally reproducible (and I'm not sure whether our
> releases actually *are* reproducible in any case, these days, I'm not
> at all sure we ship all the necessary metadata and so on for *every
> single deliverable* within the distribution).
> 
> These days I'd suggest it should be quite acceptable to simply use git
> tags for this purpose. It should be quite easy for rel-eng to adjust
> the release scripts to create a tag in the fedora-kickstarts repo (and
> why not fedora-comps too, while we're at it) for each 'candidate'
> compose, named for the compose ID. That would make it very easy to
> access the correct kickstarts for any Fedora candidate compose just by
> a 'git checkout', with no need for the cumbersome work of getting the
> package into the compose.
> 
> Naturally this would go along with updates to any relevant docs or wiki
> pages, recommending to use the git repository instead of the RPM
> packages, and explaining the tagging scheme. As for the package, we
> could either keep it but not sweat about updating it for each release,
> retire it entirely, or change it to contain only a text file pointing
> to the git repository (or to the doc / wiki page that explains the git
> repo location and tagging strategy).
> 
> Thoughts? Thanks!

So an update on this: as the response has generally been positive I'm
planning to go ahead with it, but I think we should make sure the repo
tagging thing is done *before* we remove the criterion. So I've filed
https://pagure.io/releng/issue/7568 for that. Once that's resolved I'll
go ahead with the criterion removal and docs updates.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/P2VCWJS3NOWTE6W6GQTMM4W3L6USTECG/

Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Tue, 2018-06-05 at 21:29 -0400, Neal Gompa wrote:
> 
> I'm not in favor of this change. Actually, what concerns me is that
> there's an underlying problem that caused Adam to propose this: there
> are only a few people with the necessary permissions to be able to
> prepare the release, and that this is a manual process that is
> forgotten often.
> 
> If we were to say: "hey guys, we're just gonna use these autogen'd git
> tag thingies from now on", what stops us from just autogenerating a
> push to generate the required package and have it built in Koji to be
> part of the distribution release?

Two things.

One, auto-building packages is significantly more complex than auto-
tagging a git repo. The git repo is a one-liner: 'git tag {composeid}'.
Building a package is...not. (It also requires privileges the build
process does not have, I don't think).

Two, you missed an important step: things don't go from Koji to 'the
distribution release'. They have to go through Bodhi, and that is by
design *not* automatable during a freeze. Only things that are manually
accepted as release blockers or FEs get through the freeze. That's a
whole other set of hoops to jump through.

> And perhaps this is something that doesn't get talked about much
> anymore, but I know that when I'm presenting Fedora to people, they
> *like* that it's only a couple of package installs away to get
> everything in place to make spins or remixes. And being able to offer
> in the distribution *everything* needed to build it is powerful.

Is 'git clone {url}; git checkout {branch}' that onerous?

> We've been bad about this in recent releases, sure. But why can't we
> look at making that process better, rather than throwing out the baby
> with the bathwater?

There's been about seven years in which that could have happened. It
hasn't. I'm not waiting any longer.
-- 
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
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/SUA6HO4NNIR2MH4P6VBV66GGOUF52ULM/

Re: Release criteria proposal: drop kickstart package criterion

[Neal Gompa]

On Tue, Jun 5, 2018 at 9:21 PM Josh Boyer  wrote:
>
> On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > >  wrote:
> > > > Hi, folks!
> > > >
> > > > We currently have a Final release criterion that reads as follows:
> > > >
> > > > "A spin-kickstarts package which contains the exact kickstart files
> > > > used to build the release must be present in the release repository.
> > > > The included kickstarts must define the correct set of release
> > > > repositories.
> > > >
> > > > Why?
> > > >
> > > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > > kickstarts used to produce the release images are a vital piece of
> > > > information required to duplicate that release, so they must be
> > > > preserved along with the release."
> > > >
> > > > Lately this requirement has been fairly annoying in practice. Updating
> > > > the package prior to release does not appear to be in anyone's regular
> > > > schedule, so invariably what happens is shortly before the release
> > > > deadline I realize we haven't built a 'release' spin-kickstarts package
> > > > and have to file a blocker bug and ping people with the necessary
> > > > permissions (of which there are only a few) to build one in a tearing
> > > > hurry. Then we have to approve the blocker bug and push the updated
> > > > package through the freeze, all wasting time we could be spending on
> > > > more important fixes.
> > > >
> > > > The benefit here is really fairly tiny, as well. It's arguable whether
> > > > anyone cares particularly whether a Fedora release, as a frozen
> > > > artifact, is 100% internally reproducible (and I'm not sure whether our
> > > > releases actually *are* reproducible in any case, these days, I'm not
> > > > at all sure we ship all the necessary metadata and so on for *every
> > > > single deliverable* within the distribution).
> > > >
> > > > These days I'd suggest it should be quite acceptable to simply use git
> > > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > > the release scripts to create a tag in the fedora-kickstarts repo (and
> > > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > > compose, named for the compose ID. That would make it very easy to
> > > > access the correct kickstarts for any Fedora candidate compose just by
> > > > a 'git checkout', with no need for the cumbersome work of getting the
> > > > package into the compose.
> > > >
> > > > Naturally this would go along with updates to any relevant docs or wiki
> > > > pages, recommending to use the git repository instead of the RPM
> > > > packages, and explaining the tagging scheme. As for the package, we
> > > > could either keep it but not sweat about updating it for each release,
> > > > retire it entirely, or change it to contain only a text file pointing
> > > > to the git repository (or to the doc / wiki page that explains the git
> > > > repo location and tagging strategy).
> > > >
> > > > Thoughts? Thanks!
> > >
> > > It makes perfect sense, the package is not actually shipped as part of
> > > any of the actual deliverable artifacts and they're widely available
> > > in a public git repository for people to consume so it's not reducing
> > > the ability to reproduce Fedora, we don't rush around and ensure all
> > > the tools that might need last minute patches in the compose process
> > > are all tagged stable in the release either so I don't see actually
> > > shipping this package as stable makes any difference in reality, we
> > > don't even use the package in the compose process, we pull the
> > > kickstarts directly from git.
> >
> > +1 too.
>
> Yes, let's do what makes sense.  I like the proposal.
>

I'm not in favor of this change. Actually, what concerns me is that
there's an underlying problem that caused Adam to propose this: there
are only a few people with the necessary permissions to be able to
prepare the release, and that this is a manual process that is
forgotten often.

If we were to say: "hey guys, we're just gonna use these autogen'd git
tag thingies from now on", what stops us from just autogenerating a
push to generate the required package and have it built in Koji to be
part of the distribution release?

And perhaps this is something that doesn't get talked about much
anymore, but I know that when I'm presenting Fedora to people, they
*like* that it's only a couple of package installs away to get
everything in place to make spins or remixes. And being able to offer
in the distribution *everything* needed to build it is powerful.

We've been bad about this in recent releases, sure. But why can't we
look at making that process better, rather than throwing out the baby
with the bathwater?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing l

Re: Release criteria proposal: drop kickstart package criterion

[John Florian]

On 06/05/2018 07:59 AM, Stephen Gallagher wrote:



On Tue, Jun 5, 2018 at 7:13 AM Josh Boyer > wrote:


On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
mailto:zbys...@in.waw.pl>> wrote:
>
> On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > mailto:adamw...@fedoraproject.org>> wrote:
> > > Hi, folks!
> > >
> > > We currently have a Final release criterion that reads as
follows:
> > >
> > > "A spin-kickstarts package which contains the exact
kickstart files
> > > used to build the release must be present in the release
repository.
> > > The included kickstarts must define the correct set of release
> > > repositories.
> > >
> > > Why?
> > >
> > > This is considered part of Fedora's duty to be
'self-hosting': the
> > > kickstarts used to produce the release images are a vital
piece of
> > > information required to duplicate that release, so they must be
> > > preserved along with the release."
> > >
> > > Lately this requirement has been fairly annoying in
practice. Updating
> > > the package prior to release does not appear to be in
anyone's regular
> > > schedule, so invariably what happens is shortly before the
release
> > > deadline I realize we haven't built a 'release'
spin-kickstarts package
> > > and have to file a blocker bug and ping people with the
necessary
> > > permissions (of which there are only a few) to build one in
a tearing
> > > hurry. Then we have to approve the blocker bug and push the
updated
> > > package through the freeze, all wasting time we could be
spending on
> > > more important fixes.
> > >
> > > The benefit here is really fairly tiny, as well. It's
arguable whether
> > > anyone cares particularly whether a Fedora release, as a frozen
> > > artifact, is 100% internally reproducible (and I'm not sure
whether our
> > > releases actually *are* reproducible in any case, these
days, I'm not
> > > at all sure we ship all the necessary metadata and so on for
*every
> > > single deliverable* within the distribution).
> > >
> > > These days I'd suggest it should be quite acceptable to
simply use git
> > > tags for this purpose. It should be quite easy for rel-eng
to adjust
> > > the release scripts to create a tag in the fedora-kickstarts
repo (and
> > > why not fedora-comps too, while we're at it) for each
'candidate'
> > > compose, named for the compose ID. That would make it very
easy to
> > > access the correct kickstarts for any Fedora candidate
compose just by
> > > a 'git checkout', with no need for the cumbersome work of
getting the
> > > package into the compose.
> > >
> > > Naturally this would go along with updates to any relevant
docs or wiki
> > > pages, recommending to use the git repository instead of the RPM
> > > packages, and explaining the tagging scheme. As for the
package, we
> > > could either keep it but not sweat about updating it for
each release,
> > > retire it entirely, or change it to contain only a text file
pointing
> > > to the git repository (or to the doc / wiki page that
explains the git
> > > repo location and tagging strategy).
> > >
> > > Thoughts? Thanks!
> >
> > It makes perfect sense, the package is not actually shipped as
part of
> > any of the actual deliverable artifacts and they're widely
available
> > in a public git repository for people to consume so it's not
reducing
> > the ability to reproduce Fedora, we don't rush around and
ensure all
> > the tools that might need last minute patches in the compose
process
> > are all tagged stable in the release either so I don't see
actually
> > shipping this package as stable makes any difference in
reality, we
> > don't even use the package in the compose process, we pull the
> > kickstarts directly from git.
>
> +1 too.

Yes, let's do what makes sense.  I like the proposal.


And my axe! Err, or my +1, yeah.


Ditto!  I've referenced these a number of times to see where my variants 
have gone astray, but have always used the git repo for this and hadn't 
even thought of looking for such an artifact.  The proposal of tags and 
docs will only make this easier.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/YKGYRR3

Re: Release criteria proposal: drop kickstart package criterion

[Stephen Gallagher]

On Tue, Jun 5, 2018 at 7:13 AM Josh Boyer  wrote:

> On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> > >  wrote:
> > > > Hi, folks!
> > > >
> > > > We currently have a Final release criterion that reads as follows:
> > > >
> > > > "A spin-kickstarts package which contains the exact kickstart files
> > > > used to build the release must be present in the release repository.
> > > > The included kickstarts must define the correct set of release
> > > > repositories.
> > > >
> > > > Why?
> > > >
> > > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > > kickstarts used to produce the release images are a vital piece of
> > > > information required to duplicate that release, so they must be
> > > > preserved along with the release."
> > > >
> > > > Lately this requirement has been fairly annoying in practice.
> Updating
> > > > the package prior to release does not appear to be in anyone's
> regular
> > > > schedule, so invariably what happens is shortly before the release
> > > > deadline I realize we haven't built a 'release' spin-kickstarts
> package
> > > > and have to file a blocker bug and ping people with the necessary
> > > > permissions (of which there are only a few) to build one in a tearing
> > > > hurry. Then we have to approve the blocker bug and push the updated
> > > > package through the freeze, all wasting time we could be spending on
> > > > more important fixes.
> > > >
> > > > The benefit here is really fairly tiny, as well. It's arguable
> whether
> > > > anyone cares particularly whether a Fedora release, as a frozen
> > > > artifact, is 100% internally reproducible (and I'm not sure whether
> our
> > > > releases actually *are* reproducible in any case, these days, I'm not
> > > > at all sure we ship all the necessary metadata and so on for *every
> > > > single deliverable* within the distribution).
> > > >
> > > > These days I'd suggest it should be quite acceptable to simply use
> git
> > > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > > the release scripts to create a tag in the fedora-kickstarts repo
> (and
> > > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > > compose, named for the compose ID. That would make it very easy to
> > > > access the correct kickstarts for any Fedora candidate compose just
> by
> > > > a 'git checkout', with no need for the cumbersome work of getting the
> > > > package into the compose.
> > > >
> > > > Naturally this would go along with updates to any relevant docs or
> wiki
> > > > pages, recommending to use the git repository instead of the RPM
> > > > packages, and explaining the tagging scheme. As for the package, we
> > > > could either keep it but not sweat about updating it for each
> release,
> > > > retire it entirely, or change it to contain only a text file pointing
> > > > to the git repository (or to the doc / wiki page that explains the
> git
> > > > repo location and tagging strategy).
> > > >
> > > > Thoughts? Thanks!
> > >
> > > It makes perfect sense, the package is not actually shipped as part of
> > > any of the actual deliverable artifacts and they're widely available
> > > in a public git repository for people to consume so it's not reducing
> > > the ability to reproduce Fedora, we don't rush around and ensure all
> > > the tools that might need last minute patches in the compose process
> > > are all tagged stable in the release either so I don't see actually
> > > shipping this package as stable makes any difference in reality, we
> > > don't even use the package in the compose process, we pull the
> > > kickstarts directly from git.
> >
> > +1 too.
>
> Yes, let's do what makes sense.  I like the proposal.
>
>
And my axe! Err, or my +1, yeah.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/BMDWP3UKY55OGKGS6MQCMF24LRCAWUZP/

Re: Release criteria proposal: drop kickstart package criterion

[Josh Boyer]

On Tue, Jun 5, 2018 at 2:13 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> > On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
> >  wrote:
> > > Hi, folks!
> > >
> > > We currently have a Final release criterion that reads as follows:
> > >
> > > "A spin-kickstarts package which contains the exact kickstart files
> > > used to build the release must be present in the release repository.
> > > The included kickstarts must define the correct set of release
> > > repositories.
> > >
> > > Why?
> > >
> > > This is considered part of Fedora's duty to be 'self-hosting': the
> > > kickstarts used to produce the release images are a vital piece of
> > > information required to duplicate that release, so they must be
> > > preserved along with the release."
> > >
> > > Lately this requirement has been fairly annoying in practice. Updating
> > > the package prior to release does not appear to be in anyone's regular
> > > schedule, so invariably what happens is shortly before the release
> > > deadline I realize we haven't built a 'release' spin-kickstarts package
> > > and have to file a blocker bug and ping people with the necessary
> > > permissions (of which there are only a few) to build one in a tearing
> > > hurry. Then we have to approve the blocker bug and push the updated
> > > package through the freeze, all wasting time we could be spending on
> > > more important fixes.
> > >
> > > The benefit here is really fairly tiny, as well. It's arguable whether
> > > anyone cares particularly whether a Fedora release, as a frozen
> > > artifact, is 100% internally reproducible (and I'm not sure whether our
> > > releases actually *are* reproducible in any case, these days, I'm not
> > > at all sure we ship all the necessary metadata and so on for *every
> > > single deliverable* within the distribution).
> > >
> > > These days I'd suggest it should be quite acceptable to simply use git
> > > tags for this purpose. It should be quite easy for rel-eng to adjust
> > > the release scripts to create a tag in the fedora-kickstarts repo (and
> > > why not fedora-comps too, while we're at it) for each 'candidate'
> > > compose, named for the compose ID. That would make it very easy to
> > > access the correct kickstarts for any Fedora candidate compose just by
> > > a 'git checkout', with no need for the cumbersome work of getting the
> > > package into the compose.
> > >
> > > Naturally this would go along with updates to any relevant docs or wiki
> > > pages, recommending to use the git repository instead of the RPM
> > > packages, and explaining the tagging scheme. As for the package, we
> > > could either keep it but not sweat about updating it for each release,
> > > retire it entirely, or change it to contain only a text file pointing
> > > to the git repository (or to the doc / wiki page that explains the git
> > > repo location and tagging strategy).
> > >
> > > Thoughts? Thanks!
> >
> > It makes perfect sense, the package is not actually shipped as part of
> > any of the actual deliverable artifacts and they're widely available
> > in a public git repository for people to consume so it's not reducing
> > the ability to reproduce Fedora, we don't rush around and ensure all
> > the tools that might need last minute patches in the compose process
> > are all tagged stable in the release either so I don't see actually
> > shipping this package as stable makes any difference in reality, we
> > don't even use the package in the compose process, we pull the
> > kickstarts directly from git.
>
> +1 too.

Yes, let's do what makes sense.  I like the proposal.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/FO72VPNREVN5XKHZ64RXIGFNDCKJCZZ5/

Re: Release criteria proposal: drop kickstart package criterion

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 05, 2018 at 02:26:25AM +0100, Peter Robinson wrote:
> On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
>  wrote:
> > Hi, folks!
> >
> > We currently have a Final release criterion that reads as follows:
> >
> > "A spin-kickstarts package which contains the exact kickstart files
> > used to build the release must be present in the release repository.
> > The included kickstarts must define the correct set of release
> > repositories.
> >
> > Why?
> >
> > This is considered part of Fedora's duty to be 'self-hosting': the
> > kickstarts used to produce the release images are a vital piece of
> > information required to duplicate that release, so they must be
> > preserved along with the release."
> >
> > Lately this requirement has been fairly annoying in practice. Updating
> > the package prior to release does not appear to be in anyone's regular
> > schedule, so invariably what happens is shortly before the release
> > deadline I realize we haven't built a 'release' spin-kickstarts package
> > and have to file a blocker bug and ping people with the necessary
> > permissions (of which there are only a few) to build one in a tearing
> > hurry. Then we have to approve the blocker bug and push the updated
> > package through the freeze, all wasting time we could be spending on
> > more important fixes.
> >
> > The benefit here is really fairly tiny, as well. It's arguable whether
> > anyone cares particularly whether a Fedora release, as a frozen
> > artifact, is 100% internally reproducible (and I'm not sure whether our
> > releases actually *are* reproducible in any case, these days, I'm not
> > at all sure we ship all the necessary metadata and so on for *every
> > single deliverable* within the distribution).
> >
> > These days I'd suggest it should be quite acceptable to simply use git
> > tags for this purpose. It should be quite easy for rel-eng to adjust
> > the release scripts to create a tag in the fedora-kickstarts repo (and
> > why not fedora-comps too, while we're at it) for each 'candidate'
> > compose, named for the compose ID. That would make it very easy to
> > access the correct kickstarts for any Fedora candidate compose just by
> > a 'git checkout', with no need for the cumbersome work of getting the
> > package into the compose.
> >
> > Naturally this would go along with updates to any relevant docs or wiki
> > pages, recommending to use the git repository instead of the RPM
> > packages, and explaining the tagging scheme. As for the package, we
> > could either keep it but not sweat about updating it for each release,
> > retire it entirely, or change it to contain only a text file pointing
> > to the git repository (or to the doc / wiki page that explains the git
> > repo location and tagging strategy).
> >
> > Thoughts? Thanks!
> 
> It makes perfect sense, the package is not actually shipped as part of
> any of the actual deliverable artifacts and they're widely available
> in a public git repository for people to consume so it's not reducing
> the ability to reproduce Fedora, we don't rush around and ensure all
> the tools that might need last minute patches in the compose process
> are all tagged stable in the release either so I don't see actually
> shipping this package as stable makes any difference in reality, we
> don't even use the package in the compose process, we pull the
> kickstarts directly from git.

+1 too.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/3H3WQXVPTLYLC6ZVEL3XLVV6NS6QVCCX/

Re: Release criteria proposal: drop kickstart package criterion

[Peter Robinson]

On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
 wrote:
> Hi, folks!
>
> We currently have a Final release criterion that reads as follows:
>
> "A spin-kickstarts package which contains the exact kickstart files
> used to build the release must be present in the release repository.
> The included kickstarts must define the correct set of release
> repositories.
>
> Why?
>
> This is considered part of Fedora's duty to be 'self-hosting': the
> kickstarts used to produce the release images are a vital piece of
> information required to duplicate that release, so they must be
> preserved along with the release."
>
> Lately this requirement has been fairly annoying in practice. Updating
> the package prior to release does not appear to be in anyone's regular
> schedule, so invariably what happens is shortly before the release
> deadline I realize we haven't built a 'release' spin-kickstarts package
> and have to file a blocker bug and ping people with the necessary
> permissions (of which there are only a few) to build one in a tearing
> hurry. Then we have to approve the blocker bug and push the updated
> package through the freeze, all wasting time we could be spending on
> more important fixes.
>
> The benefit here is really fairly tiny, as well. It's arguable whether
> anyone cares particularly whether a Fedora release, as a frozen
> artifact, is 100% internally reproducible (and I'm not sure whether our
> releases actually *are* reproducible in any case, these days, I'm not
> at all sure we ship all the necessary metadata and so on for *every
> single deliverable* within the distribution).
>
> These days I'd suggest it should be quite acceptable to simply use git
> tags for this purpose. It should be quite easy for rel-eng to adjust
> the release scripts to create a tag in the fedora-kickstarts repo (and
> why not fedora-comps too, while we're at it) for each 'candidate'
> compose, named for the compose ID. That would make it very easy to
> access the correct kickstarts for any Fedora candidate compose just by
> a 'git checkout', with no need for the cumbersome work of getting the
> package into the compose.
>
> Naturally this would go along with updates to any relevant docs or wiki
> pages, recommending to use the git repository instead of the RPM
> packages, and explaining the tagging scheme. As for the package, we
> could either keep it but not sweat about updating it for each release,
> retire it entirely, or change it to contain only a text file pointing
> to the git repository (or to the doc / wiki page that explains the git
> repo location and tagging strategy).
>
> Thoughts? Thanks!

It makes perfect sense, the package is not actually shipped as part of
any of the actual deliverable artifacts and they're widely available
in a public git repository for people to consume so it's not reducing
the ability to reproduce Fedora, we don't rush around and ensure all
the tools that might need last minute patches in the compose process
are all tagged stable in the release either so I don't see actually
shipping this package as stable makes any difference in reality, we
don't even use the package in the compose process, we pull the
kickstarts directly from git.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org/message/Z5IKRMU2AKGMCF3FB2WNWVM6ZD2EYTYK/