[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 11:28:10AM -0700, Troy Dawson wrote: > On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > > ...snip... > > > > > > When a maintainer is done with their package in playground, they must > > > untag all builds of it out of epel-playground. We do not want > > > epel-playground cluttered with old test packages. Done means either > > > the package has been moved to regular EPEL, and / or the maintainer no > > > longer wants to play and test in epel-playground. Untagging all > > > builds of a package is currently done via a release engineering > > > ticket. > > > > This puts more work on releng, but I am not sure how often it will come > > up. We could also create a 'epel-sig' permission and grant everyone in > > that group permissions to untag from playground? > > > > Otherwise, looks good to me. > > > > kevin > > If the maintainer could do it themselves, I'm ok with that. But > currently, I don't think they can. They cannot. We would need to create a new koji permission and add people to it, or just have releng do it. > If we can get something better than rel-eng, I'm all for it. But as > far as I know, that's what we currently have to do. > We can update it when we get something better in place. Well, I think it might be worthwhile to add a permission and a small group of people who can do it, then they could process the releng tickets too. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On 15. 09. 20 18:18, Troy Dawson wrote: When a maintainer is done with their package in playground, they must untag all builds of it out of epel-playground. We do not want epel-playground cluttered with old test packages. Done means either the package has been moved to regular EPEL, and / or the maintainer no longer wants to play and test in epel-playground. Untagging all builds of a package is currently done via a release engineering ticket. Thanks. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote: > > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: > ...snip... > > > > When a maintainer is done with their package in playground, they must > > untag all builds of it out of epel-playground. We do not want > > epel-playground cluttered with old test packages. Done means either > > the package has been moved to regular EPEL, and / or the maintainer no > > longer wants to play and test in epel-playground. Untagging all > > builds of a package is currently done via a release engineering > > ticket. > > This puts more work on releng, but I am not sure how often it will come > up. We could also create a 'epel-sig' permission and grant everyone in > that group permissions to untag from playground? > > Otherwise, looks good to me. > > kevin If the maintainer could do it themselves, I'm ok with that. But currently, I don't think they can. If we can get something better than rel-eng, I'm all for it. But as far as I know, that's what we currently have to do. We can update it when we get something better in place. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote: ...snip... > > When a maintainer is done with their package in playground, they must > untag all builds of it out of epel-playground. We do not want > epel-playground cluttered with old test packages. Done means either > the package has been moved to regular EPEL, and / or the maintainer no > longer wants to play and test in epel-playground. Untagging all > builds of a package is currently done via a release engineering > ticket. This puts more work on releng, but I am not sure how often it will come up. We could also create a 'epel-sig' permission and grant everyone in that group permissions to untag from playground? Otherwise, looks good to me. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
This is the second draft. It has added a section in the developer section saying to clean your packages up when you are done playing and testing them. Edit's are still welcome, but I think it covers everything that has been discussed and approved. This will be published about the same time that - fedpkg doesn't require you to build playground when building epel -- https://pagure.io/fedpkg/issue/414 - package.cfg isn't automatically added to epel8 branches when they are created -- https://pagure.io/fedora-infrastructure/issue/9322 == # EPEL PLAYGROUND We have added an additional set of channels for EPEL-8 called playground. It is meant to be sort of like Fedora Rawhide so that packagers can work on versions of software which are too fast moving or will have large API changes from what they are putting in the regular channel. Packages in epel8-playground are primarily to be used in the following manner: * To test out some new version of the package that might not be stable yet. * To test out some new packaging of the package * To test a major version change of the package that they want to land at the next epel8 minor release. * To build a package that will never be stable enough for epel8, but still could be useful to some. ## Consumers / End Users Consumers should be aware that packages in EPEL8-playground are there without any Service Level Expectations. You may want to only cherry pick packages from there as needed. EPEL8-playground is not a full EPEL release. It only has those packages that developers and maintainers are "playing" around with. Because of this, you should not expect to enable only epel-playground and get everything you need. It is expected that you have regular epel enabled whenever you enable epel-playground. ## Developers / Maintainers epel8-playground builds are NOT automatically built when you build in epel8. This is a change from the original vision. #(Remove this sentence after a few years) You must use the epel8-playground branch and build from there, just like you would any other Fedora / EPEL build area. Packages in epel-playground will never be automatically put into regular epel. That is the responsibility of the package maintainer. It is recommended that if a maintainer plans to bring a package that has a large change from epel-playground to regular epel, they do it at minor RHEL releases (ie, 8.3, 8.4). Since end users will be upgrading and paying more attention than usual at those times, it’s a great chance to make larger changes. Be sure to announce those major changes well in advance on epel-devel and epel-announce. When a maintainer is done with their package in playground, they must untag all builds of it out of epel-playground. We do not want epel-playground cluttered with old test packages. Done means either the package has been moved to regular EPEL, and / or the maintainer no longer wants to play and test in epel-playground. Untagging all builds of a package is currently done via a release engineering ticket. EPEL Playground has traits similar to Fedora Rawhide. * Built packages do not need to be tagged with override to get into the epel8-playground build repository. They will be put in the next time the build repository is refreshed. This is usually within 15 to 60 minutes. * The main epel8-playground repository is built once a day, just like Fedora Rawhide. Thus built packages are usually available in epel8-playground the day after they are built. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Wed, Sep 9, 2020 at 2:44 PM Miro Hrončok wrote: > > On 08. 09. 20 17:52, Troy Dawson wrote: > > Note1: Not everything has been implemented yet. package.cfg is still > > in the epel repos. fedpkg has not been updated. This documentation > > will go out when those changes are implemented. > > > > Note2: This is a proposal. It can be changed. If there is something > > in there you do not want or think should be re-worded, please say so. > > Is there a set of guidelines associated with epel8-playground? Such as, for > example: > > - New builds in epel8-playground should be done with higher NEVRs than builds > in > epel8. > > - When an "experiment" in epel8-playground is finished (and either > "backported" > to epel8 or abandoned), the builds should be untagged from playground, to > allow > other maintainers to successfully conduct their own experiments without > building > against a possibly obsolete version of your package. > > ... > Very good point. I think that would go in the developer section. I'll try to get an updated draft out tomorrow. Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On 08. 09. 20 17:52, Troy Dawson wrote: Note1: Not everything has been implemented yet. package.cfg is still in the epel repos. fedpkg has not been updated. This documentation will go out when those changes are implemented. Note2: This is a proposal. It can be changed. If there is something in there you do not want or think should be re-worded, please say so. Is there a set of guidelines associated with epel8-playground? Such as, for example: - New builds in epel8-playground should be done with higher NEVRs than builds in epel8. - When an "experiment" in epel8-playground is finished (and either "backported" to epel8 or abandoned), the builds should be untagged from playground, to allow other maintainers to successfully conduct their own experiments without building against a possibly obsolete version of your package. ... -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed EPEL Playground Documentation
On Tue, Sep 08, 2020 at 08:52:39AM -0700, Troy Dawson wrote: > Note1: Not everything has been implemented yet. package.cfg is still > in the epel repos. fedpkg has not been updated. This documentation > will go out when those changes are implemented. > > Note2: This is a proposal. It can be changed. If there is something > in there you do not want or think should be re-worded, please say so. Looks good to me. +1 and thanks for writing it up. kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
