And when to remove unmaintained lines? After yet another year or so?
unmaintained "git-hash" "package-name" "2014-jan"
^^ so that you know when to remove that
line?
^ you may want to catch the install by name case
^^ yo
On 01/29/2014 11:28 PM, Jan Malakhovski wrote:
That's clever. And not too much pain. I could handle that in case my
package got removed.
I recommend using git "log -G regexp" to search the whole history if you
fail to find something. Currently it's just a matter of several seconds
on our repo
On Wed, 29 Jan 2014 11:44:40 -0800
James Cook wrote:
> How about deleting the expression but leaving a note about where to
> find it? For example, in all-packages.nix:
>
> my_package = unmaintained "0123abcd";
>
> and then
>
> $ nix-env -i my-package
> my-package was deleted because it
On 29 January 2014 04:32, Petr Rockai wrote:
> Jan Malakhovski writes:
>> * First, this "remove unmaintained" policy discourages adding new
>> packages to the public nixpkgs by users that are unable to maintain
>> stuff. In the example above, I would better store the package in my
>> own branch t
>Michael Raskin <7c6f4...@mail.ru> writes:
>> Somehow, whenever updates of packages I care about were broken, it was
>> a simple mistake that was easy to fix separately… I think this scenario
>> is overly pessimistic.
>
>Well, depends on your point of view. If you only care about a few
>packages
Michael Raskin <7c6f4...@mail.ru> writes:
> Somehow, whenever updates of packages I care about were broken, it was
> a simple mistake that was easy to fix separately… I think this scenario
> is overly pessimistic.
Well, depends on your point of view. If you only care about a few
packages for you
>It is a trade-off. Broken packages can be more overhead than duplication
>of work. If you make a package that works for you, push it to nixpkgs
>and abandon it, the next person will find it broken for his purpose, fix
>it and in the process break it for you. You will both spend time
>debugging the
Jan Malakhovski writes:
> * First, this "remove unmaintained" policy discourages adding new
> packages to the public nixpkgs by users that are unable to maintain
> stuff. In the example above, I would better store the package in my
> own branch than risk it being unexpectedly removed. This would
>
Thomas Bereknyei writes:
> That almost sounds like an "unstable" channel.
Unstable and unmaintained are two very different things.
> Rather than removing unmaintained packages, can we make them available as
> a
> separate, opt-in channel?
I'd say that is an option, but if the unmaintai
Excerpts from Alex Berg's message of Wed Jan 29 03:57:56 +0100 2014:
> Rather than removing unmaintained packages, can we make them available as a
> separate, opt-in channel?
Then they will bitrot even faster - because you have to test much more.
It would be possible, I've been using kind of overla
That almost sounds like an "unstable" channel.
On Tue, Jan 28, 2014 at 9:57 PM, Alex Berg wrote:
> Rather than removing unmaintained packages, can we make them available as
> a separate, opt-in channel?
> On Jan 28, 2014 6:43 PM, "Jan Malakhovski" wrote:
>
>> On Tue, 28 Jan 2014 10:36:39 -050
Rather than removing unmaintained packages, can we make them available as a
separate, opt-in channel?
On Jan 28, 2014 6:43 PM, "Jan Malakhovski" wrote:
> On Tue, 28 Jan 2014 10:36:39 -0500
> Shea Levy wrote:
>
> > Thoughts? If we did decide this was a good idea, we should set aside
> > some time
On Tue, 28 Jan 2014 10:36:39 -0500
Shea Levy wrote:
> Thoughts? If we did decide this was a good idea, we should set aside
> some time period by which people should unmaintain packages they don't
> want this responsibility for and adopt packages they do.
For what it worth, I think unmaintained p
On 01/28/2014 04:36 PM, Shea Levy wrote:
> Thoughts? If we did decide this was a good idea, we should set aside
> some time period by which people should unmaintain packages they don't
> want this responsibility for and adopt packages they do.
I like your ideas and think that they will help to cre
Excerpts from Eelco Dolstra's message of Tue Jan 28 18:21:57 +0100 2014:
> It should be possible (if somewhat tricky) to gather this information from the
> logs of cache.nixos.org (at least for those packages that are actually in the
> cache).
You'll get cache hits for "trying packages" - but we ne
On 01/28/2014 06:12 PM, Stewart Mackenzie wrote:
Might we adopt the C4 approach used in zeromq? It was created by Pietor
Hintjens.
We're using it os the Mozart Oz project and numenta/nupic to great success.
Please consider it.
Kind regards
Stewart
I don't understand much, and I think it was
Hi,
On 28/01/14 18:08, Oliver Charles wrote:
>> * If a package is unmaintained, it can be removed with minimal notice.
>> This will require some time under the new idea of maintainership
>> before it can be fairly put into place, but Eelco had the suggestion
>> that no maintainers could be
Excerpts from Shea Levy's message of Tue Jan 28 16:36:39 +0100 2014:
> Thoughts?
I'd try such:
1) replace broken = true by broken_since="date";
(Even maintained packages can be broken - and if they don't get fixed
within 3-6 month they can be "unmaintained" this way.
2) send reminder to use th
Oliver Charles writes:
>> * If a package is unmaintained, it can be removed with minimal notice.
>> This will require some time under the new idea of maintainership
>> before it can be fairly put into place, but Eelco had the suggestion
>> that no maintainers could be treated equivalently t
Shea Levy writes:
> * If a package is unmaintained, it can be removed with minimal notice.
> This will require some time under the new idea of maintainership
> before it can be fairly put into place, but Eelco had the suggestion
> that no maintainers could be treated equivalently to meta.br
On 01/28/2014 04:36 PM, Shea Levy wrote:
Thoughts?
Brokenness should be per-platform, as it's been introduced recently
(meta.broken meaning that no platform is known to work). Thus, for
maintained packages there should be platforms set, so we have at least
"build" status and users have binar
Hi,
I agree with basically everything said, and I think "breaking" packages
with no maintainers (after the next stable branch-off, 14.0x?) would be
really good to make it obvious what is broken and is a candidate for
removal. It would also give people a chance to adopt a package they use
before it
Hi all,
Currently, the semantics of the maintainers meta field are:
* Maintainers get an email when the build changes on hydra
* If making a large change to a package, it might be nice to run it by a
maintainer first
* Maintainers are more likely than the average contributor to update the
pac
23 matches
Mail list logo
