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] Packages & projects up for grabs due to jer's retirement
For the record, > net-dns/libidn2 * added also toolchain (glibc dependency) > net-misc/chrony * added also base-system -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
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?
[gentoo-dev] LiveCD Project disbanding: packages up for grabs
The LiveCD project is only me now, which isn't much of a project, so I'm putting these packages up for grabs. livecd@ is co-maintainer on a few others that aren't listed. app-misc/livecd-tools - Releng@ will take this sys-libs/libkudzu sys-apps/hwdata-gentoo sys-apps/hwsetup - These are used on the Live CDs, but I don't know if they actually do anything useful. - Releng@ will take them with the understanding that I might remove them from the tree. dev-python/pyparted dev-util/dialog sys-block/parted sys-fs/squashfs-tools x11-themes/gentoo-artwork-livecd
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] Adding heptapod as new in metadata.dtd
15.10.2020, 21:15, "Michał Górny" :
> On Wed, 2020-10-14 at 02:19 +0300, Torokhov Sergey wrote:
>> Excuse me for text/html in initial letter. I duplicate start message with
>> text/plain below
>> without attachments as they are available on MARC:
>>
>> Hello!
>>
>> Due to recent sunset on mercurial support by Bitbucket [1]
>> the project early hosted there that uses mercurial vcs
>> have to migrate to other mercurial hosting.
>>
>> One of them is new hosting heptapod [2] based on the Gitlab.
>> For free and open source project the service provides free of charge
>> hosting [3].
>>
>> E.g. the following projects migrate to heptapod:
>>
>> Tortoisehg : https://foss.heptapod.net/mercurial/tortoisehg/thg
>> PyPy : https://foss.heptapod.net/pypy/pypy
>>
>> The attached patches offer to add 'heptapod' (i.e. 'foss.heptapod.net' [3])
>> as new item to 'dtd/metadata.dtd' and to
>> 'xml-schema/metadata.xsd'.
>>
>> Then it could be used to set in 'matadata.xml' an additional info about :
>>
>> for dev-python/pypy{,3}: pypy/pypy
>>
>> for dev-vcs/tortoisehg: > type="heptapod">mercurial/tortoisehg/thg
>>
>> [1] https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
>> [2] https://heptapod.net
>> [3] https://foss.heptapod.net
>>
>> --
>> Sergey Torokhov
>>
>> <<<
>
> Both pushed.
>
> --
> Best regards,
> Michał Górny
Hello again.
It seems that after merge of this patches there are still some issues remain:
1) Github gentoo/gentoo CI don't know about new remote-id "heptapod" and result
in error on QA check.
2) packages.gentoo.org source code is also required to be updated to use this
new remote-id.
Is it
https://gitweb.gentoo.org/sites/soko.git/tree/pkg/app/handler/packages/utils.go
file is required to be patched
in "func RemoteIdLink(remoteId models.RemoteId) string" ?
--
Sergey Torokhov
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On 2020-11-03 22:32, Michał Górny wrote: app-text/pinfo I'll take this one. net-misc/chrony I do use some of the fancy features of chrony so I would be interested in taking it, that said with both sam and chewi being interested to some degree I'll discuss this with them first. net-misc/youtube-dl Willing to co-maintain with mgorny and/or polynomial-c. x11-terms/rxvt-unicode Will co-maintain this one with conikost, don't mind being listed as primary maintainer. > net-libs/nodejs Would be willing to maintain it but only with a co-maintainer. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
