[Nix-dev] okteta fix build

[Karn Kallio]

The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.

[Joachim Schiele]

please provide your nice patches via a PR on github.com/nixos/nixpkgs to
'master'

if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Post by Karn Kallio
The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Karn Kallio]

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs
to 'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Thank you, but I will just post these patches here for anybody who
wants to use them.

[Joachim Schiele]

but this creates a lot of more work for us!

look, we already are behind 390 PRs and working day/night and you would
probably be more helpful with a PR.

https://github.com/nixos/nixpkgs/pulls

that said, do whatever you feel is right. i'm not sure if the ML is the
best place to put patches as we don't have any workflow regarding that.
especially not if you put each patch into a single email and don't use
threads.

regards

Post by Karn Kallio

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs
to 'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Thank you, but I will just post these patches here for anybody who
wants to use them.

[Samuel Leathers]

Thanks for the patch Karn. Joachim, if you want to discuss patches on the
ML further, please do it on the spun off thread Re: [Nix-dev] Are mailing
lists any good for managing patches? (was: okteta fix build).

Thanks,

Sam

Post by Joachim Schiele
but this creates a lot of more work for us!
look, we already are behind 390 PRs and working day/night and you would
probably be more helpful with a PR.
https://github.com/nixos/nixpkgs/pulls
that said, do whatever you feel is right. i'm not sure if the ML is the
best place to put patches as we don't have any workflow regarding that.
especially not if you put each patch into a single email and don't use
threads.
regards

Post by Karn Kallio

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs
to 'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Thank you, but I will just post these patches here for anybody who
wants to use them.

--
Joachim Schiele
nixcloud GmbH
015 20 4145 347
blog: http://lastlog.de/blog
wiki: http://lastlog.de/wiki
https://lastlog.de/blog/about.html)
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Shea Levy]

Mailing list is a perfectly appropriate place to send git patches that
doesn't require membership with a proprietary service; You may not care
about that (I personally don't), but there's no reason we can't
accommodate those who do.

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs to
'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Post by Karn Kallio
The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Tomasz Czyż]

For me https://nixos.org/nixpkgs/manual/#chap-submitting-changes implies
that github must be used.

But on website http://nixos.org/nixos/community.html nix-dev mailing list
is mentioned as another way.

Would be nice to be more clear and specific how it works and who is
responsible for testing changes if they are not comming as PR, is there any
travis like pipeline etc.

Post by Shea Levy
Mailing list is a perfectly appropriate place to send git patches that
doesn't require membership with a proprietary service; You may not care
about that (I personally don't), but there's no reason we can't
accommodate those who do.

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs to
'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Post by Karn Kallio
The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Shea Levy]

We should definitely update the manual. Travis provides no value anyway
for nixpkgs IMO.

Post by Tomasz Czyż
For me https://nixos.org/nixpkgs/manual/#chap-submitting-changes implies
that github must be used.
But on website http://nixos.org/nixos/community.html nix-dev mailing list
is mentioned as another way.
Would be nice to be more clear and specific how it works and who is
responsible for testing changes if they are not comming as PR, is there any
travis like pipeline etc.

Post by Shea Levy
Mailing list is a perfectly appropriate place to send git patches that
doesn't require membership with a proprietary service; You may not care
about that (I personally don't), but there's no reason we can't
accommodate those who do.

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs to
'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Post by Karn Kallio
The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

--
Tomasz CzyŌ

[Joachim Schiele]

aszlig pointed out that we have a pointer in the manual to send patches
to the ML if the user in question does not like github which is a valid
workflow for me.

BUT we are stagnating in PRs are the moment (390 open PRs) and having a
patch per email is overkill. maybe a PR from a different git source
instead? i would rather like a git based workflow than having to align
the single files into a commit.

maybe we have to find a better workflow here which automates things.

Post by Shea Levy
Mailing list is a perfectly appropriate place to send git patches that
doesn't require membership with a proprietary service; You may not care
about that (I personally don't), but there's no reason we can't
accommodate those who do.

Post by Joachim Schiele
please provide your nice patches via a PR on github.com/nixos/nixpkgs to
'master'
if you are unsure about the workflow, please ask and we'll help you!
thanks for your work!

Post by Karn Kallio
The attached patch fixes the build of the Nixpkgs KDE application
okteta by adding some missing dependencies.
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Linus Heckemann]

Post by Joachim Schiele
aszlig pointed out that we have a pointer in the manual to send patches
to the ML if the user in question does not like github which is a valid
workflow for me.
BUT we are stagnating in PRs are the moment (390 open PRs) and having a
patch per email is overkill. maybe a PR from a different git source
instead? i would rather like a git based workflow than having to align
the single files into a commit.

FWIW this *is* a git-based workflow, git comes with the ability to
format patches for emails and import such patches (and was designed with
this in mind for use in the development of linux) — see man
git-format-patch and git-am. I personally think it's fine receiving
patches like this — if volume increases maybe there should be another
list specifically for patches, but at current levels IMHO it's no problem.

Linus

[Alexandre Peyroux]

Certainly but on big projects that have many developers and a lot of PR, it
loses its charm.

Post by Linus Heckemann

Post by Joachim Schiele
aszlig pointed out that we have a pointer in the manual to send patches
to the ML if the user in question does not like github which is a valid
workflow for me.
BUT we are stagnating in PRs are the moment (390 open PRs) and having a
patch per email is overkill. maybe a PR from a different git source
instead? i would rather like a git based workflow than having to align
the single files into a commit.

FWIW this *is* a git-based workflow, git comes with the ability to
format patches for emails and import such patches (and was designed with
this in mind for use in the development of linux) — see man
git-format-patch and git-am. I personally think it's fine receiving
patches like this — if volume increases maybe there should be another
list specifically for patches, but at current levels IMHO it's no problem.
Linus
_______________________________________________
nix-dev mailing list
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Linus Heckemann]

Post by Alexandre Peyroux
Certainly but on big projects that have many developers and a lot of PR,
it loses its charm.

I respectfully disagree. Linux has received contributions from 642 (I
think that qualifies as "many") developers in 2017 alone using this
model. Sure, it's not shiny and Web 2.0 like GitHub, but it works. And
from a maintainer's point of view (this is versus merging in patches
which have been pushed to another host than github):

- I can view the patches without importing them or working out how to
navigate git web interface xyz (if there is a web interface).

- I can import the patches directly into my repo. No trying to find the
clone URL on a web interface (if the contributor hasn't sent me the
clone URL itself).

- I can comment on specific parts of the patches inline without having
to copy and paste fragments into an email, without signing up for an
account on the git host (if that's even possible) and commenting there
(again, if that's even possible).

Of course, these are all possible on github. But it's a proprietary and
centralised service. With the email process, I can do all of this
offline and using only free software.

Overall, this process has the advantage of minimising network
communication and variation in the process for performing the various
tasks that might be necessary.

Hoping but not expecting to have convinced you ;)

Linus

[Tomas Hlavaty]

I find emails better than github too.

It's easy to get banned by github.

As for PR accumulation, here is an interesting take on bug trackers:
http://yarchive.net/comp/linux/bug_tracking.html

[Richard Ipsum]

Post by Tomas Hlavaty
I find emails better than github too.
It's easy to get banned by github.
http://yarchive.net/comp/linux/bug_tracking.html

http://jk.ozlabs.org/projects/patchwork/ may also be of interest.

[Vincent Laporte]

Pushed as c710ddf7cde471f16ea9af6ffc5e5cc6efb17fc6. Thanks.