Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Completely agreeing with Sergei, with some additional suggestions: On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > On Sun, 29 Jul 2018 00:40:18 +0300 > Mikle Kolyada wrote: > > > Hello, > > > > The Gentoo QA team would like to introduce the following policy that > > would be applied to individuals breaking the state and quality of the > > main gentoo.git tree > > > > ( as we do not have this strictly documented yet): > > > > > > > > If recommended > > It's not called "recommended" but "enforced". I agree. If you put penalties on these, they become hard rules. I think that change should be discussed by the council perhaps? > > Gentoo workflow policies are not followed by an > > individual developer > > (e.g make major changes to the widely used eclasses without prior > > discussion on the mailing list or > > commit changes that lead to multiple CI checks failure) > > Here should go exhaustive list of links to the policies to be enforced. At least. And they should be clear and concise. No "common sense" or anything involved for exceptions and the like. In addition, new checks should be introduced to the community and possibly approved by council as to whether being enforced or not. Fabian > > > the standard QA > > procedure is: > > > > 1.) Two warnings granted by QA team, after two independent breakages > > 2.) Revoking the commit access for 14 days > > > > These violations will be evaluated individually by all QA team members. > > Warnings can be revoked, if during 6 months period a developer makes at > > least 20 non trivial changes not producing more breakages. > > > > > > -- > > Sergei > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Sent from my phone. Please excuse my brevity. On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > Completely agreeing with Sergei, with some additional suggestions: > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > On Sun, 29 Jul 2018 00:40:18 +0300 > > Mikle Kolyada wrote: > > > > > Hello, > > > > > > The Gentoo QA team would like to introduce the following policy that > > > would be applied to individuals breaking the state and quality of the > > > main gentoo.git tree > > > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > If recommended > > > > It's not called "recommended" but "enforced". > > I agree. If you put penalties on these, they become hard rules. I > think that change should be discussed by the council perhaps? > > > > Gentoo workflow policies are not followed by an > > > individual developer > > > (e.g make major changes to the widely used eclasses without prior > > > discussion on the mailing list or > > > commit changes that lead to multiple CI checks failure) > > > > Here should go exhaustive list of links to the policies to be enforced. > > At least. And they should be clear and concise. No "common sense" or > anything involved for exceptions and the like. In addition, new checks > should be introduced to the community and possibly approved by council > as to whether being enforced or not. > > Fabian > > > > > > the standard QA > > > procedure is: > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > 2.) Revoking the commit access for 14 days > > > > > > These violations will be evaluated individually by all QA team members. > > > Warnings can be revoked, if during 6 months period a developer makes at > > > least 20 non trivial changes not producing more breakages. > > > > > > > > > > -- > > > if you want to enforce rules, would be productive to also have extensive documentation on how to avoid to make such problems. Better would be to invest more time in something like the breckage checker script, similar at what mgorny is doing, than adding more ways to block developers contributions. thanks, Alice >
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote: > Sent from my phone. Please excuse my brevity. > > On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > > > Completely agreeing with Sergei, with some additional suggestions: > > > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > > On Sun, 29 Jul 2018 00:40:18 +0300 > > > Mikle Kolyada wrote: > > > > > > > Hello, > > > > > > > > The Gentoo QA team would like to introduce the following policy that > > > > would be applied to individuals breaking the state and quality of the > > > > main gentoo.git tree > > > > > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > > > > > If recommended > > > > > > It's not called "recommended" but "enforced". > > > > I agree. If you put penalties on these, they become hard rules. I > > think that change should be discussed by the council perhaps? +1. Also please provide some tool for developers to check for compliance to these rules, e.g. repoman full must perform all these checks. If developers have no way to verify correctness of the code, they can't be held responsible for accidental violation of the rules. > > > > the standard QA > > > > procedure is: > > > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > > 2.) Revoking the commit access for 14 days > > > > > > > > These violations will be evaluated individually by all QA team members. > > > > Warnings can be revoked, if during 6 months period a developer makes at > > > > least 20 non trivial changes not producing more breakages. Why 6 months period? Why time frame at all? 20 good commits sounds OK. If you want time frame, then you should set autoexpire of warning as well. What is the definition of non-trivial change? There will be commits which may be seen as trivial by one person (e.g. because it is one-liner) and as non-trivial by another (e.g. because such commit fixes serious bug). > if you want to enforce rules, would be productive to also have extensive > documentation on how to avoid to make such problems. > Better would be to invest more time in something like the breckage checker > script, similar at what mgorny is doing, than adding more ways to block > developers contributions. > > thanks, > Alice Best regards, Andrew Savchenko pgpmyxUP15S3S.pgp Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, Jul 29, 2018 at 4:17 AM, Andrew Savchenko wrote: > On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote: >> Sent from my phone. Please excuse my brevity. >> >> On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: >> >> > Completely agreeing with Sergei, with some additional suggestions: >> > >> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: >> > > On Sun, 29 Jul 2018 00:40:18 +0300 >> > > Mikle Kolyada wrote: >> > > >> > > > Hello, >> > > > >> > > > The Gentoo QA team would like to introduce the following policy that >> > > > would be applied to individuals breaking the state and quality of the >> > > > main gentoo.git tree >> > > > >> > > > ( as we do not have this strictly documented yet): >> > > > >> > > > >> > > > >> > > > If recommended >> > > >> > > It's not called "recommended" but "enforced". >> > >> > I agree. If you put penalties on these, they become hard rules. I >> > think that change should be discussed by the council perhaps? > > +1. Also please provide some tool for developers to check for > compliance to these rules, e.g. repoman full must perform all these > checks. > > If developers have no way to verify correctness of the code, they > can't be held responsible for accidental violation of the rules. > >> > > > the standard QA >> > > > procedure is: >> > > > >> > > > 1.) Two warnings granted by QA team, after two independent breakages >> > > > 2.) Revoking the commit access for 14 days >> > > > >> > > > These violations will be evaluated individually by all QA team members. >> > > > Warnings can be revoked, if during 6 months period a developer makes at >> > > > least 20 non trivial changes not producing more breakages. > > Why 6 months period? Why time frame at all? 20 good commits sounds > OK. If you want time frame, then you should set autoexpire of > warning as well. > Best regards, > Andrew Savchenko That reads to me as "warnings become permanent after six months if not remediated with 20 non-trivial good commits", not that they expire.
[gentoo-dev] Re: rfc: [QA] Ban policy introduction
On 29.07.2018 00:40, Mikle Kolyada wrote: > Hello, > > The Gentoo QA team would like to introduce the following policy that > would be applied to individuals breaking the state and quality of the > main gentoo.git tree > > ( as we do not have this strictly documented yet): > > > > If recommended Gentoo workflow policies are not followed by an > individual developer > (e.g make major changes to the widely used eclasses without prior > discussion on the mailing list or > commit changes that lead to multiple CI checks failure), the standard QA > procedure is: > > 1.) Two warnings granted by QA team, after two independent breakages > 2.) Revoking the commit access for 14 days > > These violations will be evaluated individually by all QA team members. > Warnings can be revoked, if during 6 months period a developer makes at > least 20 non trivial changes not producing more breakages. > > > > > > Meh, I sent this one a bit prematurely, sorry for the spam, we will work on it a bit more before it reaches an official point signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
W dniu pią, 27.07.2018 o godzinie 08∶06 -0700, użytkownik Brian Dolbec napisał: > On Fri, 27 Jul 2018 16:31:15 +0200 > Ulrich Mueller wrote: > > > > > > > > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote: > > > July 27, 2018 4:07 PM, "William Hubbs" > > > wrote: > > > > Section 5.5.2 describes the directory structure of /var/cache. > > > > These paths are all optional [1]. > > > > > > > > /var/cache/fonts > > > > /var/cache/man > > > > /var/cache/www > > > > /var/cache/ > > > > > > > > Gentoo isn't a package, so I don't think /var/cache/gentoo/* is > > > > appropriate. Here is my proposal: > > > > > > > > /usr/portage -> /var/db/repos/gentoo > > > > /usr/portage/distfiles -> /var/cache/portage/distfiles > > > > /usr/portage/packages -> /var/cache/portage/binpkgs > > > > > > > > I'm not 100% comfortable with /var/db, but I don't have any better > > > > suggestion either. > > > > > > > > [1] > > > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData > > > > > > > From the same source > > > "No other requirements are made on the data format of the cache > > > directories." > > > And as you have quoted it, everything under /var/cache is > > > optional. > > > So anything which doesn't conflict with another package seems fine > > > according to FHS. > > > > That's how I would read it, too. We could of course invent a package > > name (like "package-manager" for virtual/package-manager) but it seems > > cumbersome, and I don't see any benefit of it. > > > > There also is /var/cache/fonts, so the FHS itself lists an example of > > a directory that's not named after a specific package. > > > > Ulrich > > /var/db/repos/gentoo > /var/cache/distfiles > /var/cache/binpkgs > > Works for me, just please keep "portage" out of it, after all distfiles > are not restricted to portage use only, and neither are binpkgs. There > is alternate binpkg installers. Well, technically speaking this specific binary package format is Portage-specific. But I don't think we need to go into that kind of nuances. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
[Proxying a message from Anders Thomson ] Hi Ulrich, As non-devs aren't allowed to post to gentoo-dev, I was hoping that you would proxy this question/comment for me. While on the subject of changing defaults, could we consider changing the (default) location of the pkg db? Roughly everything in /usr (and /(s)bin) is managed by the package manager, and it would be handy if the db of installed bits is close to the bits themselves . Keeping it in /var/ makes /var opinionated on the current set of installed packages and thus another thing to backup etc of you want "just the os/system stuff, not the applications' databases". along the same vein, if you want /var to be on another storage device (NAS/SAN for large databases), you get the OS's pkg db with it. If for any reason a boot fails to get /var mounted, you're without the pkg db. Something along the lines of /usr/lib/pkg ? Best, /Anders On Fri, Jul 27, 2018 at 4:31 PM, Ulrich Mueller wrote: > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote: > July 27, 2018 4:07 PM, "William Hubbs" wrote: >> Section 5.5.2 describes the directory structure of /var/cache. >> These paths are all optional [1]. >> >> /var/cache/fonts >> /var/cache/man >> /var/cache/www >> /var/cache/ >> >> Gentoo isn't a package, so I don't think /var/cache/gentoo/* is >> appropriate. Here is my proposal: >> >> /usr/portage -> /var/db/repos/gentoo >> /usr/portage/distfiles -> /var/cache/portage/distfiles >> /usr/portage/packages -> /var/cache/portage/binpkgs >> >> I'm not 100% comfortable with /var/db, but I don't have any better >> suggestion either. >> >> [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData > From the same source > "No other requirements are made on the data format of the cache > directories." > And as you have quoted it, everything under /var/cache is optional. > So anything which doesn't conflict with another package seems fine > according to FHS. That's how I would read it, too. We could of course invent a package name (like "package-manager" for virtual/package-manager) but it seems cumbersome, and I don't see any benefit of it. There also is /var/cache/fonts, so the FHS itself lists an example of a directory that's not named after a specific package. Ulrich pgpvkqkV7URia.pgp Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:40 AM, Michał Górny wrote:
> Dnia 27 lipca 2018 10:32:17 CEST, Ulrich Mueller napisał(a):
>>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>>
Users must never need to modify files in /var/lib to configure a
package's operation, and _the_specific_file_hierarchy_ used to
store the data _must_not_be_ _exposed_ to regular users."
>>
>>> One small note, while it is never needed to modify, skel.ebuild
>>> would then be a file that is meant to be accessed by users in
>>> /var/lib if your proposal is realized.
>>
>>That's one of the reasons why the proposal prefers /var/db. The other
>>reason is existing usage in eselect-repository.
>>
>>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>>
>>> In my understanding, a cache is typically an open collection of
>>items.
>>> Some subset of them can be deleted without much negative consequence,
>>> and there may also be surplus items that are no longer necessary and
>>> will be expired at some later time in order to reclaim disk space.
>>
>>> Nothing of this is true for an ebuild repository, which is a closed
>>> collection of files: A single file cannot be discarded without
>>> invalidating the whole repository. Also there cannot be any stray
>>> files which would be expired later. Same as above, a single stray
>>file
>>> will invalidate all.
>>
>>> (A collection of binary packages may qualify as a cache though, by
>>> this definition.)
>>
>>So, considering all the feedback from mailing list and IRC:
>>
>> /usr/portage -> /var/db/repos/gentoo
>> /usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> /usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>>
>>Open question: Should we have the additional "gentoo" path component
>>for the ones in /var/cache? The tradeoff is between a path that is
>>easier to type, or slightly easier usage if someone wants to NFS mount
>>distfiles and binpkgs.
>
> Note that NFS is not exactly clear cut here since binpkgs are not portable to
> different hosts, so you can have multiple variants of it.
True, but trivially solvable by configuring like-hosts to share
packages. Skylake packages go here, Sandybridge packages go here, etc.
This is what I do.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>
>>> Users must never need to modify files in /var/lib to configure a
>>> package's operation, and _the_specific_file_hierarchy_ used to
>>> store the data _must_not_be_ _exposed_ to regular users."
>
>> One small note, while it is never needed to modify, skel.ebuild
>> would then be a file that is meant to be accessed by users in
>> /var/lib if your proposal is realized.
>
> That's one of the reasons why the proposal prefers /var/db. The other
> reason is existing usage in eselect-repository.
>
>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>
>> In my understanding, a cache is typically an open collection of items.
>> Some subset of them can be deleted without much negative consequence,
>> and there may also be surplus items that are no longer necessary and
>> will be expired at some later time in order to reclaim disk space.
>
>> Nothing of this is true for an ebuild repository, which is a closed
>> collection of files: A single file cannot be discarded without
>> invalidating the whole repository. Also there cannot be any stray
>> files which would be expired later. Same as above, a single stray file
>> will invalidate all.
>
>> (A collection of binary packages may qualify as a cache though, by
>> this definition.)
>
> So, considering all the feedback from mailing list and IRC:
>
>/usr/portage -> /var/db/repos/gentoo
>/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>
> Open question: Should we have the additional "gentoo" path component
> for the ones in /var/cache? The tradeoff is between a path that is
> easier to type, or slightly easier usage if someone wants to NFS mount
> distfiles and binpkgs.
That proposal has by vote of support. No strong preference on whether
to include gentoo/ or not. It's one NFS mount vs two so not a big deal
either way.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote:
>
> On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
> >
> > So, considering all the feedback from mailing list and IRC:
> >
> >/usr/portage -> /var/db/repos/gentoo
> >/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
> >/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
> >
> > Open question: Should we have the additional "gentoo" path component
> > for the ones in /var/cache? The tradeoff is between a path that is
> > easier to type, or slightly easier usage if someone wants to NFS mount
> > distfiles and binpkgs.
>
> That proposal has by vote of support. No strong preference on whether
> to include gentoo/ or not. It's one NFS mount vs two so not a big deal
> either way.
>
Why not stick the repos in /var/repos and not /var/db/repos? If we're
just making up paths, why not make up a shorter one? I don't think
any other linux distros use /var/db...
--
Rich
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On 29/07/18 21:01, Rich Freeman wrote: > > > Why not stick the repos in /var/repos and not /var/db/repos? If we're > just making up paths, why not make up a shorter one? I don't think > any other linux distros use /var/db... > *BSD I believe .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree
> On Fri, 27 Jul 2018, Brian Dolbec wrote:
> On Fri, 27 Jul 2018 16:31:15 +0200
> Ulrich Mueller wrote:
>> > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote:
>>
>> > From the same source
>> > "No other requirements are made on the data format of the cache
>> > directories."
>> > And as you have quoted it, everything under /var/cache is
>> > optional.
>>
>> > So anything which doesn't conflict with another package seems
>> > fine according to FHS.
>>
>> That's how I would read it, too. We could of course invent a
>> package name (like "package-manager" for virtual/package-manager)
>> but it seems cumbersome, and I don't see any benefit of it.
>>
>> There also is /var/cache/fonts, so the FHS itself lists an example
>> of a directory that's not named after a specific package.
> /var/db/repos/gentoo
> /var/cache/distfiles
> /var/cache/binpkgs
For the record, these three paths have been approved in today's
Council meeting.
> Works for me, just please keep "portage" out of it, after all
> distfiles are not restricted to portage use only, and neither are
> binpkgs. There is alternate binpkg installers.
By another Council vote, snapshot names should be changed from
portage-MMDD.tar.{bz2,xz} to gentoo-MMDD.tar.{bz2,xz}.
So, no "portage" any more. ;)
Ulrich
pgpabZ6TuTvWB.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Sun, Jul 29, 2018 at 1:01 PM, Rich Freeman wrote:
> On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote:
>>
>> On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> >
>> > So, considering all the feedback from mailing list and IRC:
>> >
>> >/usr/portage -> /var/db/repos/gentoo
>> >/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> >/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>> >
>> > Open question: Should we have the additional "gentoo" path component
>> > for the ones in /var/cache? The tradeoff is between a path that is
>> > easier to type, or slightly easier usage if someone wants to NFS mount
>> > distfiles and binpkgs.
>>
>> That proposal has by vote of support. No strong preference on whether
>> to include gentoo/ or not. It's one NFS mount vs two so not a big deal
>> either way.
>>
>
> Why not stick the repos in /var/repos and not /var/db/repos? If we're
> just making up paths, why not make up a shorter one? I don't think
> any other linux distros use /var/db...
That would be fine with me as well :)
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-07-29 23:59 UTC
3d84bb9c9cd x11-misc/winswitch20180725-22:50 zlogene cddcf9838ac x11-plugins/wmlaptop 20180724-22:52 zlogene 44f2894b6ee Additions: app-metrics/burrow_exporter 20180726-17:56 mrueg 9a307cfc150 dev-libs/libfstrcmp 20180725-14:04 candrews 2c222f7234d dev-python/kaitaistruct 20180605-14:45 chainsaw 2cff6b95aaa dev-python/python-consul 20180725-17:56 mrueg c986848dce2 dev-python/python-netlink 20180725-01:28 zmedico f8814383738 dev-python/tappy 20180724-10:26 mgorny 0c866a5083f dev-util/tup 20180728-00:09 andrey_utkin 87056724896 games-emulation/jrommanager 20180711-10:05 mgorny a94b03d7740 gnome-extra/gnome-shell-extension-gsconnect 20180724-16:06 pacho 4485d26059f media-plugins/kodi-peripheral-steamcontroller 20180723-17:37 candrews 19a303ca833 sys-apps/sensei-raw-ctl 20180729-09:41 thev00d00 c17ecff78b0 sys-fs/fatresize 20180727-17:22 jer c095a8110e5 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-plugins/gst-plugins-schroedinger,removed,leio,20180728-13:51,707b5731b0d net-misc/whatportis,removed,mgorny,20180728-13:02,aea591630ff app-misc/jira-cli,removed,mgorny,20180728-13:01,235ef6a607e games-arcade/xevil,removed,mgorny,20180728-12:14,fc9559077a1 dev-java/sun-jacc-api,removed,mgorny,20180728-12:14,7a95cab7a6e dev-java/servletapi,removed,mgorny,20180728-12:13,612ef9d514f dev-java/jdom-jaxen,removed,mgorny,20180728-12:12,fe8f1aa8e61 dev-libs/DirectFB,removed,mgorny,20180728-12:07,50a4c86ddd4 games-arcade/snake3d,removed,mgorny,20180728-12:05,30e541dda46 dev-python/django-two-factor-auth,removed,mgorny,20180728-12:04,cd2c0c5a89d sci-physics/hoomd-blue,removed,mgorny,20180728-12:03,87a357c9870 media-sound/gnac,removed,mgorny,20180728-12:03,d502a07b9ae games-simulation/dangerdeep,removed,mgorny,20180728-12:02,abf18fe077c media-gfx/postr,removed,mgorny,20180728-12:01,0cabbb0a90a games-strategy/gorky17-demo,removed,mgorny,20180728-12:01,b111ae4b626 app-misc/wyrd,removed,mgorny,20180728-11:57,df9d497e52a app-doc/mkdoxy,removed,mgorny,20180728-11:56,862948f6e19 net-libs/libwhisker,removed,mgorny,20180728-11:56,b7b9c071e5f sys-boot/getdvhoff,removed,mgorny,20180728-11:55,3452d636e3b games-arcade/marbleblastgold-demo,removed,mgorny,20180728-11:55,51c695a2f91 games-arcade/marbleblast-demo,removed,mgorny,20180728-11:54,f07aeb25cc1 games-arcade/skystreets,removed,mgorny,20180728-11:54,a09208f09ea games-emulation/gfceux,removed,mgorny,20180728-11:52,1d34e586d70 games-emulation/hugo,removed,mgorny,20180728-11:51,1934c92d159 games-emulation/kigb,removed,mgorny,20180728-11:51,ff27fc46b73 games-emulation/raine,removed,mgorny,20180728-11:50,c406c020a2b games-fps/aaquake2,removed,mgorny,20180728-11:50,77dfd2da408 games-fps/doomsday-resources,removed,mgorny,20180728-11:49,bd6a6b19610 games-fps/duke3d,removed,mgorny,20180728-11:48,1d08d5fec85 games-fps/lsdldoom,removed,mgorny,20180728-11:46,75a1bc93301 games-fps/soldieroffortune-demo,removed,mgorny,20180728-11:45,089380dae1b games-puzzle/ensemblist,removed,mgorny,20180728-11:45,136425af8df games-puzzle/hoh-bin,removed,mgorny,20180728-11:44,1ed8caecbd7 games-strategy/heroes3-demo,removed,mgorny,20180728-11:42,d257e92ba64 games-sports/miniracer,removed,mgorny,20180728-11:41,8c8204c585a app-crypt/openpgp-keys-gentoo-mirror,removed,mgorny,20180728-11:39,578d7b15842 app-i18n/ibus-tutcode,removed,mgorny,20180728-11:39,ae8130e2e42 sys-fs/aufs4,removed,mgorny,20180728-11:37,33e9b1ddbff sys-fs/aufs3,removed,mgorny,20180728-11:37,a95a109ee37 dev-python/pyxml,removed,zlogene,20180725-23:19,8b6ccd70a89 app-text/rhyme,removed,zlogene,20180725-23:14,06794555a43 dev-python/pyrtf,removed,zlogene,20180725-23:10,f4cb5da2bd2 dev-java/easyneurons,removed,zlogene,20180725-23:02,5b4fc0adce8 net-misc/openvpn-auth-ldap,removed,zlogene,20180725-22:58,6ba685b8d0b x11-misc/winswitch,removed,zlogene,20180725-22:50,cddcf9838ac games-emulation/advancemenu,removed,zlogene,20180724-23:12,2cd73c7da92 app-text/gentoo-guide-xml-dtd,removed,zlogene,20180724-23:07,21e07e157fb dev-python/eliot,removed,zlogene,20180724-22:59,cecdd7aa897 x11-libs/libiterm-mbt,removed,zlogene,20180724-22:55,3d84bb9c9cd x11-plugins/wmlaptop,removed,zlogene,20180724-22:52,44f2894b6ee games-fps/postal2mp-demo,removed,zlogene,20180724-22:48,81550bf8371 net-irc/ircservices,removed,zlogene,20180724-22:39,4b137236165 www-apps/phprojekt,removed,grknight,20180723-14:08,8811e877bda www-apps/polarblog,removed,grknight,20180723-14:05,f87a95a87a2 www-apps/phpmp,removed,grknight,20180723-14:03,3324eee670b www-apps/mypictures,removed,grknight,20180723-13
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, Jul 29, 2018 at 12:40:18AM +0300, Mikle Kolyada wrote: > (e.g make major changes to the widely used eclasses without prior > discussion on the mailing list or What's the metric to say if a given eclass is widely used? -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Hello, I like the idea of enforcing quality rules in the tree, but I have a few reservations regarding the current plan. On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote: > Sent from my phone. Please excuse my brevity. > > On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > > > Completely agreeing with Sergei, with some additional suggestions: > > > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > > On Sun, 29 Jul 2018 00:40:18 +0300 > > > Mikle Kolyada wrote: > > > > > > > Hello, > > > > > > > > The Gentoo QA team would like to introduce the following policy that > > > > would be applied to individuals breaking the state and quality of the > > > > main gentoo.git tree If you introduce penalties for breaking prefix as well, I'm afraid many people will be unnecessarily penalized. I think that such penalties are counter productive in most cases. If someone is really being careless it might make sense to get some warning and lose commit access temporarily. If someone made a simple mistake that can be easily fixed, like version bumping a package that starts to fail in some corner case, then punishment doesn't make much sense. I'd rather prefer to see improvements to our automated checks as the mean to improve the quality of the tree, and penalties for people that do not use repoman. Rather than a temporary ban, it would also make more sense to just require someone to go through the ebuild quiz again as penalty for breaking the tree many times. > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > > > > > If recommended > > > > > > It's not called "recommended" but "enforced". > > > > I agree. If you put penalties on these, they become hard rules. I > > think that change should be discussed by the council perhaps? > > > > > > Gentoo workflow policies are not followed by an > > > > individual developer > > > > (e.g make major changes to the widely used eclasses without prior > > > > discussion on the mailing list or > > > > commit changes that lead to multiple CI checks failure) > > > > > > Here should go exhaustive list of links to the policies to be enforced. > > > > At least. And they should be clear and concise. No "common sense" or > > anything involved for exceptions and the like. In addition, new checks > > should be introduced to the community and possibly approved by council > > as to whether being enforced or not. > > > > Fabian > > > > > > > > > the standard QA > > > > procedure is: > > > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > > 2.) Revoking the commit access for 14 days > > > > > > > > These violations will be evaluated individually by all QA team members. > > > > Warnings can be revoked, if during 6 months period a developer makes at > > > > least 20 non trivial changes not producing more breakages. > > > > > > > > > > > > > > -- > > > > > > if you want to enforce rules, would be productive to also have extensive > documentation on how to avoid to make such problems. > Better would be to invest more time in something like the breckage checker > script, similar at what mgorny is doing, than adding more ways to block > developers contributions. I agree with Alice here. We already have the devmanual and repoman, as well as the CI system, which are all very good. Extending them is the best way to keep Gentoo in good shape. Also, if we have enough resources, we can try to reject broken pushes, rather than punishing devs after broken changes reach the main tree. Cheers, -Guilherme
