<samueldr>
I dislike being negative, but here goes baseless speculation and FUD for at least the whole week
<andi->
well that doesnt read like speculation at all anymore.. but yes speculations about the future of github
<andi->
I'll enjoy the fire from the backseat..
* andi-
continues reading firefox code
<samueldr>
I meant speculation about what's going to happen next, not about the acquisition
<samueldr>
and the numerous "what are we doing now that microsoft eats babies^W^W" questions :/
<samueldr>
I just hope that if nixos, or anything I care for, moves (I don't care that much) the move will not be reactionary and done in a hurry...
<andi->
yeah
<samueldr>
e.g. hosted gitlab.com isn't as good as it looks
<andi->
btw. did you see the results of tha backup attempt?
<samueldr>
been using it for work-related projects and it's way too often down
<samueldr>
no
<samueldr>
and when up, sometimes their pipelines (CI stuff) break
<andi->
I have been using self-hosted gitlab for a while now and it is fun to use in small to medium sized teams
<samueldr>
yes, self-hosted seems much better
<samueldr>
before gitlab.com we were using an older revision self-hosted and never had problems
<samueldr>
which is why I was surprised the .com product had so many issues
<gchristensen>
unclear if gitlab could handle a project of our size
<samueldr>
(probably a case of scaling is hard)
<samueldr>
I would like to see if anyone has experience with using phabricator here
<andi->
gchristensen: yeah, thats what I am concerend about.. the only project that big or similar is probably gitlab itself..
<samueldr>
both admin and day-to-day use
<samueldr>
phabricator is used by big projects (freebsd, mediawiki to name a few)
<samueldr>
but seems out of the mindshare
<samueldr>
maybe because it doesn't do the actual git hosting
<samueldr>
and is only used to manage the projects
<samueldr>
I think the biggest issue, too, would be that they don't do the PR workflow, but work on patches
<gchristensen>
gitlab has had 1/2 the # of issues/prs
<samueldr>
when I looked at it briefly for work-related uses, it seemed way too powerful
<gchristensen>
but seems about the size
<andi->
a tool
<andi->
is way too powerful?
<samueldr>
somehow I think there must be a catch
<andi->
I mean for the regular contributor that should be the same amount of pain/gain
<gchristensen>
we could do all our issue tracking in assembly, but that is probably too powerful right?
<andi->
too verbose you mean?
<samueldr>
well, what I really meant was that it either is the perfect tool, but nobody uses it, or something blatant is missing and is why nobody is using it
<samueldr>
maybe the workflow of not-using-prs is the biggest issue :/
<andi->
nobody uses it? I've seen many larger organizations adopt it in the last years.. The problem is probably that the OSS world already has had their tools when gitlab became viable
<gchristensen>
its like JIRA for code tracking
<samueldr>
for work-related use, what seemed powerful is that projects aren't 1:1 related to code
<samueldr>
multiple repos or none can be part of a project
<samueldr>
yeah, "nobody" was an hyperbole
<samueldr>
I meant that the mindshare when talking alternatives for code and project management seems almost inexistant for it
<andi->
if we are back at the stage where we just need a review tool we might as well consider gerrit.. really ugly but gets the job done
<gchristensen>
gerrit is great for filtering out drive by contributors
<samueldr>
:)
<andi->
yes it is... add a CLA ontop..
<MichaelRaskin>
Maybe it is a feature?
<gchristensen>
andi-: and all your contributors are paid to do it
<andi->
yeah..
<MichaelRaskin>
Our open PR count does the same, and requires more effort for the same amount of driving-away
<andi->
it stopped me from fixing some issues in Openstack in '11 or so.. never bothered again
<samueldr>
(though, I was asking for opinions/experience about phabricator not for nixos-related uses, but general uses)
<andi->
A friend of mine usese that for a larger PHP page.. it's okay according to him but probably wouldn't work with our amount of changes
<gchristensen>
works for facebook, no?
<samueldr>
works for freebsd, no?
<andi->
well I have only 2nd hand experience..
<samueldr>
:)
<andi->
talked about it a few days ago (friday?)
<samueldr>
one day I'll fixup the phabricator in nixos and force my colleagues to use it :)
<andi->
hrhr
<samueldr>
(btw, not much was needed last time I tried, version bump and maybe one or two new dependencies)
<samueldr>
(and data migration across 2 year of releases worked)
<samueldr>
so, it looked easy enough to manage
matthewbauer has quit [Ping timeout: 268 seconds]
<andi->
we would also be in the business of running infrastructure that must not fail :)
<MichaelRaskin>
«must»?
* samueldr
wonders if phacility would host nixos' instance
<andi->
should
<samueldr>
it could be a kind of challenge for them (if volume *is* that unmanageable)
<andi->
should not fail.. I mean we should not destroy our data..
<andi->
samueldr: I think the volume limits where more in the tweaking and adding more hosts area from how I understood..
<MichaelRaskin>
If you want to not destroy data, you want an official read-only mirror (might be plain git) that always has all the repos, and put all the extra data you care about into one of the mirrored repos
<MichaelRaskin>
Obviously, the mirror should be maximally different-stack
<gchristensen>
andi-: indeed it would be important for it to be quite up
<MichaelRaskin>
If uptime is worth caring about, it is worth to be discussed in terms of kinds
<andi->
My main concern is being attractive to new contributors.. be it overhead or not if the project is not easily approachable many people wouldn't be here today?
<gchristensen>
+1
<MichaelRaskin>
Readable git repository, writeable git repository. full UI, channels, binary cache — the uptime requirements could be different
<andi->
So, we should probably step back and see what the wider community does
<manveru>
nobody using gitea?
<andi->
wasnt that the software that still hsa issues with diffs?
<MichaelRaskin>
Handling contributions that actually happen is as important and maybe more important than attracting new contributors
<andi->
well it is definitly required to balance it
<MichaelRaskin>
Unless the plan is to also double the number of committers…
<andi->
I am not sure if the number of committers is a good metric. How many are basically inactive?
<MichaelRaskin>
(which might be a good idea anyway, but it probably doesn't happen in a single week)
<MichaelRaskin>
Changes in it are usually a sensible indicator in the short term, though
<andi->
manveru: i run an older gogs instance for private stuff but that is rarely used.. it is just a fancy gui to configure repos for me..
<MichaelRaskin>
Because the new committers are usually selected among the recently active people
<manveru>
andi-: i don't have any problems with diffs...
<MichaelRaskin>
If you care about first-time friction too much, you end up choosing the next social network with some code hosting attched — like GitHub — and waiting nutil it is bought by, dunno, Facebook
<andi->
manveru: it think on two ocassions when I contributed somewhere else newly added files did not show up or showed up strangely. Shows files I didn't even touch..
<MichaelRaskin>
Because preexisting accounts
<andi->
MichaelRaskin: so lets go back to MLs and patches?
* andi-
still likes email
<MichaelRaskin>
You forgot to include SVN in the package!
<manveru>
i dunno man, i just like how easy the setup is compared to gitlab :P
<andi->
CVS
<andi->
works for OpenBSD
<MichaelRaskin>
Nope, Nixpkgs never was in CVS
<andi->
i know
<andi->
but we could move there
<MichaelRaskin>
Also, the notion of atomic commit _is_ useful for Nixpkgs
<MichaelRaskin>
See also: NixOS move inside the main repo
<andi->
not seriously arguing for CVS or going back to SVN...
<andi->
it's just a thing that would probaly help keep the community smaller ;)
<MichaelRaskin>
SVN does have its plusses over Git
<MichaelRaskin>
especially for the Nixpkgs case
<manveru>
thanks for causing me flashbacks to the early 2000s
<andi->
which ones come to your mind? I had a discussion with a friend from game studio recently.. they have the SVN vs git weekly...
<MichaelRaskin>
I mean, narrow checkouts are nice
<MichaelRaskin>
Also, git is approximately the worst possible choice w.r.t. command set, and git is not for storing history that anyone actually plans to look up
<andi->
what makes you think the history isn't useable?
<__monty__>
How does narrow checkout differ from shallow clone?
<MichaelRaskin>
narrow vs shallow
<MichaelRaskin>
subdir or only part of timeline
<MichaelRaskin>
space vs time
<__monty__>
Got it.
<andi->
thats the one thing I personally miss from SVN. The rest of the features that I came in touch with can rest in peace
<MichaelRaskin>
For me SVN outranks two VCSes I have used: CVS and git
<__monty__>
What's so bad about git?
<andi->
Have you considered HG?
<MichaelRaskin>
Mercurial is nice.
<MichaelRaskin>
Personally, I prefer Monotone.
<MichaelRaskin>
But it might bitrot at some point, and I am not sure what would be a good migration target. Because Monotone has nice things nobody else has.
<MichaelRaskin>
Maybe fossil or pijul
<MichaelRaskin>
git command set… there are things that are badly designed, but git command set is not one of them. It is not designed at all, apparently
<andi->
well, it is often no very intuitive but somehow it has become the defacto standard :/
<MichaelRaskin>
git data model is not for ever looking up history. We don't even store channel bump history in git
<MichaelRaskin>
andi-: I can tell you how
<MichaelRaskin>
First, the git command set has not become defacto standard
<MichaelRaskin>
A small subset yes, and even it is not used correctly by the majority of users
<andi->
MichaelRaskin: isn't that more of a user error (channel bump data) since that basically happens out of band?
<MichaelRaskin>
And how it became standard — well, Linus Torvalds has personally applied a _heroic_ amount of effort to explain to people why DVCS
<andi->
the git-way would be to have tags on the channel bumps?
<MichaelRaskin>
andi-: and that amount of tags is completely unusable
<andi->
yes, agreed
<MichaelRaskin>
In Monotone I would just have a non-contiguous branch which is a subset of another branch
<andi->
but I fail to see what a "proper" way would be to do that if not store the git commits in a text file and manage that with some VCS again
<samueldr>
about tags for channel bumps: git apparently doesn't play well with that many tags
<andi->
and then you could see the different bumps in the history?
<samueldr>
(reportedly)
<MichaelRaskin>
andi-: then I could just apply commands on the channel branch, whatever I want
<MichaelRaskin>
And in the master history I would see that some commits are in multiple branches
<MichaelRaskin>
I think in git you could do a special branch with non-fast-forward merges
<samueldr>
I came to git after having used mercurial, it seemed like a downgrade (in ~2013)
<samueldr>
memory's fuzzy, but the main pain point being how the UX (git cli) was painful
<samueldr>
and still, I use it, and find it's painful
<MichaelRaskin>
It is separately funny that git fails at integrity
<andi->
the question is (not trying to defend git) what is the right amount of features you REALLY need for the average project? You will always find some use-case that isn't covered..
<MichaelRaskin>
Look, for a small average project you need more consistency and less scaling
<MichaelRaskin>
I.e. just use Mercurial and keep your sanity
<MichaelRaskin>
Nixpkgs is probably approaching from below the scale where git somewhat makes sense
<MichaelRaskin>
The fun story about git integrity: Linus Torvalds made git fast by carefully making sure that ext3 consistency guarantees allow to avoid fsync. Guess if the consistency guarantees git _currently_ needs hold for ext4, now that «almost nobody» uses ext3.
<samueldr>
MichaelRaskin: not that I doubt, but I'd like to read about that issue, I like a good scary story to tell around the campfire
<andi->
same :)
<andi->
sounds like a real scary to tell.. if your battery runs out while you do a git commit then...
<MichaelRaskin>
Well, for any merge strategy I can break it with a seemingly innocent history
<__monty__>
Still, that's not a reason to use a worse strategy.
<MichaelRaskin>
I would guess that the best strategy is full-lattice merge, but nobody will ever use it.
<MichaelRaskin>
Wow
<MichaelRaskin>
I looked up the discussion of that article on Mercurial mailing list
<MichaelRaskin>
First of all in the example from the article Git would pick a single ancestor.
<MichaelRaskin>
Hm, good argument: recursive merge is better when you have a complicated situation, but then you probably have conflicts, and then the user needs to understand recursive merge well…
<MichaelRaskin>
And it looks like «bid merge» does cover the comprehensible cases where recursive merge is an improvement
<__monty__>
I'm not sure I read the entire Hg mailing list thread because it's muy echo chamber.
<MichaelRaskin>
Later it turns out that the original article uses nonstandard edge directions for commit DAG.
<MichaelRaskin>
So it does mean a recursive merge…
<MichaelRaskin>
But in general I do buy the argument about conlicts (and bid merge probably is a nice compromise)
<__monty__>
See, the nagging about those edges is one of the things that turned me off of the thread. If you can't deal with a simple difference in convention then what business do you have coming up with graph algorithms?
<MichaelRaskin>
Sorrry?
<MichaelRaskin>
If you draw DAG edges in wrong direction, what business do you have going close to graph algorithms?
<MichaelRaskin>
I mean, inverting _all_ edges is fine, inverting _some_ is beyond good and evil.
<MichaelRaskin>
(I know, the people drawing the DAGs in a way that creates oriented cycles are not Git developers)
<__monty__>
It's completely clear why some of the arrows point the opposite direction even without reading about the author's convention. If you can't deal with that then I'm not confident in your abstract thinking skills.
matthewbauer has quit [Remote host closed the connection]
<__monty__>
The Hg responses are simply rude one after the other and it's clear the critics didn't even read the author's post. Up until I came across that thread I was kinda leaning toward Hg, now I stick with git hoping something better'll come along.
matthewbauer has joined #nixos-chat
<MichaelRaskin>
There is an upper bound how much a person can understand about graph algorithms before drawing DAGs with mixed directions stops being an option
<MichaelRaskin>
It is not a high bound
<__monty__>
This is clearly not going anywhere so I'll just stop. Goodnight.
<MichaelRaskin>
Goodnight
<simpson>
MichaelRaskin: FWIW I agree that the arrows matter. I'm imagining how little sympathy I'd get for making a mistake on a diagram like https://corbinsimpson.com/complexity.poset.png
<MichaelRaskin>
Well, people make mistakes, which is excusable and does not disqualify for sympathy. But harsh critique of an argument based on the arrows-as-drawn is also normal.
<MichaelRaskin>
I wanted to say you could add an arrow and see if anyone notices, but now I see there are even legal arrows you could add
<simpson>
Yeah, this is just the transitive reduction.
<MichaelRaskin>
I mean there are legal arrows not implied by the diagram
<MichaelRaskin>
Well, I checked the soft target first
<MichaelRaskin>
Which is trivial and boring
<MichaelRaskin>
Did you try scraping Complexity Zoo?
__monty__ has quit [Quit: leaving]
<simpson>
Yeah, but it's in human-readable form, so it's a manual task.
<simpson>
A non-trivial portion of *why* I'm doing this work is so that we have more machine-readable category information.
<MichaelRaskin>
HTML to text, then dump the lines with «contain» «inclu»
<MichaelRaskin>
Still manual work, but maybe a bit more efficient.
<simpson>
Heh. I like it. I'd really love to be able to split these all out into per-paper bits of results, now that I know that my automatic equality finder is working.
<MichaelRaskin>
Then again, what to do with NPI…
<MichaelRaskin>
As for the boring inclusion — I mean that you don't have a path from coNP, say, to PP
<MichaelRaskin>
By the way, is it intentional that the smaller classes are higher?
matthewbauer has quit [Ping timeout: 248 seconds]
<simpson>
I guess? I didn't really pay attention to the flags I gave to DOT. I just wanted to make sure that the arrows go the right direction.
matthewbauer has joined #nixos-chat
<MichaelRaskin>
Well, inverting 100% of arrows wouldn't be that bad