>A program that takes v1.deb and v2.deb can output the list of patches added
>and removed, as well as whether the meta-data for the package (scripts/* ?)
>was changed.
This means that we switch to debian releases as our upstream?
>For both of these packages it is fairly easy to generate a fully p
On Tue, Sep 2, 2014 at 11:33 AM, Michael Raskin <7c6f4...@mail.ru> wrote:
> >> 1 not sure if 0.8.0.3 is relevant on linux
> >> 1 patch OK
> >> 2 hard to say
> >> 2 not linked on homepage
> >> 3 build failure
> >> 11 patch ok
> >> 12 build pending
> >> 2
>> 1 not sure if 0.8.0.3 is relevant on linux
>> 1 patch OK
>> 2 hard to say
>> 2 not linked on homepage
>> 3 build failure
>> 11 patch ok
>> 12 build pending
>> 23 irrelevant
>> 29 no patch
>>
>>
>What does "no patch" mean? (a new release without a
On Tue, Sep 2, 2014 at 10:52 AM, Michael Raskin <7c6f4...@mail.ru> wrote:
> >With the awesome monitor.nixos.org system, we're prety close to 1)
> deriving
> >trivial patches (update version and sha256) automatically, 2) building
> >these trivial patches in a monitor.nixos.org-controlled branch, an
>With the awesome monitor.nixos.org system, we're prety close to 1) deriving
>trivial patches (update version and sha256) automatically, 2) building
>these trivial patches in a monitor.nixos.org-controlled branch, and 3)
>notifying maintainers that a successful build of a new version exists so
>the
With the awesome monitor.nixos.org system, we're prety close to 1) deriving
trivial patches (update version and sha256) automatically, 2) building
these trivial patches in a monitor.nixos.org-controlled branch, and 3)
notifying maintainers that a successful build of a new version exists so
they can
Many other package systems are decentralised (Gems/Composer/PyPI/NPM).
Why not make Nix packages decentralised? So that maintainers can
maintain their own packages and update them at any time? This would
speed up evolution of Nix packages.
One problem to solve is how do we make sure that unresp
Humm I think that I commit to 14.04 any update I need, not waiting for Eelco
approval. :) I talk about final program updates, not libraries that cause big
rebuilds.
I use to think that anything can be reverted, and then the revert has to be
justified. That helps as to learn what to commit and what
On 08/31/2014 03:43 PM, Chris Double wrote:
> Speed of processing pull requests for new packages is an issue.
> Anything that can be done to reduce this would be helpful. It's
> demotivating as a contributor to do what seems to be a simple package
> update of a minor version and have the pull reque
Would a script that checked all PRs if they contain a change to a file with
maintainers. help? You could then regulary run that script or run it
automatically to get notifications.
--
Benno
2014-08-31 17:07 GMT+02:00 Lluís Batlle i Rossell :
> nixpkgs is a repository that holds maintainers with
nixpkgs is a repository that holds maintainers with very different interests,
some very narrow, with the common factor of nix/nixos. I really don't want to
hear about updates to a very big percent of nixpkgs. :)
In nixpkgs, 'meta.maintainers' was a way to get maintainers called upon some
update
i
I have a problem with the pull requests... In github, if I'm not wrong, I can
either receive all PRs by mail or none. Hence I unsubscribed. Thankfully,
sometimes people do @viric on some packages.
I wish I could accept a merge by replying the request letter, instead of
clicking the web button.
Re
Speed of processing pull requests for new packages is an issue.
Anything that can be done to reduce this would be helpful. It's
demotivating as a contributor to do what seems to be a simple package
update of a minor version and have the pull request take weeks.
When I first started using NixOS the
On 2014-08-29 at 09:59, Mateusz Kowalczyk wrote:
> On 08/29/2014 10:04 AM, Vladimír Čunát wrote:
>> Also, the commitment of being maintainer of a group of packages seems
>> significantly larger than for a single package. The change may rather
>> dissuade people from becoming a maintainer at all
On 08/29/2014 03:26 PM, Paul Colomiets wrote:
> Well, I'm not the committer. But I think the problem with looking to
> PR, is that there are 110 unsorted PRs. It's hard to look them all in
> one go. And it's useless that all committers look at them all. If
> there would be 11 groups of 10 PRs, it's
>On Fri, Aug 29, 2014 at 3:59 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
>>
>> I would say that ZHF has some progress specifically because it is about
>> reasonable efforts to improve signal-to-noise.
>>
>> If we want packages to get updated, we need to merge pull requests
>> faster and not let p
On Fri, Aug 29, 2014 at 3:59 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
>
> I would say that ZHF has some progress specifically because it is about
> reasonable efforts to improve signal-to-noise.
>
> If we want packages to get updated, we need to merge pull requests
> faster and not let pull req
>Actually I think people are much more inclined to sit down and spend a
>few minutes sometimes updating a package or two from their group rather
>than putting their own name down specifically on a package and then
>having the sole burden of updating it themselves. I also think it makes
>people feel
On 08/29/2014 10:04 AM, Vladimír Čunát wrote:
> On 08/27/2014 04:35 PM, Mateusz Kowalczyk wrote:
>> What do you think? I think something like this is inevitable with the
>> ever-growing number of packages and users or we end up with the
>> situation like we have today, with thousands of outdated pa
On Fri, Aug 29, 2014 at 12:04 PM, Vladimír Čunát wrote:
> On 08/27/2014 04:35 PM, Mateusz Kowalczyk wrote:
>>
>> What do you think? I think something like this is inevitable with the
>> ever-growing number of packages and users or we end up with the
>> situation like we have today, with thousands
People may be likely to commit to being part of a group, where they can
assist as time allows, without necessarily commiting to being THE
maintainer for a particular package. So you could potentially end up with a
larger pool of people prepared to do maintenance with this model.
Alan
On Fri, Aug
On 08/27/2014 04:35 PM, Mateusz Kowalczyk wrote:
What do you think? I think something like this is inevitable with the
ever-growing number of packages and users or we end up with the
situation like we have today, with thousands of outdated packages
without maintainers or with inactive/busy mainta
Mateusz Kowalczyk writes:
> Hi,
>
> Some weeks ago the nixpkgs monitor[1] started to work again and the
> numbers there are worrying. I inline the numbers at the bottom.
>
> Now, there are 2000+ outdated packages with maintainers listed and 1000
> outdated without maintainers at all (and the 1600
Hi,
Some weeks ago the nixpkgs monitor[1] started to work again and the
numbers there are worrying. I inline the numbers at the bottom.
Now, there are 2000+ outdated packages with maintainers listed and 1000
outdated without maintainers at all (and the 1600 whose status we don't
know). Even if so
24 matches
Mail list logo
