Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

If I’m set as maintainer for a package, what are the best ways to get informed when new versions come out (e.g. RSS, announcement mailinglists, nixos-monitor)? If the software in question is released on github using their release functionality, you can subscribe to an RSS feed in your reader of

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

On 16-09-03 07:24am, Shea Levy wrote: > Any other ideas that might be useful here? The nixpkgs-side is one dimension to what maintainers have to do, but what I’m stubling upon is the update-information-side. If I’m set as maintainer for a package, what are the best ways to get informed when new

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

laverne writes: > A "maintainer" that does not have commit access cannot maintain and > is thus not actually a maintainer. Due to the wonders of Github, it's entirely feasible to maintain packages without having commit access. A "maintainer" is not necessarily the person who commits patches

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Many meta.maintainers do not have commit access, that's the main bottleneck that causes hours/days/weeks/months delay. This should not be so. A "maintainer" that does not have commit access cannot maintain and is thus not actually a maintainer. I'm currently listed as maintainer (15 packages)

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

On Sat, 03 Sep 2016 08:35:45 -0500 stewart mackenzie wrote > Many meta.maintainers do not have commit access, that's the main > bottleneck that causes hours/days/weeks/months delay. This should not be so. A "maintainer" that does not have commit access cannot maintain and is thus

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Layus writes: > Could you elaborate more on how you plan to implement this ? > Who will be responsible to maintain maintainers ;-) ? > Do you plan to automate it somehow ? The first thing, straightforward to do, is add an option to not build unmaintained packages and add a

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

We could let the mention-bot ignore certain files "fileBlacklist": ["*.md"], // mention-bot will ignore any files that match these file globs On Sat, Sep 3, 2016 at 1:03 PM, Shea Levy wrote: > No, not something automated like that. Though mention-bot seems to work >

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

No, not something automated like that. Though mention-bot seems to work decently well, it doesn't know for example that changes to all-packages.nix are much less useful than changes to a default.nix file in a package directory. A human can know that, and additionally look at the log messages to

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

maintainers.nix contains email addresses and for many of us uses the same as our github handles. So users should be told to ping on github *and* email when they find an issue, and then if someone is unresponsive through that we can (if we're sticking with 3) remove them after some time. Hydra

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

On 09/03/2016 01:21 AM, Bardur Arantsson wrote: > On 2016-09-02 23:16, Shea Levy wrote: >> > Why can't people use the commit logs to see who is knowledgeable? > Are you thinking of something like https://github.com/facebook/mention-bot ? Note that we *do* use that bot in nixpkgs for quite some

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

On 2016-09-02 23:16, Shea Levy wrote: > Why can't people use the commit logs to see who is knowledgeable? Are you thinking of something like https://github.com/facebook/mention-bot ? This fails in the case where someone does a big cross-cutting (i.e. not concerned with particular packages)

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

I'm mostly worried about leaning that I need to fix a package that I'm maintaining. I care about fixing bugs and purging unmaintaned packages, but most of the time I don't even see the report, or I know it's broken in hydra until I test again locally. Do you have any ideas around getting word out

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Yes, using log info seems good enough for finding related users. I was thinking to hydra notifications, which are also linked to this maintainer field. But I guess that a maintainer not active on github will not want to receive hydra notifications, so both are related. Could you elaborate

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Why can't people use the commit logs to see who is knowledgeable? I believe we should have some way to denote "this person has committed to make reasonable efforts to keep this package working properly", and the maintainers field seems the right fit. But anyway, limiting 3 to release-small or

Re: [Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Hi Shea, I like this idea, except for the part where you forcefully remove maintainers. I have always seen maintainers as knowledgeable on the package, not bound to reply on issues about it. Just ensure that X is big enough :-). I really like this idea if we limit (3.) to release-small

[Nix-dev] Limiting access to only maintained packages and ensuring core packages are maintained

Hi all, I think a few changes might improve package stability a bit: 1. Add a nixpkgs config setting to throw an error on packages with no meta.maintainers 2. Work to reach a point where a significant subset of nixpkgs (say, release-small) is allowed on this list. 3. Remove maintainers