Hi Arseniy,
On Tue, May 19 2015, Arseniy Seroka wrote:
We have this.
Read about it in a making patches section [1]
[1]
https://github.com/jagajaga/nixpkgs/blob/addition/contributing/CONTRIBUTING.md
what's the status of that document?
We also have: https://nixos.org/wiki/Contributing
Is
On Tue, May 19 2015, Peter Simons wrote:
Hi Florian,
What is the reasoning to have these in a separate repository?
We don't want notification e-mails sent out every time the channel
updates, which would happen if these branches were pushed to the main
repository.
Thx - I added
github shows CONTRIBUTING.md when you open an issue/PR, that's the main
reason I'd like to see it as an entry point to contributing to Nix family.
The wiki page and nixos.org is something ~1% of contributing users will
ever read.
On Fri, May 22, 2015 at 11:04 AM, Florian Friesdorf
There is also a thread mentioning contribution from march:
Some bug tracker experience and RFC on improvements
On Fri, May 22 2015, Florian Friesdorf wrote:
Hi Arseniy,
On Tue, May 19 2015, Arseniy Seroka wrote:
We have this.
Read about it in a making patches section [1]
[1]
Hi,
On 20/05/15 22:23, Nicolas Pierron wrote:
I did that a while ago, and somebody removed them, because of the
potential noise that such branches can caused.
Then I pushed the script that I made to keep track of the channel versions.
You can use this script in your nixpkgs working
On 05/19/2015 07:36 PM, Matthias Beyer wrote:
On 19-05-2015 12:08:30, Vladimír Čunát wrote:
I'm uncertain if there might be some performance implications [...]
From a git point of view, there won't be any performance implications
besides that the tags get fetched on `git fetch` - which is
Hi,
I did that a while ago, and somebody removed them, because of the
potential noise that such branches can caused.
Then I pushed the script that I made to keep track of the channel versions.
You can use this script in your nixpkgs working directory, run
$ $(git rev-parse
I've wrote that and nobody mentioned :(
2015-05-20 23:23 GMT+03:00 Nicolas Pierron nicolas.b.pier...@gmail.com:
Hi,
I did that a while ago, and somebody removed them, because of the
potential noise that such branches can caused.
Then I pushed the script that I made to keep track of the
On 20/05/2015 14:44, Vladimír Čunát wrote:
On 05/19/2015 07:36 PM, Matthias Beyer wrote:
On 19-05-2015 12:08:30, Vladimír Čunát wrote:
I'm uncertain if there might be some performance implications [...]
From a git point of view, there won't be any performance implications
besides that the
Hi,
nix channels are series of snapshots of nixpkgs that were succesfully
build by hydra and we subscribe and update them via nix-channel - for
users of nixpkgs this is great!
As maintainers of nixpkgs and users who keep custom patches, we also
have one or more local checkouts of
What is the reasoning to have these in a separate repository?
What do you think about adding tags like I proposed?
On Tue, May 19 2015, Domen Kožar wrote:
We have https://github.com/NixOS/nixpkgs-channels that has branches that
track latest channel updates
On Tue, May 19, 2015 at 9:56 AM,
Hi Florian,
What is the reasoning to have these in a separate repository?
We don't want notification e-mails sent out every time the channel
updates, which would happen if these branches were pushed to the main
repository.
Best regards,
Peter
___
We have https://github.com/NixOS/nixpkgs-channels that has branches that
track latest channel updates
On Tue, May 19, 2015 at 9:56 AM, Florian Friesdorf f...@chaoflow.net wrote:
Hi,
nix channels are series of snapshots of nixpkgs that were succesfully
build by hydra and we subscribe and
We have this.
Read about it in a making patches section [1]
[1]
https://github.com/jagajaga/nixpkgs/blob/addition/contributing/CONTRIBUTING.md
Sincerely,
Arseniy Seroka
On 19 May 2015 12:15:00 Florian Friesdorf f...@chaoflow.net wrote:
Hi,
nix channels are series of snapshots of nixpkgs
On 05/19/2015 11:22 AM, Florian Friesdorf wrote:
What do you think about adding tags like I proposed?
Listing the tags will quickly become unwieldy, but for a persistent
reference it will be more readable to have channel-date than some random
hash (or maybe channel/date or something). It might
On 19-05-2015 12:08:30, Vladimír Čunát wrote:
I'm uncertain if there might be some performance implications when
working on a repo with too many tags, but as this won't be in the main
repo, we can easily chance it.
From a git point of view, there won't be any performance implications
besides
16 matches
Mail list logo
