<Drakonis[m]>
heh well, being easy to work with through pull requests
<Drakonis[m]>
fedora is too feudal
<Drakonis[m]>
same with debian
<MichaelRaskin>
Frankly, it is a sobering and a stressful reminder that even with all our process bottlenecks…
<Drakonis[m]>
debian has remedied the issue by allowing packagers to send in packages using pull requests
<Drakonis[m]>
fedora doesn't have that
drakonis has joined #nixos-chat
<drakonis>
despite the fact that i'm not a fan of how rigid the system in many aspects, it is still ahead of the curve
<gchristensen>
drakonis: where were we brought up?
<drakonis>
PRs-on-distgit
<gchristensen>
ah cool
<drakonis>
it is the direct mention
<drakonis>
the other parts are still relevant in a way or another
<gchristensen>
having individual repos would make it easier to pretend we had fewer bugs
<drakonis>
ha
zybell_ has quit [Ping timeout: 240 seconds]
<drakonis>
fedora's packaging stack is quite crummy while debian has a quite robust stack with extremely rigid packaging rules
<drakonis>
be back in a few minutes
<drakonis>
by virtue of having this repository model, its way easier to maintain packages
<drakonis>
because fish was out of date for two years on fedora
<drakonis>
only because nobody wanted to go through the process of getting someone to update it
<drakonis>
gotta contact the maintainer or go through the red tape involving taking over a package
<gchristensen>
yeah
<drakonis>
debian has the same issues
<LnL>
gchristensen: lol
<MichaelRaskin>
That red tape we keep talking about introducing?
<drakonis>
except its much easier to do it on your own
<drakonis>
what kind of red tape though
<drakonis>
debian has the most red tape because you have to write down every possible license a package has
<MichaelRaskin>
Well, stronger code ownership model
<gchristensen>
that is a good thing IMO
<drakonis>
AND you have to package every dependency in the chain
<gchristensen>
re licenses
<drakonis>
code ownershp model?
<drakonis>
yes it is
<drakonis>
but there's complex packages with hundreds of varying licenses lol
<gchristensen>
yeah
<drakonis>
eclipse for example
* gchristensen
hides
<drakonis>
the debian licenses package is huge
<drakonis>
the licenses file
<MichaelRaskin>
Well, weakness of the code ownership model is why any PRs ever get merged in Nixpkgs.
<drakonis>
the feudalism in fedora and debian is a pretty shitty thing
<MichaelRaskin>
I am not sure strong ownership model and feudalism are distinct enough
<drakonis>
its a fiefdom
<drakonis>
you have hundreds of individual packages with their own maintainers
<drakonis>
this is a problem
<MichaelRaskin>
Right, clear ownership
<MichaelRaskin>
Which is a problem, I agree
<drakonis>
people maintaining packages that only have to be version bumped every x time
<drakonis>
they tend to create little fiefdoms for themselves
<drakonis>
adding red tape is only useful for complex packages sets
<drakonis>
because these don't always involve just version bumps when updating
<drakonis>
anyways, is this the right place for this conversation or is #nixos-dev the proper place?
<MichaelRaskin>
Well…
<drakonis>
seems like i already found the answer :V
<MichaelRaskin>
Oh?
<drakonis>
for my own question
<drakonis>
its probably -dev
<MichaelRaskin>
I would say that the current relevant topic for process optimisation is the Nix Release Process RFC
<MichaelRaskin>
For example: it is the first RFC in half a year that has good chances to be passed after actual comments and significant changes based on discussion
<drakonis>
this isn't exactly the topic i was talking about though
<drakonis>
this is Nix and not Nixpkgs
<MichaelRaskin>
Well, having a visibly working RFC process is probably a prerequisite for any process changes anyway
<drakonis>
well i see
<drakonis>
i don't see any rfc for package ownership :v
<drakonis>
i do assume that there's code owners list on nixpkgs
<MichaelRaskin>
Also, Nix has the Nix Core team (which is officially declared as a process experiment), so I think it is a good idea to see how it works.
<shlevy>
Haven't followed this whole thread, but I plan to have an update against the main PR on Monday
<MichaelRaskin>
There is something. It is not clear what it does. The expectation is that _if_ the person is in the list _then_ this person is (one of) the main developers of something complicated
<Drakonis[m]>
it looks fine as it is, as long the same courtesy isn't extended to everyone that wants an small package
<MichaelRaskin>
It is not clear what ownership means in practice.
<MichaelRaskin>
Like, there are notifications, OK
<Drakonis[m]>
who maintains what
<MichaelRaskin>
We _also_ have meta.maintainers for that
<MichaelRaskin>
For complicated packages there is normally no huge competition of people trying to take over that mess…
<Drakonis[m]>
it doesn't provide power
drakonis has quit [Read error: Connection reset by peer]
<Drakonis[m]>
it simply messages them
<MichaelRaskin>
Well, it is probably slightly more rude not to wait a reasonable time for comments by a code owner than by the maintainer
<Drakonis[m]>
okay, my point is, don't give people free control over a tiny slice of the repository because they're going to get into fights
<samueldr>
hey now, I'll fight your for my right to get into fights over little things (/s)
<Drakonis[m]>
this week an unresponsive maintener got in a fight because the folks that took over did it in a way he didn't like and without his consent
<Drakonis[m]>
this was debian mind you
<Drakonis[m]>
fedora has its own fights too
<Drakonis[m]>
drove people out of the project
<MichaelRaskin>
It's not like we _never_ have questions «why in the world did you do that this way» answered with «well, we tagged you two weeks ago and got no reply»…
<MichaelRaskin>
But that usually doesn't escalate to a proper fight.
<Drakonis[m]>
of course
<MichaelRaskin>
Our process has many bottlenecks, things get blocked and stalled. Fights are things.
<Drakonis[m]>
it's less perceptible
<MichaelRaskin>
What? A fight that got stalled before happenning? Yes, it's not always easy to notice.