<gchristensen>
ok better than vscode is idea-ultimate
<gchristensen>
it worked _almost_ perfectly out of the box, and only a minor tweak to the settings was required to work perfectly
<gchristensen>
(that tweak was telling it to find the docbook xsd at /nix/store/ymqcc629ym9fw3b3aglnh2f9c7d4x6nv-docbook5-5.0/share/xml/docbook-5.0/xsd/docbook.xsd)
<gchristensen>
it does live validation as you type
goibhniu has quit [Ping timeout: 240 seconds]
infinisil has quit [Quit: Configuring ZNC, sorry for the join/quits!]
infinisil has joined #nixos-dev
<samueldr>
is there hope for idea community edition?
<gchristensen>
there is hope for "free licenses for active contributors to active open source projects"
orivej has quit [Ping timeout: 256 seconds]
<gchristensen>
(samueldr, I already submitted the request for it)
<samueldr>
oh, it's more that I like it when the open-source version of a product does all the required bits, I was only curious if the docbook parts were in community
zybell_ has quit [Ping timeout: 256 seconds]
<gchristensen>
oh interesting questio
<gchristensen>
let's find out
<gchristensen>
works great, samueldr
<samueldr>
neat, this would make it way easier to onboard contributors to write docs
mbrgm has quit [Ping timeout: 260 seconds]
<gchristensen>
there are a couple teensy tiny annoyances
<samueldr>
present in both editions?
mbrgm has joined #nixos-dev
<gchristensen>
yeah, links like <xref linkend="sec-configuration-syntax"/> in one document, referring to an ID in another document, is a validation error
<samueldr>
if it's part of community, then it's (hopefully) a bit that can be looked at :)
<gchristensen>
aye
<samueldr>
(which is why I love open source software even when I don't look and fix)
<gchristensen>
anyway, bed time ... I'd encourage you to try out idea-community on the docs :)
<samueldr>
(I actually opened it minutes ago)
<gchristensen>
(oh cool!)
zybell_ has joined #nixos-dev
pie_ has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
orivej has joined #nixos-dev
ma27 has quit [Ping timeout: 256 seconds]
ma27 has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
xeji has joined #nixos-dev
xeji has quit [Ping timeout: 256 seconds]
<Mic92>
xeji fixed a large amount of packages for the last release. How about giving him merge access?
pie_ has joined #nixos-dev
ckauhaus has joined #nixos-dev
<gchristensen>
their first PR was only feb 18, not a long time, but I'm not sure this is a problem exactly
ckauhaus has quit [Ping timeout: 256 seconds]
<Mic92>
81 merged pull requests since then with 4 open ones.
ckauhaus has joined #nixos-dev
ckauhaus_ has joined #nixos-dev
ckauhaus has quit [Ping timeout: 256 seconds]
ckauhaus_ has quit [Ping timeout: 260 seconds]
ma27 has quit [Quit: WeeChat 2.0]
ma27 has joined #nixos-dev
ma27 has quit [Quit: WeeChat 2.0]
<peti>
domenkozar: If you feel strongly about keeping that UI issue collection ticket open, then please feel free to re-open it. Please assign it to yourself, though, and make sure it's tagged appropriately.
<peti>
domenkozar: Personally, I don't having it open. I did mind having open while it's being assigned to me though. :-)
<domenkozar>
peti: do you know why shlevy assigned this to you?
<peti>
domenkozar: Because all old tickets got divided into equal chunks, and each maintainer got assigned one chunk for triaging. That ticket was part of the chunk I got.
<peti>
domenkozar: I looked at at and felt that it's not important to keep open.
<peti>
domenkozar: It does not address any specific issue and it's not actionable and it's been inactive for 2+ years. So what's the point?
<domenkozar>
theres 51 comments on it
<domenkozar>
which results in Nix 2.0 resdesign
<domenkozar>
I think it's important, but it needs to be revisited.
<peti>
domenkozar: Why do you think that it's important to have this ticket open?
<domenkozar>
I understand it's an open question, but I find such discussion healthy, unless people start to nitpick and derail it as a way to collect opinion
<domenkozar>
peti: because if you close it, people will feel unheard
<domenkozar>
there might be comments there still relevant today
<domenkozar>
so the least we can do today is not to give feedback "we don't care"
<peti>
domenkozar: When did I say that I don't care?
<domenkozar>
or "won't fix"
<domenkozar>
well you say that nothing happened in 2 years
<domenkozar>
and conclude that's it
<domenkozar>
I consider that as negative feedback to someone who tied to weight in their opinion
<domenkozar>
so I don't see much benefit closing it down.
<domenkozar>
s/tied/tried/
<peti>
The benefit is that we have one less unspecific, unactionable, inactive open ticket.
<peti>
The ticket was a fine vehicle for the UI discussion that took place, but now the discussion has run out.
<domenkozar>
I think we should focus efforts on acitonables, instead of closing down unactionables
<peti>
So we don't need the ticket any more.
<domenkozar>
and unactionables can become actionables one day
<domenkozar>
peti: anyway that's just my opinion, I think it's not white&black
<peti>
domenkozar: Well, I suppose we have different expectations towards an issue tracker. I use it differently, therefore I find other other things valuable and relevant.
<domenkozar>
yes, I see issue tracker as expressing opinions, which esspecially in context of UX means attached emotions with some preexperienced pain
<domenkozar>
so I don't think issue tracker should be treated as a purely technical system
<peti>
Yeah, that's where we differ.
<domenkozar>
and once you closed down the issue, someone did write a pretty long writeup they *feel* like issue should be open
<domenkozar>
so there's some evidence to that
<peti>
I completely agree that users *have* these feelings and they do get angry when an issue is closed without a clear resolution. This does happen.
<peti>
I just decided for myself at some point that I don't care. The purpose of the issue tracker is not to make people feel good. The purpose is to organize open issues.
<peti>
My perception is that all those open tickets that no-one reads and no-one does anything about drown out the ones that are actually actionable and important.
<simpson>
Ignore feelings, acquire evidence.
<peti>
domenkozar: Anyhow, thank you for disagreeing with me and giving me the opportunity to examine my own perspective. :-)
<MichaelRaskin>
Of course, we wouldn't have this problem if we had an actual issue-tracking system and not that GitHub something
<MichaelRaskin>
I mean, it is completely clear that bugs, feature requests, and long-term opinion collection are three different kinds of things that shouldn't be randomly mixed…
<peti>
Technically, discussions ouught to
<peti>
Technically, discussions ought to take place in the form of an RFC.
ckauhaus has joined #nixos-dev
<peti>
But yeah, I agree that github issues are terrible for long-running discussions. They offer too little structure.
<MichaelRaskin>
GitHub * is terrible for * if you actually care about *
<MichaelRaskin>
I guess one could emulate something that looks like a workflow if it was possible to move issues between projects.
<domenkozar>
peti: sorry, had a phone call
<domenkozar>
peti: yeah, I have learned that caring is hard as well, but I do think investing into people rather than just tech is at most valuable, although it should be taken with care as sometimes it can go too far
<domenkozar>
but I also understand your view, I share it to some extent :)
ckauhaus has quit [Ping timeout: 248 seconds]
<domenkozar>
hence why I say there's no right or wrong here
<MichaelRaskin>
To be honest, I would expect the sides to be reversed, given peti's opinion on fast reverting whatever breaks evaluation unless it is obvious how to fix it…
<peti>
MichaelRaskin: Good point. On that particular occasion, I am more sensitive to other's feelings. I am not sure why.
<MichaelRaskin>
I have a theory as to «why» — reverts usually hit people with some proven investment into moving nixpkgs forward. On the other hand, failing evaluations make a few useful tool useless, which also hits (another group of) people with proven investment into improving Nixpkgs…
<thoughtpolice>
Ah, forgot how much I love NixOps. Running a brand new 'nixops deploy' with 5 machines, the first time only starts the first one, not the others concurrently, it then fails inexplicably despite succeeding to start the 1st VM, and running deploy again deploys in parallel to the remaining 5 machines.
<MichaelRaskin>
To the remaining four, I hope.
<thoughtpolice>
yes, typo
<MichaelRaskin>
With Shodan and Autosploit you never know…
<peti>
MichaelRaskin: Yeah, that sounds right. People who commit to Nixpkgs are more important to me than random Github users. So in case someone commits a broken change to Nixpkgs, I have more patience.
<MichaelRaskin>
On the other hand, broken commits in Nixpkgs make more splash damage than unactionable issues…
<domenkozar>
yeah but once most of these people were a random github person :)
<MichaelRaskin>
domenkozar: I think a typical Nixpkgs committer has submitted a patch or PR before opening their first issue.
<domenkozar>
I wouldn't judge people by their first action
<domenkozar>
I think initial impression is really important and it should be "good hearted" from both sides, but again, that's a lot of work :)
<MichaelRaskin>
It is more of judging the actions by the people who typically do it, though
<domenkozar>
but it's less work than fixing everything ourslves
<MichaelRaskin>
Well, I would say that the bottlenecks matter. Right now it is not acquisition of contributors, it is triaging of PRs. Even if we subtract the automated tide.
<MichaelRaskin>
Accepting good code already submitted.
<MichaelRaskin>
Which is why I mostly support fast reverts — broken eval hits tools related to the bottleneck
<domenkozar>
yeah I think we all agree on that :)
<MichaelRaskin>
I am not sure we all agree on fast reverts, though
<thoughtpolice>
peti: I would definitely agree on prioritizing Nixpkgs/Nix users above non-users, theoretical users, etc, for certain, and making their lives better as a priority. OTOH, regarding the issue tracker -- I think it's pretty much inevitable that, at a given threshold, all bug/issue trackers sort of turn into this -- more like an open forum of active things people are thinking about more than "I need to keep tabs on issue X Y Z."
<angerman>
peti: I’m around if you have questions.
<thoughtpolice>
Really I only get tagged on issues now I'm explicitly pinged on; luckily the bots help with that on maintainer-related stuff, but otherwise there's just too much. I think people at this stage are going to naturally silo into the key issues they care about
<thoughtpolice>
(I'm, like, never going to read a ticket about Ruby stuff, for example, unless something mysteriously regressed in my closure. So I really don't want to even think about it that much.)
xeji has joined #nixos-dev
ckauhaus has joined #nixos-dev
ckauhaus has quit [Ping timeout: 260 seconds]
pie_ has quit [Read error: Connection reset by peer]
<peti>
I guess a more sophisticated project management software would be good. Github is fine for small projects, but for our purposes it's too simplistic.
pie_ has joined #nixos-dev
<peti>
angerman: I got the tool to compile and converted a couple of expressions already. :-)
<angerman>
peti: I’d love to get feedback :-)
<angerman>
peti: I honestly didn’t expect anyone to give it a try just yet though :-)
<peti>
angerman: The big question is in the design of the generated Nix expression. There's various trade-offs to consider and looking at concrete examples is super helpful in understanding how these trade-offs manifest themselves.
<peti>
angerman: Personally, I lean towards not mentioning Haskell dependency as arguments *at all* and instead to assume what "with self;" brings all required names into scope. Flags, on the other hand, are something I would list explicitly and individually as arguments to the function, because it's important that people get feedback when they pass a flag to the function that's actually not supported by the
<peti>
build.
<peti>
Anyhow, having the prototype available for experimentation helps a lot.
<angerman>
peti: I agree. It’s mostly in the design stage now. Trying to figure out something that works for me right now.
orivej has joined #nixos-dev
pie__ has joined #nixos-dev
pie__ has quit [Quit: Leaving]
drakonis has joined #nixos-dev
xeji has quit [Quit: WeeChat 2.0]
jtojnar has quit [Read error: Connection reset by peer]