<cole-h>
qyliss: 'Google have a tool, called "repo", for...' -> should this be `Googlers have` or `Google has`?
<qyliss>
No, that's just British English :)
<cole-h>
x)
<Irenes[m]>
when we want to explain plural pronouns (cf. pluralpride.com) we sometimes make reference to that British English thing lol
<cole-h>
Irenes[m]: Hey, I see your name on there :)
<Irenes[m]>
indeed :)
<cole-h>
qyliss: Are your crosvm changes planned to go upstream ever?
<qyliss>
that's complicated
<cole-h>
Just wondering how, if I were to contribute to cros, the CLA situation would be handled in the case that you will eventually send things upstream
<qyliss>
I don't like that upstream has a CLA
<cole-h>
Right
<qyliss>
Which is why I have not yet submitted anything upstream
<qyliss>
But, from what I've read, Google will accept patches containing other people's code as long as the licensing is clear.
<qyliss>
Why they can't accept that for your own code I don't know.
<cole-h>
lol
<qyliss>
I doubt any significant Spectrum changes will ever be upstreamed, fwiw.
<qyliss>
They're too specialised.
<qyliss>
The things I could upstream are smaller changes.
<Irenes[m]>
I can answer that. I mean, not definitively, but I am confident of the answer. They are jerks and want to own the code if there is any possible way to achieve that, and most people will simply follow restrictive rules like that.
<qyliss>
The CLA is fairly decent, as CLAs go.
<qyliss>
But it's still a CLA.
<Irenes[m]>
yeah
<Irenes[m]>
I mean, they wouldn't sign it if it were somebody else's
<Irenes[m]>
no reason you should sign theirs
<qyliss>
I'm a little worried that might strain relations with them
<qyliss>
But I haven't had to make a decision either way so far, so I'll just stick with that as long as I can.
<Irenes[m]>
they aren't a monolith. the developers and the IP lawyers are two different teams.
<qyliss>
Yeah, I understand. But developers can still get annoyed at legal things getting in the way.
<Irenes[m]>
very fair
<qyliss>
And since the CLA isn't actually all that bad, all told, I can easily see it looking like I'm the problem.
<Irenes[m]>
sure
<cole-h>
btw Irenes[m] thanks for that link -- I've bookmarked it for when I'm of more sound mind... :P
<Irenes[m]>
for sure!
<qyliss>
I was fortunate enough to have a very patient plural twitter mutual a long time ago
<Irenes[m]>
:)
<tazjin>
Irenes[m]: Google signs other CLAs frequently and this is even documented in the public open source docs
<tazjin>
Emacs is one example of something with a fairly intense CLA that Googlers can contribute to
<Irenes[m]>
their willingness depends on the CLA and the project license
<Irenes[m]>
I got them to sign one once but it was one of the easy cases
<qyliss>
I suspect at some point I well sign the Google CLA
* Irenes[m]
nod
<qyliss>
I don't think it's bad enough to be worth trying to go around it
<qyliss>
But right now I don't really have anything worth upstreaming, I think.
<qyliss>
The reasons I have for disliking the Google CLA are pretty technical and in practice probably irrelevant.
<qyliss>
So I don't think I'd avoid trying to upstream something over it if there was anything that actually seemed worth it.
<qyliss>
It is enough to have put me off trying to upstream minor changes, though.
<tazjin>
I've made people hand me their copyright for contributing to my projects before, I don't really get why this is controversial
<qyliss>
if there's some issue that would stop somebody using my code, I'd rather fix that for everyone, rather than just Google.
<qyliss>
Most of the time, CLAs are copyright assignments paired with the GPL. Which is quite an unfair imbalance.
<qyliss>
The Google one isn't like that. It's mostly a restatement of the apache license.
<Irenes[m]>
yeah I believe their main concern is patents
<qyliss>
So the problems with it are, as I said, minimal
<qyliss>
It's just a hurdle that I haven't been sufficiently motivated to jump over yet for my small changes
<qyliss>
Irenes[m]: one thing I do dislike about the Google CLA with crosvm is that contributors have to grant Google a patent license, but afaik Google doesn't grant me one.
<qyliss>
Again, a technicality, because I don't hold any software patents, and I never will.
<Irenes[m]>
makes sense.
<MichaelRaskin>
I would not be so flat-out sure you will never _hold_ a software patent, although you enforcing a sotware patent against any codebase is unlikely.
<qyliss>
mmm, I certainly _hope_ I never hold a software patent
<Irenes[m]>
right like, I see ideological factors there for sure
cole-h has quit [Quit: Goodbye]
<MichaelRaskin>
I can imagine too many stupid situations where holding software patent gives some benefit for absurd procedural reasons even if the patent is intentionally made unenforceable.
<Shell>
MichaelRaskin: qyliss is very ideologically opposed to holding software patents, enforceable or not, for a number of different reasons.
<MichaelRaskin>
True, but invalidating bogus patents (not only in software) is stupidly hard, so if patents ever get fast-track recognition as prior art the defensive value might be hard to pass up. Although I definitely share _hoping_ not to be in a situation where doing this is worthwhile.
* Shell
shrugs.
<Shell>
I'm fairly sure she'd be happier being on the run from a judgement than owning a software patent, from what I know of her. :)
<MichaelRaskin>
What about filing a completely bogus patent application as pentesting? (And failing to write an application bad enough to be denied)
<qyliss>
fwiw, as I understand it software patents are not recognized in the European Union
<MichaelRaskin>
It looks like one can get a software patent but not enforce it.
<qyliss>
Sure, of course you can
<qyliss>
Like you can develop nuclear weapons and not use them
<MichaelRaskin>
No, I mean EU software patents exist
<qyliss>
Oh, right, yes, they take registrations.
<MichaelRaskin>
(but are not enforceable inside EU)
<edef>
qyliss: i use lieer with gmail
<edef>
qyliss: which you can hook into msmtp
<edef>
qyliss: i'd like to do better than lieer but that's like, Actual Work
<edef>
qyliss: basically, lieer syncs my mail into notmuch, and also happens to acquire an OAuth token for that
<qyliss>
Ah, that's a thing for pulling mail, rather than sending?
<edef>
qyliss: and i grab that out of the lieer state with jq in my msmtprc's passwordeval
<tazjin>
edef: are you using my lieer patch to request the right scopes?
<edef>
tazjin: yes
<hyperfekt>
wtf i didn't know kvm supported live migration? does that mean if we play our cards right we can adapt spectrum into a distributed OS with actually viable amounts of effort?
<hyperfekt>
<edef> you can just batch-create those and later fire them up, and they would compress fairly well against each other
<hyperfekt>
this is what attempts to bring aslr back to android apps do i think
<Shell>
... in theory. all the bits around spectrum-crosvm would need to support live migration as well, e.g. porting over all the file handles the vm has open, etc
<Shell>
VM live migration isn't actually the hard part, it's making sure the environment around the VM looks exactly the same once it's migrated. even in normal VM setups, just doing this for networking is a slight pain.
<hyperfekt>
qyliss: how does licensing patches in open source generally work if there's no CLA? does sending a patch to a project under a license imply that license for the patch?
<qyliss>
Yes
<qyliss>
(But double check with your lawyer)
<hyperfekt>
because technically a repo is a derivative work, but i could theoretically send patches without ever using the repo to create them...
<qyliss>
Sure, not every patch is a derivative work
<qyliss>
But whether something is a derivative work is only relevant if you're dealing with the GPL
<qyliss>
The reason that sending a patch to a project implies the same license is because that's what the convention is, AIUI
<hyperfekt>
ah, that's what i was wondering
<qyliss>
In the kernel and some other projects, they make this explicit, without a CLA
<hyperfekt>
there are a bunch of cases where something being common sense and practical effects the copyright situation but it's almost impossible tot ell where that is the case
<adisbladis>
Don't try to apply common sense to copyright law
<hyperfekt>
qyliss: oh, TIL. i never looked into that term and just assumed it was if someone was submitting a patch for someone else and putting their name behind the contents because they reviewed them and approve
<hyperfekt>
adisbladis: yeah i don't. but courts which is where it gets confusing
<hyperfekt>
Shell: my understanding is it would mostly be a matter of tunneling to the correct machine at the VM/provider interface
cole-h has joined #spectrum
multi has quit [Quit: bye]
multi has joined #spectrum
<qyliss>
Okay, I'm gonna make cgit do tarballs, then order a server upgrade
<qyliss>
Kinda digging having a maintenance day. Nice change of pace.
<cole-h>
Is that gonna go in this week's update? :D
<qyliss>
Yep :)
<qyliss>
And you're getting a special shoutout too
<MichaelRaskin>
… we definitely need an enshrined workflow that includes committing everything that ever goes live for more than 5 minutes, and then a later cleanup
<qyliss>
I have this for new changes
<qyliss>
mailing lists are back
maxdevjs has joined #spectrum
<hyperfekt>
qyliss: there has to be a good workflow for in-progress stuff with git
<hyperfekt>
MichaelRaskin: ideally committing is what makes it go live, and testing happens somewhere else, no?
<MichaelRaskin>
Ideally testing happens after committing.
<qyliss>
fwiw, this isn't a big deal because I copy the whole tree into the build system
<qyliss>
so even if I delete the git repository I still have everything
<MichaelRaskin>
And
<MichaelRaskin>
I guess it accumulates in the store
<qyliss>
Yeah, but not too much because of hard linking
<Irenes[m]>
right so I mean I would generally suggest having both the production and the testing versions of things checked in
<Irenes[m]>
which with git means different branches
<MichaelRaskin>
So Nix can be a reasonably efficient VCS?
<Irenes[m]>
that way there's a record of what was tested
<qyliss>
MichaelRaskin: good enough
<Irenes[m]>
I've been thinking about trying to formalize some auto-pull infrastructure that can also always roll back to prod...
<Irenes[m]>
haven't done it though
<MichaelRaskin>
Hmmmmm. And nix-serve / nix-copy-closure could serve as clone.
<MichaelRaskin>
I guess some use of multiple outputs and symlinks could allow both shallow and narrow checkouts…
<hyperfekt>
what is adding a commit to the head of a branch called? is it pushing? i guess i don't think of it as pushing because it happens on Github as a PR so often
<Shell>
hyperfekt: committing
<Shell>
if you then push your new branch pointer to a server, that's pushing
<hyperfekt>
so it is committing even if i don't make a commit at that point
<Shell>
?
<hyperfekt>
say i have branches trunk and feature
<hyperfekt>
i've branched feature off of trunk, i commit on feature, i merge that into trunk, but no merge commit is made because it's fast forwarded
<hyperfekt>
i have now changed the head of trunk without committing on trunk
<Shell>
right, so that's just a merge
<Shell>
I imagine the generic term for pointing the head of a trunk to somewhere new would be something like "reset", given that's the command which does just that? but that's just gonna confuse people :p