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
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
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
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)
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
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
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
>
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
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
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
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)
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
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
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
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
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
16 matches
Mail list logo