Most patches cannot break master.
This is not a monolithic software.
Patches may break a package, or a few of them, but not "master" as a whole.
If the patch modifies a widely used package or something more risky,
then a local buid it usually the way to go, unless Travis got it green.
-- Layus.
On 03/07/16 18:18, Azul wrote:
so what do you guys use as a quality gate then?
how do you make sure a patch won't break master? are you just testing
it locally on your machines?
- curious
On 3 Jul 2016 16:27, "Bjørn Forsman" <[email protected]
<mailto:[email protected]>> wrote:
On 3 July 2016 at 17:20, Azul <[email protected]
<mailto:[email protected]>> wrote:
> n00b to the nix community so forgive my ignorance here.
> is this the correct way to submit patches to nixpkgs ?
> I attempted a PR some time ago which I never managed to get to build
> properly on Travis or identify why the Travis build scripts
failed the the
> build , so I scrapped it all together. Being new to nix and
being very short
> of time meant I didn't have the opportunity to debug it
properly. I could
> say I read some sort of contributor guidelines which lead to
follow the
> usual github PR, test, wait for green and ask for a review but
maybe I just
> dreamed it up or I was thinking of some other open source project?
>
> so what is the best way to send patches to nix in a sane and
safe way that
> won't break master ?
In general the best way is github PRs. But patches on the mailing list
may be applied too. Someone just have to do it...
The Travis builds are unfortunately failing a lot. It is my feeling
that most devs will look at PRs even if Travis are failing.
- Bjørn
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________
nix-dev mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-dev
