Re: [gentoo-dev] ebuild life cycle review
Hi, On 4/11/20 2:13 AM, Jonas Stein wrote: > AFAIK technically it can already scan overlays. > You can ask the euscan team. Anybody there who can help me to contact euscan team? > http://euscan.gentooexperimental.org/ The updated team contact is missing in this page. Is euscan still experimental? Are anybody using it with overlays? Thanks, Samuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
On Sat, 11 Apr 2020 21:41:58 +0100 Samuel Bernardo wrote: > loosing ebuilds (we > wants it!... we needs it must!... my precious) Ebuilds are never actually "lost". If you use gentoo's git repo for /usr/portage, you can always wind back the whole tree, or some subset thereof, to a state where the ebuild existed. It won't be well maintained, but that's the compromise one pays for. ( You don't even have to use git for /usr/portage if you don't want to, you can do what I do occasionally and have an otherwise empty overlay with symlinks to a copy of gentoo.git at the desired point ) pgp6yBauaZw01.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
Hi, Thank you very much for your experience and information sharing. I learnt very much with your answers. --- The goal of my suggestions was related to ebuilds that become unattended more than one year or being left behind even further. Anyway the right timescale depends on each project and so each team could define the right limit. This kind of policies would allow to take care of forgotten or neglected ebuilds in portage. But this policy implementation only deserves attention when updating new profile releases. The policy action could just place a portage warning with hard mask of those packages that will be removed in next profile release. Because I like very much the idea of not loosing ebuilds (we wants it!... we needs it must!... my precious), I suggested that in this case could be relevant to have another profile stage such as ceased or unattended. So with this kind of action would allow to reduce work, keeping the focus of maintenance where it is most needed. --- I have to leave a very big thanks to all dedication and time that all Gentoo developers, maintainers, teams, ... spent with this noble cause. Cheers On 2020-04-11 16:53, James Le Cuirot wrote: > On Fri, 10 Apr 2020 18:21:00 +0200 > Jonas Stein wrote: > >>> I would like to leave a suggestion for Gentoo portage ebuild review. >>> Since there are some ebuilds in portage that become outdated for more >>> than one year when there are new versions available, maybe could be >>> possible to add a new step in Gentoo QA service to generate an alarm >>> (send email to project and CI leaders) to request a human review. >> This service does already exist. Everybody can use repology [1], euscan >> [2] and others. >> >> Bumping a package needs time - especially for testing. I work a lot on >> our bug tracker and my impression is that automatic bugs for a bump >> request are contra productive. We already have many important, but easy >> to fix open bugs. >> Automatic tickets for packages will flood bugzilla with tickets for >> unused packages and bind additional manpower. > Totally agree. I have already used euscan, and nowadays repology, and > they're very useful for keeping on top of the stuff I directly > maintain. I can also use them for the wider games team but there's a > mountain of work to do there and that's not even counting the constant > flood of largely automated bug reports we already get every day. I just > do what I can. > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
On Fri, 10 Apr 2020 18:21:00 +0200 Jonas Stein wrote: > > I would like to leave a suggestion for Gentoo portage ebuild review. > > Since there are some ebuilds in portage that become outdated for more > > than one year when there are new versions available, maybe could be > > possible to add a new step in Gentoo QA service to generate an alarm > > (send email to project and CI leaders) to request a human review. > > This service does already exist. Everybody can use repology [1], euscan > [2] and others. > > Bumping a package needs time - especially for testing. I work a lot on > our bug tracker and my impression is that automatic bugs for a bump > request are contra productive. We already have many important, but easy > to fix open bugs. > Automatic tickets for packages will flood bugzilla with tickets for > unused packages and bind additional manpower. Totally agree. I have already used euscan, and nowadays repology, and they're very useful for keeping on top of the stuff I directly maintain. I can also use them for the wider games team but there's a mountain of work to do there and that's not even counting the constant flood of largely automated bug reports we already get every day. I just do what I can. -- James Le Cuirot (chewi) Gentoo Linux Developer pgp4N4f_TOjII.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
On Fri, 10 Apr 2020 12:31:19 +0100 Samuel Bernardo wrote: > - if there is more then X new versions in upstream, get from a release > feed associated with ebuild (X value defined by project leader with > threshold set by CI) This is probably the biggest difficult part really. There's lots of different services that provide this, but none of them are great for us, really. The majority of the ones I've looked at have a very hard time as soon as perl versions turn up. Even our own project, euscan, had serious problems with this. And evaluating this data in a notifiable way can be very expensive depending on how you do it, when contacting a service. ( Most services I've seen don't have a 'bulk' query interface, so you need a query-per-package... , and trying to get the service to work out 'what gentoo has' to work it out is even trickier ) I've been abusing release-monitoring for perl stuff, it was very time consuming to get everything we use tracked there, and I'm the only person who really adds new perl entries to it to track, so it only covers a fraction of gentoo. ( And again, it has the query-rate limitations, and the "perl versions are hard" problems as well ) pgpxsEjxTVsqt.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] ebuild life cycle review
Hi Samuel, > I would like to leave a suggestion for Gentoo portage ebuild review. > Since there are some ebuilds in portage that become outdated for more > than one year when there are new versions available, maybe could be > possible to add a new step in Gentoo QA service to generate an alarm > (send email to project and CI leaders) to request a human review. This service does already exist. Everybody can use repology [1], euscan [2] and others. Bumping a package needs time - especially for testing. I work a lot on our bug tracker and my impression is that automatic bugs for a bump request are contra productive. We already have many important, but easy to fix open bugs. Automatic tickets for packages will flood bugzilla with tickets for unused packages and bind additional manpower. We should reserve automatic tickets for important milestones. Such as EAPI 0 removal or the removal of an obsolete eclass. Version bumps will get easier and faster as automatic tests are improving. There is a big effort in the area of Python packages already. But there is still a lot to do for the next years. What consumes a lot manpower for version bumps? - Dependencies change upstream without documentation - Tests are missing - Tests are provided, but broken - Build systems are not used as intended and we have to fix downstream - The current workflow is still error prone and needs stronger integration of tools for standard tasks. (Package tests, last riting, removal, simple version bump, reassigning packages) repoman ci can not help with edits in profiles for example, it lacks of many QA tests. So you need finally additional test tools such as dev-util/pkgcheck. [1] https://repology.org/ [2] http://euscan.gentooexperimental.org -- Best, Jonas
Re: [gentoo-dev] ebuild life cycle review
Looking also to changes proposed in GLEP 72 maybe my previous suggestion would bring another profile status as unattended or ceased. This would allow the transition for those that need to use old or archived profile versions. On 2020-04-10 12:31, Samuel Bernardo wrote: > Hi everyone, > > I would like to leave a suggestion for Gentoo portage ebuild review. > > Since there are some ebuilds in portage that become outdated for more > than one year when there are new versions available, maybe could be > possible to add a new step in Gentoo QA service to generate an alarm > (send email to project and CI leaders) to request a human review. > > Two conditions could be verified: > > - if ebuild don't receive any review for more than a time period defined > by project leader (threshold set by CI) > > - if there is more then X new versions in upstream, get from a release > feed associated with ebuild (X value defined by project leader with > threshold set by CI) > > Best, > > Samuel > > signature.asc Description: OpenPGP digital signature
[gentoo-dev] ebuild life cycle review
Hi everyone, I would like to leave a suggestion for Gentoo portage ebuild review. Since there are some ebuilds in portage that become outdated for more than one year when there are new versions available, maybe could be possible to add a new step in Gentoo QA service to generate an alarm (send email to project and CI leaders) to request a human review. Two conditions could be verified: - if ebuild don't receive any review for more than a time period defined by project leader (threshold set by CI) - if there is more then X new versions in upstream, get from a release feed associated with ebuild (X value defined by project leader with threshold set by CI) Best, Samuel signature.asc Description: OpenPGP digital signature
