Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
On Thu, 16 Jun 2016 00:01:52 +0200
"Andreas K. Huettel" wrote:
> > Right now we have the following components:
> >
> > - Applications,
> merge with unspecified
Merging is impossible.
> > - Core system,
> autoassign to base-system?
Will base-system handle systemd bugs? I doubt it. It reminds me of
auto-assignment to games which resulted in many bugs hitting /dev/null.
> > - Development,
> makes no sense, merge with unspecified
>
> > - Eclasses and Profiles,
> split into eclasses and profiles
Splitting is impossible. I can create two new components, if you
insist, and disable the old one.
> > - Games,
> merge with applications
>
> > - Java,
> auto-assign to java
Why is Java special? Just because nobody uses it?
> > - Library,
> merge with unspecified
>
> > - Printing,
> either autoassign to printing or merge with unspecified
>
> > - Server,
> does anyone actually use this?
Yes. Reasons unclear.
> > - All packages,
> > - Core system [includes baselayout],
> > - Eclasses and Profiles,
> > - GCC Porting,
> > - Hardened,
> > - Keywording & Stabilization,
> > - New packages ('New ebuilds' previously),
> > - SELinux.
> >
>
> This is pretty close to the result of above reassignment, however,...
>
> > Keeping the big pseudo-category split doesn't make much sense as most
> > of the packages can't be fit easily into a specific group and it only
> > confuses users. GNOME & KDE aren't very clear either, especially for
> > non-core packages (like: is systemd a GNOME package?). Having them
> > skip bug-wranglers doesn't sound really helpful.
>
> Keeping the big desktop environments would be nice; anything that is a large,
> logical group of packages maintained by one team.
>
> Like, auto-assigning kde to kde and gnome to gnome.
>
> Of course upstream doesn't really help with their destructive tendencies.
> ("There is no KDE5, only Frameworks, Plasma and Applications.")
But there are non-core KDE apps that are not maintained by KDE team,
and GNOME apps that are not maintained by GNOME team. Users usually
don't check maintainers before choosing a component...
--
Best regards,
Michał Górny
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
On 06/15/2016 12:11 PM, Michał Górny wrote:
> Hello, everyone.
>
> On bug #577398, Pacho has requested removing the 'Development'
> component that's rarely used according to its description. However, I'd
> rather not remove a single component when it fits the component split
> currently used there.
>
> Right now we have the following components:
>
> - Applications,
> - baselayout,
> - Core system,
> - Development,
> - Eclasses and Profiles,
> - Games,
> - GCC Porting,
> - GNOME,
> - Hardened,
> - Java,
> - KDE,
> - Keywording & Stabilization,
> - Library,
> - New packages ('New ebuilds' previously),
> - Printing,
> - SELinux,
> - Server,
> - Unspecified.
>
> This basically is a mix of two component types: functional (like
> keywording, new packages...) and ebuild category (app, baselayout, core
> system...).
>
> Out of those components, GNOME, Hardened, Java, KDE and SELinux don't
> go through bug-wranglers. All other components don't have a specific
> default assignee.
>
> Of course, users are pretty much confused about which component to use,
> except for simple cases. The more experienced ones know that it doesn't
> matter most of the time, and choose a random one.
>
> Applications have around 100k bugs, new packages 128k (mostly wrong
> filled because of the old 'ebuilds' name), other components are less
> than 20k.
>
>
> I would personally go for the following layout:
>
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.
>
> The goals would be:
>
> a. have something that would fit most bugs going through bug-wranglers
> on the top,
>
> b. leave the functional split for 'eclasses and profiles' and 'new
> packages',
>
> c. leave the special team components such as 'gcc porting', 'hardened'...
>
> Keeping the big pseudo-category split doesn't make much sense as most
> of the packages can't be fit easily into a specific group and it only
> confuses users. GNOME & KDE aren't very clear either, especially for
> non-core packages (like: is systemd a GNOME package?). Having them
> skip bug-wranglers doesn't sound really helpful.
>
>
> Your thoughts?
>
>
> [1]:https://bugs.gentoo.org/show_bug.cgi?id=577398
>
A smaller set of categories goes a long way to helping people figure out
how they should be filed, and ensures the right people look at them.
Anything to make that process smoother for both devs and users sounds
good to me. Even as a developer I feel there's too much divide among
things and it can be hard to decide where a bug goes.
Ultimately it's up to the people who have to deal with the most bugs,
though.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
> Right now we have the following components:
>
> - Applications,
merge with unspecified
> - Core system,
autoassign to base-system?
> - Development,
makes no sense, merge with unspecified
> - Eclasses and Profiles,
split into eclasses and profiles
> - Games,
merge with applications
> - Java,
auto-assign to java
> - Library,
merge with unspecified
> - Printing,
either autoassign to printing or merge with unspecified
> - Server,
does anyone actually use this?
>
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.
>
This is pretty close to the result of above reassignment, however,...
> Keeping the big pseudo-category split doesn't make much sense as most
> of the packages can't be fit easily into a specific group and it only
> confuses users. GNOME & KDE aren't very clear either, especially for
> non-core packages (like: is systemd a GNOME package?). Having them
> skip bug-wranglers doesn't sound really helpful.
Keeping the big desktop environments would be nice; anything that is a large,
logical group of packages maintained by one team.
Like, auto-assigning kde to kde and gnome to gnome.
Of course upstream doesn't really help with their destructive tendencies.
("There is no KDE5, only Frameworks, Plasma and Applications.")
--
Andreas K. Huettel
Gentoo Linux developer
dilfri...@gentoo.org
http://www.akhuettel.de/
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
On Wed, Jun 15, 2016 at 3:57 PM, Davide Pesavento wrote: > We could also have separate components for "keywording" vs > "stabilization", which would make the use of STABLEREQ/KEYWORDREQ > keywords obsolete at the same time. The STABLEREQ keyword would still be useful for security bugs, where the Component/Product are generally set to Gentoo Security / Vulnerabilities.
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
On Wed, 15 Jun 2016 21:57:04 +0200
Davide Pesavento wrote:
> On Wed, Jun 15, 2016 at 9:11 PM, Michał Górny wrote:
> > I would personally go for the following layout:
> >
> > - All packages,
> > - Core system [includes baselayout],
> > - Eclasses and Profiles,
> > - GCC Porting,
> > - Hardened,
> > - Keywording & Stabilization,
> > - New packages ('New ebuilds' previously),
> > - SELinux.
> >
> [...]
> >
> > Your thoughts?
> >
>
> I'd split "eclasses" from "profiles", as they're not normally related
> to each other.
>
> We could also have separate components for "keywording" vs
> "stabilization", which would make the use of STABLEREQ/KEYWORDREQ
> keywords obsolete at the same time.
Note that there's no sane way to move/split bugs, so we'd either have
to leave the old (disabled) components and add two new ones, or leave
all current bugs in one of them and create the other one empty.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
On Wed, Jun 15, 2016 at 9:11 PM, Michał Górny wrote:
> I would personally go for the following layout:
>
> - All packages,
> - Core system [includes baselayout],
> - Eclasses and Profiles,
> - GCC Porting,
> - Hardened,
> - Keywording & Stabilization,
> - New packages ('New ebuilds' previously),
> - SELinux.
>
[...]
>
> Your thoughts?
>
I'd split "eclasses" from "profiles", as they're not normally related
to each other.
We could also have separate components for "keywording" vs
"stabilization", which would make the use of STABLEREQ/KEYWORDREQ
keywords obsolete at the same time.
Thanks,
Davide
[gentoo-dev] [RFC] 'Gentoo Linux' bugzilla component reorganization
Hello, everyone.
On bug #577398, Pacho has requested removing the 'Development'
component that's rarely used according to its description. However, I'd
rather not remove a single component when it fits the component split
currently used there.
Right now we have the following components:
- Applications,
- baselayout,
- Core system,
- Development,
- Eclasses and Profiles,
- Games,
- GCC Porting,
- GNOME,
- Hardened,
- Java,
- KDE,
- Keywording & Stabilization,
- Library,
- New packages ('New ebuilds' previously),
- Printing,
- SELinux,
- Server,
- Unspecified.
This basically is a mix of two component types: functional (like
keywording, new packages...) and ebuild category (app, baselayout, core
system...).
Out of those components, GNOME, Hardened, Java, KDE and SELinux don't
go through bug-wranglers. All other components don't have a specific
default assignee.
Of course, users are pretty much confused about which component to use,
except for simple cases. The more experienced ones know that it doesn't
matter most of the time, and choose a random one.
Applications have around 100k bugs, new packages 128k (mostly wrong
filled because of the old 'ebuilds' name), other components are less
than 20k.
I would personally go for the following layout:
- All packages,
- Core system [includes baselayout],
- Eclasses and Profiles,
- GCC Porting,
- Hardened,
- Keywording & Stabilization,
- New packages ('New ebuilds' previously),
- SELinux.
The goals would be:
a. have something that would fit most bugs going through bug-wranglers
on the top,
b. leave the functional split for 'eclasses and profiles' and 'new
packages',
c. leave the special team components such as 'gcc porting', 'hardened'...
Keeping the big pseudo-category split doesn't make much sense as most
of the packages can't be fit easily into a specific group and it only
confuses users. GNOME & KDE aren't very clear either, especially for
non-core packages (like: is systemd a GNOME package?). Having them
skip bug-wranglers doesn't sound really helpful.
Your thoughts?
[1]:https://bugs.gentoo.org/show_bug.cgi?id=577398
--
Best regards,
Michał Górny
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
Dnia 15 czerwca 2016 08:42:26 CEST, Andrew Savchenko napisał(a): >On Wed, 15 Jun 2016 05:15:03 +0200 Michał Górny wrote: >> On Wed, 15 Jun 2016 00:12:40 +0200 >> "Andreas K. Huettel" wrote: >> >> > Am Dienstag, 14. Juni 2016, 02:32:41 schrieb Peter Stuge: >> > >> > > >> > > I would personally be super happy to have my overlay hosted at >Gentoo - >> > > >> > >> > So what precisely is keeping you from that? >> > >> > https://wiki.gentoo.org/wiki/Project:Overlays/Overlays_guide >> >> Don't encourage people to create more work for me when we have >GitHub! > >Github is propietary and I don't see why someone have a right to >enforce its usage on people. > >If someone want to use github — go ahead, but if not — in no way >you can force people to do that (e.g. by refusing to create on >overlay, or review patch on bugzilla, or whatever). Congratulations, you just volunteered to join overlays and do the work! > >Best regards, >Andrew Savchenko -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] [RFC] New eclass: mate
Dnia 15 czerwca 2016 06:18:31 CEST, Jason Zaman
napisał(a):
>On Fri, Jun 10, 2016 at 12:52:34PM -0400, NP-Hardass wrote:
>> On 06/09/2016 11:54 PM, Jason Zaman wrote:
>> > On Thu, Jun 09, 2016 at 08:19:43AM -0400, NP-Hardass wrote:
>> >> # @FUNCTION: python_cond_func_wrap
>> >> # @DESCRIPTION: Wraps a function for conditional python use, to
>run for each
>> >> # python implementation in the build directory.
>> >> python_cond_func_wrap() {
>> >> if use python; then
>> >> python_foreach_impl run_in_build_dir "$@"
>> >> else
>> >> $@
>> >> fi
>> >> }
>> >
>> > I dont see where you inherited the python eclasses? You also
>probably
>> > need to use use_if_iuse (from eutils.eclass) instead since it seems
>like
>> > python might not be in all the ebuilds. Afaik, you're not allowed
>to
>> > call use foo if foo is not in IUSE already
>> I forgot to include a comment in the ebuild, but the intention was
>that
>> the eclass would not inherit python, by design, those wanting to use
>> that should inherit python themselves. Although, if I should check
>that
>> explicitly, I am unaware of how to do so, and would appreciate advice
>> from someone, if it is possible. I am aware of INHERITED, but the PMS
>> says it shouldn't be exported to ebuilds, so I'm unsure if/how it
>could
>> be used.
>>
>> My hope was that since this is used several times (though, not too
>> many), that I could move this logic into the eclass, but if it would
>be
>> more appropriate to just keep that in each of those ebuilds, I can do
>> that too.
>
>Yeah sounds like keeping this in the eclass is right. Moving duplicated
>code into the ebuilds would be a waste. You are defining the API so
>requiring the ebuild to inherit itself is completely okay. I would add
>a
>little more to the doc above to make it super obvious tho.
>
>I don't know how to check if the python eclasses specifically are
>inherited. I think "python" being in IUSE would be sufficient to check
>tho. so all you'd need to do is inherit eutils and replace the "if use
>python" with "if use_if_iuse python".
>
>If you *really* wanted to check you could perhaps do
>if [[ $(type python_foreach_impl) == function ]]. Seems overkill and I
>wouldn't bother. Having python in iuse is probably enough of a sanity
>check.
You can check for the include guards. This is how python-r1 eclasses detect one
another (in order to prevent inheriting multiple of them).
However, note that all fancy checks are allowed in phase scope only, and not in
global scope.
>
>-- Jason
--
Best regards,
Michał Górny (by phone)
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 You've got most things right, Rich. But a couple of comments follow. On 15/06/16 02:25, Rich Freeman wrote: > 1. Developers wouldn't have access to all the ebuilds in the > curated repositories. They would only have access to the ones they > contribute to. I'm not sure I completely agree with that as a hard rule. E.g. I think that having an inter-repository QA team would be valuable. > 2. Exherbo at least requires peer review for all commits I > believe. So, even if you're committing to your "own" overlay you're > still going to need review if your overlay is a curated one. Once again you are misrepresenting Exherbo. But since this thread is about Gentoo, I will limit my reply to Gentoo. We should not enforce anything on a user's repository like this. Instead, I suggest we maintain a fork of their repository in which we perform review. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXYQW7AAoJENQqWdRUGk8BGv4P/ieFcyRD1Be2Qqoj3/l90Vt0 3ga1EYzU1UI8nIkXXAYHChG+POMVadN73dkq/K7M/VGZbW5wAJZcCXfzC08T3rPa 5PROH8UmBnp5Y30tZiNrhI3cNyqUgV/V6E16WHAInPyQ1lOZp2csw9PZV7lu27PE vHpjb0wmEugJNNMQrJclbMQa11PW+elI7/cgHvRCdFq3ptuaCJ6yyAkWJ+ouB4C0 8WpVelra2l+b0YwBYYXQ4A9qlkIFfa6Ptvkirk/J9Nrjjnj++8Exa1D9sayUmuQr Iw8eTRYVUi0i1PQtTHBr6oEXMKjSdy1y1pb22O4ypflhcrj0IyhWZnIvdwDZkLzm 6abobiN79kzTgD8J45T2afcGKbtUIITldhgbS3GuxC6E1XjE6ByVswmh7MXT2cJa l4lddH77KTdb+m0dbL6PuojTdyVKmlEyRJRr+iAEN7Fo3CSa7BE1ButdOssoNj6X NIJLsHpGUVkGqSnar3f0lIe0hQqMdIEOSLqCkAkO6+OjA2nIbcgNAZXRHhJcGoB5 K1Nna/nCZm+GcQtlsKYvK+XyDHiLQn5QO0F6MMo5DUbxjcDR+0neKxrm12oShDFG iGZDzcryAy7eZrycMR8o3RqEUf7vGk3Ve3eFgSMiGqQfaIp0Oogc4Meolk6ALKpG YZ2JhKLp5efThPSaim85 =dWzl -END PGP SIGNATURE-
Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 14/06/16 08:48, Daniel Campbell wrote: > What sort of modularization are you talking about? The cheap answer is "as much as possible. > Would we suggest something like GNOME, KDE, XFCE, Mate, Cinnamon, > et al getting their own overlays? dev-lang/foo getting its own > overlay, etc? Yes. Although I would not want to impose my thoughts too much in this regard, as I think we have a lot of capable devs, who are hopefully more fit for this task than I am. > To some degree, that will simplify some people's trees and quicken > emerge, but then it just pushes maintainance to a part that most > users don't really mess with much (repos.conf) I don't know what maintenance you are speaking about. > You can achieve mostly the same end via your own git repo at > /usr/local/ and pulling overlays in via either layman or git > submodules, for overlays that aren't already in layman. The repository isn't hosted by us along with everybody else's repository, so there is no community element. And the Gentoo tree isn't modular today. So I completely fail to see how that would be "mostly the same". > zugaina and layman are great tools that could use a bit more > polish, and could be either adopted or assisted as an official part > of the handbook. That would be great. > There's no guarantee on their quality, and if an overlay becomes > popular then there may be pressure put on the Gentoo tree to adopt > whatever the popular overlay has. This could be detrimental *or* > beneficial, depending on what the changes are. I assume that using PPAs is at your own risk, so this is not a real problem. Gentoo would have a curated and reviewed set of repositories, venturing outside of that is clearly for power users. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXYQIaAAoJENQqWdRUGk8BVQQP/RmlYUCY46hslpRXC2A8W+pk OUCF4hL16pwMqfTIMOhxGvjSJ8sGSWSrHrh27YlvW5b0T1xxmH8fL5q/b9AxnnlZ g0cvbprunskuc0UK1b8H2vE0WFPXoTV5QmyKb3XZoXyW6BEPNYyal/uKAH8IxuQO 9y+bJa1TuAsaOEvIhDLDN8DCavwP+Wd306JrRm3dj708gDxr//i8aGg0WLEhKtof 1RAmqw/K12J2C/9rF/8isoE2UO8DEf/s19A4ghtrQj1zho4ZY4wUBZ/MNwHhboU8 TXPRXYVSI4n4N40hpdzVm6Mi+URiggLtYwwS8tZlaky1/1cLz7aG7INo1ECSaSOS rqllFkhgOWH+Tmxkt3OaODrAV263So7RbDlpMmjl4GJxj6dpygM5yEhAoM8ARWxg 0KE1m1XkRqZeDolJ3fKjFhVOzqMSHvbJT58PzD35AbiDXc/95kdcM+dCS/BGPqSs wSVTm7QIjsY7v5Pz6G/5kCKPi14xsTDZktSz4p/gOU53/+Tio6P+vN5ZCyFwfa43 9dkVv7QnpCJQLy8jlc07nvBB5xtEcPFe7yab/2qZdcc1LPQfRdUU8KUMzMTygNyb 1kW0aTQtKbnu2Af/JfjjVlVMN5WNBRiNVYhT430HVDRuoyShzoO6CDR+6V/AX8ze gT+8VKGb+5gU4iUyS4sz =wgyc -END PGP SIGNATURE-
