What I take from this thread is not that we need to enforce ownership (I
think it is right to say that the people committing to nixpkgs are cautious
to only commit to their own stuff), but rather that we need to document
this ownership better. Just a file, like chromiums OWNERS files could help
ver
> I'm totally for that, but do note that there is an equivalent problem
> in deciding who gets "PR approval" access. But, I suppose since we
> control hydra/whatever and not github, we can roll our own logic like
> allowing people to only approve PRs for automatic merging that affect
> certain file
On 02/22/2016 10:35 AM, Adrien Devresse wrote:
> The way the other distributions solved this issue is by distributing the
> responsabilities. A model where a little minority has to approve /
> validate the merge each package modification can not scale to a huge
> number of packages.
IMHO the discu
On 02/23/2016 05:56 PM, Pascal Wittmann wrote:
> On 02/23/2016 12:10 AM, zimbatm wrote:
>> Somewhere we also have a tool that tracks CVEs against packages with a
>> heuristic but I don't remember where it is anymore.
>
> This is implemented in nixpkgs-monitor. It is outdated (inactive) for
> quite
On 23 Feb 2016 23:08, "Matthias Beyer" wrote:
>
> On 21-02-2016 15:28:08, Bjørn Forsman wrote:
> > On 21 February 2016 at 15:17, zimbatm wrote:
> > > tl,td; I think that we should split nixpkgs/pkgs in two
> >
> > Another way to do it is the Linux kernel way. Instead of splitting the
> > (git) re
I think the topic trees idea is great. This is also how openSUSE does
things, and they've managed to reproduce something like a Github workflow
for packages across a wide range of distros. I think their capitalization
on this model, and the generous provision of a build cluster for public
use, are
On 02/23/2016 12:10 AM, zimbatm wrote:
> Somewhere we also have a tool that tracks CVEs against packages with a
> heuristic but I don't remember where it is anymore.
This is implemented in nixpkgs-monitor. It is outdated (inactive) for
quite some time. I've opened an issue about this #12703.
si
And now this leads into my thread
https://www.mail-archive.com/nix-dev@lists.science.uu.nl/msg18287.html
:).
I'm totally for that, but do note that there is an equivalent problem
in deciding who gets "PR approval" access. But, I suppose since we
control hydra/whatever and not github, we can roll o
On 23-02-2016 16:08:37, Matthias Beyer wrote:
> On 21-02-2016 15:28:08, Bjørn Forsman wrote:
> > On 21 February 2016 at 15:17, zimbatm wrote:
> > > tl,td; I think that we should split nixpkgs/pkgs in two
> >
> > Another way to do it is the Linux kernel way. Instead of splitting the
> > (git) repo
On 21-02-2016 15:28:08, Bjørn Forsman wrote:
> On 21 February 2016 at 15:17, zimbatm wrote:
> > tl,td; I think that we should split nixpkgs/pkgs in two
>
> Another way to do it is the Linux kernel way. Instead of splitting the
> (git) repository in two (or more) pieces, split _maintenance
> respo
We have nixpkgs/pkgs/build-support/upstream-updater. I think it's a tool
that takes metadata from a package to find updates. But it's used by 8
packages tops and it's doc is in doc/old/update-upstream-data.txt.
Somewhere we also have a tool that tracks CVEs against packages with a
heuristic but I d
On Mon, Feb 22, 2016 at 9:54 AM, Mathnerd314
wrote:
> What happened to the rule of "Don't keep generated files in version
> control"?
>
Previous discussion:
http://comments.gmane.org/gmane.linux.distributions.nixos/18615
3 months and no progress...
-- Mathnerd314
___
I think the solution is to automate package updates as much as possible.
All the big tech companies can release updates at the push of a button;
release management is done by 1 person. The only way to keep up is to also
update all the packages in Nixpkgs with 1 button. There's been some work on
thi
Related to the discussion, apparently even Debian has trouble keeping-up
with security updates:
https://statuscode.ch/2016/02/distribution-packages-considered-insecure/ It's
not a simple problem for sure.
On Mon, 22 Feb 2016 at 09:35 Adrien Devresse wrote:
> I think the inflow of PRs *is* high
> I think the inflow of PRs *is* high wrt. the number of active
> contributors with push access. Certainly too much to keep quality very
> high all the time, but on the other hand, for those less important
> packages it's not a big deal...
The way the other distributions solved this issue is by di
On 02/21/2016 09:10 PM, Patrick Callahan wrote:
> Does anyone here know what other distros do to engage more
> developers+maintainers? Could we, among other things, organize some kind
> of drive to encourage more systematic contributions? Or is integrating
> all the current PRs too much work alread
Would you say that this is somewhat comparable to 'contrib' repos in
general? I would hope nixpkgs could still manage better quality control and
integration than Arch users have with AUR, which is kind of hacky.
Does anyone here know what other distros do to engage more
developers+maintainers? Cou
Thanks,
what I had in mind is a model similar to Arch Linux. I would like to make
some definitions first:
committer: person who has commit access to nixpkgs
maintainer: person who is listed in a given package's meta.maintainers
attribute
There is a core set of packages that all work together and
On 02/21/2016 03:17 PM, zimbatm wrote:
> tl,td; I think that we should split nixpkgs/pkgs in two
OK, let's discuss.
TL;DR: I quite don't get where to draw the line, and what the
relationship of the two sets would be.
> nixpkgs is getting pretty huge. There is so much surface, [...]
>
> We have a
On 21 February 2016 at 15:17, zimbatm wrote:
> Hi list,
>
> tl,td; I think that we should split nixpkgs/pkgs in two
Another way to do it is the Linux kernel way. Instead of splitting the
(git) repository in two (or more) pieces, split _maintenance
responsibility_ into a hierarchy. This is opposit
Hi list,
tl,td; I think that we should split nixpkgs/pkgs in two
nixpkgs is getting pretty huge. There is so much surface, I don't think
that a single person can keep up with the pace of change and still manage
to do other things in the same day. Luckily we do have ~5 super-human
people taking ca
21 matches
Mail list logo
