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
Thomas Bereknyei tombe...@gmail.com 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
Jan Malakhovski o...@oxij.org 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
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
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 your
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 your
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
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
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
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
Shea Levy s...@shealevy.com 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
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 the
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 treated
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
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 need
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
On Tue, 28 Jan 2014 10:36:39 -0500
Shea Levy s...@shealevy.com 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
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 o...@oxij.org wrote:
On Tue, 28 Jan 2014 10:36:39 -0500
Shea Levy s...@shealevy.com wrote:
Thoughts? If we did decide this was a good idea, we should
That almost sounds like an unstable channel.
On Tue, Jan 28, 2014 at 9:57 PM, Alex Berg chex...@gmail.com 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 o...@oxij.org wrote:
On Tue, 28
19 matches
Mail list logo
