Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, Nov 03, 2020 at 09:10:01AM +0100, Michał Górny wrote: > On Tue, 2020-11-03 at 07:13 +0200, Joonas Niilola wrote: > > I'm suggesting a new QA policy to disallow any "live-ebuild-only > > packages" being hosted in ::gentoo. > > I'm with you on this though I think it should be relaxed to disallow > only long term presence of pure live packages. It's fine to add a live > ebuild first for a month or two if you're still working on something > (just like it's fine to add a masked package). However, it's not fine > to leave things like this for years. > > That said, maybe the policy should cover 'long-term masked packages' > in general. See below. I agree with this. long term is definitely not good, but I typically add the live ebuild to test first before I do the real ones. SELinux packages specifically I have a script which handles bumping all of them properly by copying the - to the current as I cut a release. So to add a new policy, I'll add the - ebuild a while before. The aim is obviously on the order of days but sometimes ENOTIME so it might be a while longer. Thanks, Jason
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/5/20 6:03 AM, Alec Warner wrote: > > > The result is that we should remove badly maintained stuff; not create > more policies. > > -A > Feel like I'm repeating myself... but such policy would prevent us from getting into situation like this in the first place, with more CI coverage available, and better visibility to users. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Wed, Nov 4, 2020 at 7:38 PM Joonas Niilola wrote: > > > On 11/4/20 11:19 PM, Rich Freeman wrote: > > Did you consider that somebody could read your email and not actually > > agree with you? > Impossible! My suggestion is about keeping the tree clean and to provide > the best user experience. Who'd disagree with that?! > > Sure the methods for achieving that can be discussed, but if I find ~50 > % of current live-only packages being unbuildable, don't you agree > there's a problem with them? And regardless the outcome of this policy > suggestion, I've filed 14 bugs to maintainers notifying their --only > packages aren't working. > > > Does it work? If so, then there is no harm. If not, then just remove > > it - you don't need a new policy to treeclean stuff that doesn't work. > One of the selling points to this policy suggestion is that they'd get > CI coverage, which they currently don't. Why keep dead weight around for > years that apparently no one uses, not even the maintainer themself. > > > You're saying that live-only packages should be removed because they > > could have snapshots. I'm saying that if you want to maintain a > > snapshot just add it and co-maintain - you don't have to remove > > packages that don't have them. > I'm saying currently maintainers aren't doing very good job at > maintaining them, and no one else uses/finds these packages. > Again though, this isn't about having a policy against X or Y and seems instead to be a policy against unmaintained stuff...and I think we mostly have a policy against that already; there is a whole team who removes stuff (treecleaners). The result is that we should remove badly maintained stuff; not create more policies. -A > > -- juippis > > > >
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/4/20 11:12 PM, Matt Turner wrote: > > Is there value in making snapshots of app-portage/no-distcc-env? > > I don't really think so, and that's why I didn't do it. Should I reconsider? > We havy many similar packages keyworded, like all theme packages. Last upstream commit was made 1 year ago, couldn't you treat it as a release at that point? Does it make sense to have a live ebuild for stagnated upstream? 1 year is enough time to get even ~alpha keyworded, although in this case ALLARCHES would apply. On a more principal level I do wonder why this is an ebuild at all, should we all package our /etc/portage configs? But as a distcc user I could find this useful, and with keywords and 'optfeature' added to distcc, you could find more users reporting more packages to be added upstream. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/4/20 11:19 PM, Rich Freeman wrote: > Did you consider that somebody could read your email and not actually > agree with you? Impossible! My suggestion is about keeping the tree clean and to provide the best user experience. Who'd disagree with that?! Sure the methods for achieving that can be discussed, but if I find ~50 % of current live-only packages being unbuildable, don't you agree there's a problem with them? And regardless the outcome of this policy suggestion, I've filed 14 bugs to maintainers notifying their --only packages aren't working. > Does it work? If so, then there is no harm. If not, then just remove > it - you don't need a new policy to treeclean stuff that doesn't work. One of the selling points to this policy suggestion is that they'd get CI coverage, which they currently don't. Why keep dead weight around for years that apparently no one uses, not even the maintainer themself. > You're saying that live-only packages should be removed because they > could have snapshots. I'm saying that if you want to maintain a > snapshot just add it and co-maintain - you don't have to remove > packages that don't have them. I'm saying currently maintainers aren't doing very good job at maintaining them, and no one else uses/finds these packages. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Wed, Nov 04, 2020 at 06:24:39PM +, Alexey Sokolov wrote:
> 04.11.2020 19:10, Marty E. Plummer пишет:
> > On Tue, Nov 03, 2020 at 07:13:32AM +0200, Joonas Niilola wrote:
> >> Hey,
> >>
> > <-snip->
> > Just my 2c, One of the major reasons I use gentoo is the ability to use
> > live ebuilds relatively easily. One has the equivalent in arch linux in
> > the form of ${pkgname}-${vcs} aur packages but keeping them up to date
> > is quite annoying.
> >>
> >> -- juippis
> >>
> >
>
> What you're describing is live ebuilds, and I agree they are useful.
> Joonas was talking about packages which have *only* live ebuilds, and no
> other versions, and not even snapshots.
>
I must have misread, then, as I assumed a kill of all ${PN}-**.ebuild
I suppose no live-only is reasonable for the most part, if there are
non-live releases (not all software is at that point in their release
cycles).
> --
> Best regards,
> Alexey "DarthGandalf" Sokolov
>
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, Nov 03, 2020 at 07:13:32AM +0200, Joonas Niilola wrote:
> Hey,
>
<-snip->
Just my 2c, One of the major reasons I use gentoo is the ability to use
live ebuilds relatively easily. One has the equivalent in arch linux in
the form of ${pkgname}-${vcs} aur packages but keeping them up to date
is quite annoying.
>
> -- juippis
>
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Wed, Nov 4, 2020 at 3:57 PM Joonas Niilola wrote: > > On 11/4/20 10:43 PM, Rich Freeman wrote: > > > > Do you really think that users who just blindly run "emerge > > --autounmask-write" are going to be both masking and unmasking > > packages by hand (per your other email)? > Just by following wiki... > > > > > And how are they any better off if they do? They just end up in the > > exact same state, except now we have zero control over their > > experience instead of only a little control. > Exactly, we should try to prevent this situation! Glad we agree. > Great, then no need to remove working packages that only have live versions. Just add snapshots where appropriate. > > > > Then why not do that, instead of removing things? > Did you bother reading my reply? Did you consider that somebody could read your email and not actually agree with you? > There's work being done towards fixing > packages which seem to have hope. Now for some of these packages there's > been last upstream activity 8 years ago. Is having a - ebuild > justified there? Does it work? If so, then there is no harm. If not, then just remove it - you don't need a new policy to treeclean stuff that doesn't work. > Also for some, upstream is dead, gone, making the > package totally un-emergeable. Then treeclean it. Again, no need for a new policy here. Stuff that doesn't build is already grounds for removal if it isn't fixed in a timely manner. > Now imagine if we had a snapshot tarball > in our mirrors, maybe it wouldn't need to be removed, if it still could > be built. Stuff that has no working SRC_URI still should be removed. By all means create your own upstream for it if you wish. Removing that package years ago wouldn't have done anything to make a snapshot available. You're saying that live-only packages should be removed because they could have snapshots. I'm saying that if you want to maintain a snapshot just add it and co-maintain - you don't have to remove packages that don't have them. -- Rich
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, Nov 3, 2020 at 12:13 AM Joonas Niilola wrote: > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. Is there value in making snapshots of app-portage/no-distcc-env? I don't really think so, and that's why I didn't do it. Should I reconsider?
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/4/20 10:43 PM, Rich Freeman wrote: > > Do you really think that users who just blindly run "emerge > --autounmask-write" are going to be both masking and unmasking > packages by hand (per your other email)? Just by following wiki... > > And how are they any better off if they do? They just end up in the > exact same state, except now we have zero control over their > experience instead of only a little control. Exactly, we should try to prevent this situation! Glad we agree. > > Then why not do that, instead of removing things? Did you bother reading my reply? There's work being done towards fixing packages which seem to have hope. Now for some of these packages there's been last upstream activity 8 years ago. Is having a - ebuild justified there? Also for some, upstream is dead, gone, making the package totally un-emergeable. Now imagine if we had a snapshot tarball in our mirrors, maybe it wouldn't need to be removed, if it still could be built. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Wed, Nov 4, 2020 at 2:46 PM Joonas Niilola wrote: > > On 11/4/20 8:52 PM, Rich Freeman wrote: > > > > 4. If somebody finds one they probably have to add some random > > overlay to their config, which causes this package to become > > available, probably along with 47 other packages that can potentially > > conflict with other things in the tree, all with zero QA. > (It's common practice to mask the entire overlay then unmask the > package(s) you need from it) > Do you really think that users who just blindly run "emerge --autounmask-write" are going to be both masking and unmasking packages by hand (per your other email)? And how are they any better off if they do? They just end up in the exact same state, except now we have zero control over their experience instead of only a little control. > > Certainly it is good to have snapshotted versions that get more QA > > where appropriate, and that should probably be communicated. When it > > is done with an "or else" attached the result is likely to be that a > > lot of stuff just gets removed, with little benefit... > > > Well my intention is to get up-to-date packages KEYWORDED properly, for > better visibility and support. > Then why not do that, instead of removing things? We should be careful with QA policies to avoid the concept that we want somebody to do A, but we can't make them do A, so we tell them they're not allowed to do B unless they also do A, and then we're shocked when nobody wants to do B now. If A is absolutely essential then maybe it is better to not have B to ensure that A happens. However, often A is a nice-to-have, and we end up pruning stuff that really isn't that bad because we were just trying to force devs to do something else. If we want snapshots, then we should just add snapshots. Removing the package doesn't accomplish adding a snapshot. -- Rich
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/4/20 8:52 PM, Rich Freeman wrote: > > If you remove them from the tree: If they have an active upstream and/or tagged releases, and the package builds, I'd much rather keyword than remove them. There's already work being done towards this, https://bugs.gentoo.org/752429 https://bugs.gentoo.org/752447 https://bugs.gentoo.org/752423 https://bugs.gentoo.org/752456 https://bugs.gentoo.org/752426 https://bugs.gentoo.org/752438 etc. > 4. If somebody finds one they probably have to add some random > overlay to their config, which causes this package to become > available, probably along with 47 other packages that can potentially > conflict with other things in the tree, all with zero QA. (It's common practice to mask the entire overlay then unmask the package(s) you need from it) > Certainly it is good to have snapshotted versions that get more QA > where appropriate, and that should probably be communicated. When it > is done with an "or else" attached the result is likely to be that a > lot of stuff just gets removed, with little benefit... > Well my intention is to get up-to-date packages KEYWORDED properly, for better visibility and support. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/4/20 8:18 PM, Alec Warner wrote: > > I disagree. These packages are not installable by default, and must be > unmasked by users, so this tradeoff is one we expect them to make. Are > there practical problems that these packages pose to developers? You > listed a bunch of user problems, but again users are opting into these > problems, presumably. I just managed to install Gentoo yesterday, today I want package x and apparently it's masked? I type emerge --autounmask-write x because the guide told me so without understanding any of the concerns (that are also written in devmanual) listed above. I have no idea what I'm doing, but at least I got the package on stable system... if upstream wasn't so broken currently. Now imagine you're a developer and you need a certain library to develop your software, but the upstream repo has been broken for weeks or months. You couldn't emerge the package, but if there was a snapshot available to a latest working commit, it could save a lot of your time. > > But again, why are we making this a firm policy; as opposed to letting > the maintainer make their decision? Look where maintainer decision got us, majority of these ebuilds being broken, outdated and totally ignored. There aren't that many packages available right now, but the state could still be cleaner. Wouldn't you like the solution offered by mgorny, where there could be a time-limit for these --only packages? > > > We can't guarantee any package to build..so I'm not sure how this is a > practical policy goal. > > -A Sure we can. You test it before you push, then it hits at least two tinderboxes currently. Before stabilization multiple test runs are made. I do trust the current state of Gentoo packages being better and better each day. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Wed, Nov 4, 2020 at 1:39 PM Marty E. Plummer wrote:
>
> On Wed, Nov 04, 2020 at 06:24:39PM +, Alexey Sokolov wrote:
> >
> > What you're describing is live ebuilds, and I agree they are useful.
> > Joonas was talking about packages which have *only* live ebuilds, and no
> > other versions, and not even snapshots.
> >
> I must have misread, then, as I assumed a kill of all ${PN}-**.ebuild
> I suppose no live-only is reasonable for the most part, if there are
> non-live releases (not all software is at that point in their release
> cycles).
This still seems like a solution searching for a problem. What is the
downside to having these in the tree?
If you remove them from the tree:
1. They move from having minimal QA to zero QA.
2. They don't get updated when larger Gentoo-wide things happen.
3. People have to do searches to realize they even exist.
4. If somebody finds one they probably have to add some random
overlay to their config, which causes this package to become
available, probably along with 47 other packages that can potentially
conflict with other things in the tree, all with zero QA.
Obviously if somebody notices that such an ebuild is broken it should
get treecleaned if the maintainer doesn't respond to a bug. However,
it sounds like we're talking about a handful of packages after almost
two decades of allowing them. Since they're masked, they don't do
anything unless somebody actually goes poking at them, and if they do
they probably file a bug and they'll go away.
Certainly it is good to have snapshotted versions that get more QA
where appropriate, and that should probably be communicated. When it
is done with an "or else" attached the result is likely to be that a
lot of stuff just gets removed, with little benefit...
--
Rich
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
04.11.2020 19:10, Marty E. Plummer пишет:
> On Tue, Nov 03, 2020 at 07:13:32AM +0200, Joonas Niilola wrote:
>> Hey,
>>
> <-snip->
> Just my 2c, One of the major reasons I use gentoo is the ability to use
> live ebuilds relatively easily. One has the equivalent in arch linux in
> the form of ${pkgname}-${vcs} aur packages but keeping them up to date
> is quite annoying.
>>
>> -- juippis
>>
>
What you're describing is live ebuilds, and I agree they are useful.
Joonas was talking about packages which have *only* live ebuilds, and no
other versions, and not even snapshots.
--
Best regards,
Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Mon, Nov 2, 2020 at 9:13 PM Joonas Niilola wrote: > Hey, > > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. Rationale being the same as why > - packages can't have KEYWORDS: They are unpredictable and > potentially insecure. Unpredictability could mean upstream repo being > broken at any given time placing users in an awkward situation, where > they are able to build some packages while not the others. Upstream > repo can also be force-pushed over. I feel like packages offered in > ::gentoo shouldn't have these issues, and the need to have at least one > safe release available to users that's guaranteed to build. > I disagree. These packages are not installable by default, and must be unmasked by users, so this tradeoff is one we expect them to make. Are there practical problems that these packages pose to developers? You listed a bunch of user problems, but again users are opting into these problems, presumably. > > With Git-like VCS's becoming popular, it is super easy to create an > unchanged snapshot based on a commit. Even devmanual encourages this > with proper guide how-to: > > https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#snapshots-and-live-ebuilds >(https://devmanual.gentoo.org/keywording/index.html) > > We currently have 43 "live-ebuild-only" packages in tree. Out of those > 19 are totally unbuildable, that's 44 % of all packages present in the > repo. Overall the maintenance of these live-ebuild-only packages looks > low, there's only a handful of ebuilds that have good quality and no > issues at all. 12 of them, 28 %, are still on EAPI-5. Of all 43, only 2 > would require the maintainer to generate a tarball by themself, while > others can utilize upstream's tagged releases, or ability to make a > snapshot from a specific commit. Obviously if this policy passes, I'll > be helping getting these packages keyworded. > But again, why are we making this a firm policy; as opposed to letting the maintainer make their decision? > > And finally here's an example how to introduce new packages to tree > without upstream releases: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/rlottie?id=42873c46b7ed07d5b4f8af5fcf08d8549cb6385b > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=2de52234783be909f6e4aed333533e6a804e8e6b > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=8305f0c6cd0ce8cb5ac0f2d92569acce36a5cc0a >etc... > > https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=24c48b325dd5a22284d077d6581a1a45e397e511 > > If the only available version for a package doesn't build - or can't be > guaranteed to build - then it should be last-rited, or not exist in > ::gentoo repo at all. > We can't guarantee any package to build..so I'm not sure how this is a practical policy goal. -A > > Some history and initiative: bug #713802 > > -- juippis > >
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 2020-11-03 Tue 01:28, Joonas Niilola wrote: > Initially Arfrever suggested the same, I wasn't a fan of it because I > believe it's much simpler to make this into a pkgcheck/repoman check like > this. > > However with pkgcheck maybe a similar logic can be used as is used with > StableRequestCheck. So no objections there I guess. That's simple to achieve with pkgcheck's git support. LiveOnlyCheck now flags packages with only live ebuilds that were all added at least a year ago [1]. [1]: https://github.com/pkgcore/pkgcheck/commit/df4e40c2c2
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 11/3/20 10:10 AM, Michał Górny wrote: I'm with you on this though I think it should be relaxed to disallow only long term presence of pure live packages. It's fine to add a live ebuild first for a month or two if you're still working on something (just like it's fine to add a masked package). However, it's not fine to leave things like this for years. That said, maybe the policy should cover 'long-term masked packages' in general. See below. Initially Arfrever suggested the same, I wasn't a fan of it because I believe it's much simpler to make this into a pkgcheck/repoman check like this. However with pkgcheck maybe a similar logic can be used as is used with StableRequestCheck. So no objections there I guess. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, 2020-11-03 at 07:13 +0200, Joonas Niilola wrote: > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. I'm with you on this though I think it should be relaxed to disallow only long term presence of pure live packages. It's fine to add a live ebuild first for a month or two if you're still working on something (just like it's fine to add a masked package). However, it's not fine to leave things like this for years. That said, maybe the policy should cover 'long-term masked packages' in general. See below. > Rationale being the same as why > - packages can't have KEYWORDS: They are unpredictable and > potentially insecure. Unpredictability could mean upstream repo being > broken at any given time placing users in an awkward situation, where > they are able to build some packages while not the others. Upstream > repo can also be force-pushed over. I feel like packages offered in > ::gentoo shouldn't have these issues, and the need to have at least one > safe release available to users that's guaranteed to build. I agree with this but I'd like to emphasize one point: these packages are not installable for users out of the box. They are not tested as part of tinderboxing. They simply can't be installed in some environments (e.g. network-restricted) though obviously they're not production-ready by design. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
Hey, I'm suggesting a new QA policy to disallow any "live-ebuild-only packages" being hosted in ::gentoo. Rationale being the same as why - packages can't have KEYWORDS: They are unpredictable and potentially insecure. Unpredictability could mean upstream repo being broken at any given time placing users in an awkward situation, where they are able to build some packages while not the others. Upstream repo can also be force-pushed over. I feel like packages offered in ::gentoo shouldn't have these issues, and the need to have at least one safe release available to users that's guaranteed to build. With Git-like VCS's becoming popular, it is super easy to create an unchanged snapshot based on a commit. Even devmanual encourages this with proper guide how-to: https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#snapshots-and-live-ebuilds (https://devmanual.gentoo.org/keywording/index.html) We currently have 43 "live-ebuild-only" packages in tree. Out of those 19 are totally unbuildable, that's 44 % of all packages present in the repo. Overall the maintenance of these live-ebuild-only packages looks low, there's only a handful of ebuilds that have good quality and no issues at all. 12 of them, 28 %, are still on EAPI-5. Of all 43, only 2 would require the maintainer to generate a tarball by themself, while others can utilize upstream's tagged releases, or ability to make a snapshot from a specific commit. Obviously if this policy passes, I'll be helping getting these packages keyworded. And finally here's an example how to introduce new packages to tree without upstream releases: https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/rlottie?id=42873c46b7ed07d5b4f8af5fcf08d8549cb6385b https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=2de52234783be909f6e4aed333533e6a804e8e6b https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=8305f0c6cd0ce8cb5ac0f2d92569acce36a5cc0a etc... https://gitweb.gentoo.org/repo/gentoo.git/commit/media-libs/rlottie?id=24c48b325dd5a22284d077d6581a1a45e397e511 If the only available version for a package doesn't build - or can't be guaranteed to build - then it should be last-rited, or not exist in ::gentoo repo at all. Some history and initiative: bug #713802 -- juippis
