joerg | could you place the pad URL into /topic please? | 13:18 |
---|---|---|
joerg | or just paste it again so somebody else may add | 13:19 |
bb|hcb | sure: https://pad.dyne.org/pad/#/2/pad/edit/YTdxkNKr+GtEbedK6jGeWwG2/ | 13:20 |
joerg | also a link to some website, forum or mailinglist-archive related to the topic would be great :-) | 13:20 |
joerg | bb|hcb: I did a few minor edits to the pad, you might want to update github | 13:47 |
joerg | sorry, inline edits are hard to tag with ((name)) | 13:48 |
joerg | my edits were only in "ADOPTION NOTICE (2021-09-14)" (the italic text) | 13:49 |
joerg | plus a <strike> a few lines later | 13:49 |
joerg | golinux: isn't there a "history" with timeline to scroll along, in dynre pad? | 13:50 |
joerg | "getting started..." suggests "you can use 'history' to view edits..." - alas I don't find that symbol/button | 13:53 |
joerg | AAAH in *** menu | 13:54 |
bb|hcb | Yep, its a little hidden; I have applied the change: https://github.com/eudev-project/eudev | 14:01 |
joerg | :-) | 14:02 |
bb|hcb | I have tried couple of approaches to do automation to help with merging the changes from udev, including git log -p and parsing the output to produce list of udev related commits (I know this excludes the changes in the copied library functions). | 14:13 |
bb|hcb | But from what I see the codebases have diverged too much; also the commit count is crazy high. Maybe the good old two-way visual diff file by file can be used to produce a saner set of PRs... What do you think? | 14:14 |
Arsen | bb|hcb: https://git.sr.ht/~arsen/eudev-new/tree/master/item/tools/systemd_upstream_filter.py | 15:03 |
Arsen | this will leave you with only files in REMAP_FILES and KEEP_EXACT_PATH | 15:03 |
Arsen | it might take up to an hour to run though | 15:03 |
Arsen | as you might imagine, filtering down that big of a history takes a bit | 15:04 |
joerg | forwarded from obsolete legacy channel: | 15:07 |
joerg | [16 Sep 2021 13:43:41] <blueness> not so much tired as my life situation changed and i was the only guy doing this. mostly since 2017 eudev didn't need much work | 15:08 |
joerg | [16 Sep 2021 13:43:58] <blueness> proof of that gentoo | 15:08 |
joerg | [16 Sep 2021 13:44:32] <blueness> very few bugs, people only said "its dead" because there were few commits, but i'm not going to commit just for the sake of committing | 15:08 |
joerg | [16 Sep 2021 13:45:04] <blueness> the task now for the new eudev team is to just re-calibrate and do the same | 15:08 |
joerg | [16 Sep 2021 13:45:30] <blueness> the only thing that i know of that eudev fell behind on was parsing the rules, and it was just this corner case | 15:08 |
joerg | o/ fsmithred :-) | 15:11 |
Arsen | yeah, people tend to think "wow no commits" and presume dead on a feature-complete project with no known bugs | 16:06 |
Arsen | it's a pet peeve | 16:06 |
fsmithred | hi joerg. I'm here to watch it happen and also as a crash test dummy. | 16:19 |
skarnet | Arsen: cool, we share a pet peeve :) | 17:07 |
Arsen | :D | 17:13 |
bb|hcb | Arsen: that is nice, but I do not think that blindly merging changes will yield any good :( | 17:20 |
Arsen | who said anything about merging them blindly | 17:20 |
Arsen | plus, that's an effective strategy as long as it works, in terms of compatability | 17:21 |
bb|hcb | :))) And that is the problem, because they are way too many. What do you think about diffing files? | 17:21 |
Arsen | git diff systemd/main -- <pathspec> | 17:23 |
Arsen | and no, there's relatively few of them | 17:23 |
Arsen | I lost the exact count because I was testing this on a ramfs (I have more physical memory than disk space right now) but it was in the low thousands | 17:24 |
Arsen | 2276 | 17:25 |
Arsen | though, that count is from a msg before I included hwdb files | 17:25 |
bb|hcb | 2276 commits? Did you count how many -/+ per commit? | 17:30 |
bb|hcb | If they are small ones (like couple of hunks with couple of lines changed each) it's would not be that bad (actully I didn't see a huge one yet) | 17:31 |
bb|hcb | s/it's/it | 17:34 |
Arsen | I did not, but it's fair to assume that the last 365 days alone of backhistory suffice, as we know systemd-udevd works fine for Gentoo right now, without systemd | 17:37 |
Arsen | so we *could* fork at the current point and further merge or reject patches as need be | 17:37 |
skarnet | for Alpine, getting rid of the glibcisms is important, so that's a set of patches that should be reapplied immediately | 17:42 |
Arsen | absolutely | 17:43 |
Arsen | same for managarm | 17:43 |
bb|hcb | Agreed, but we may miss some small detail. eudev also works in ALT, antiX, Crux, Devuan, Guix, Slackware, VOID and maybe others; I am using eudev on Devuan and it works well | 17:44 |
Arsen | what kind of small detail are you expecting | 17:46 |
bb|hcb | I have seen lots of whitespace/code beautify changes; maybe it will be better to merge them, so the code diverges less | 17:46 |
bb|hcb | Also there is the other proposed approach - redo the fork based on what we have in both repos, but I doubt that there will be issues in the result | 17:47 |
bb|hcb | So what you say above+review would be best, but there is one problem with that - correlated changes - it will be a nightmare to group the changes in semantically sane PRs | 17:49 |
bb|hcb | OTOH if we split those in (e.g. 20 commits per PR) then the whole set should go all in or all out, we can't merge PR by PR | 17:50 |
Arsen | hm? | 17:50 |
Arsen | what would a PR do | 17:50 |
bb|hcb | Allow others to review | 17:50 |
bb|hcb | And the bigger the PR, the harder to say GO/NO GO | 17:51 |
Arsen | not really | 17:51 |
Arsen | the only thing that should really matter is the latest revision of the source branch | 17:51 |
Arsen | if it works for us after applying fixes for glibc-specific functions and similar issues, we should just merge that | 17:51 |
bb|hcb | You mean to squash all the history and merge the result? | 17:51 |
Arsen | no, no squashing is needed | 17:52 |
Arsen | if we squash we lose the ability to merge from the potential filtered middle repository | 17:53 |
bb|hcb | i misunderstood. please explain | 17:54 |
bb|hcb | i agree that its better not to squash; explain your proposed model (you alredy have been there) :) | 17:54 |
Arsen | alright, filter down the upstream repo, grafted at a certain commit (I picked a point roughly a year ago that includes at least one release following that commit) to get a history of only recent udev-related changes, then continuously update that (yet to make updating that work though with the filter efficiently), and git merge (--allow-unrelated histories only the first time) that filtration result | 17:56 |
Arsen | that way we get a history directly linkable to upstream, to solve any attribution issues, and a relatively maintainable way to stay up to date | 17:56 |
bb|hcb | How do you manage files that moved around? | 17:57 |
Arsen | hm | 17:58 |
Arsen | I'm sure git thought of that already in the recursive merge strategy | 17:58 |
bb|hcb | Most of them are not in the same place in both repos | 17:59 |
Arsen | wait, wdym | 17:59 |
bb|hcb | I am not sure, if there is a commit moving the file, then it will know, but if there isn't then I do not know what will happen | 18:00 |
Arsen | well, all changes to the src/{lib,}udev subtrees would've been kept | 18:01 |
Arsen | so if a file is moved the commit that did it is there | 18:01 |
bb|hcb | hm. that may work, lets try? | 18:06 |
Arsen | well I did :P | 18:06 |
Arsen | though I'm not home so I'm not keeping that up to date right now | 18:07 |
Arsen | it requires more memory than my cheapo vps can handle | 18:07 |
bb|hcb | I have some ram, but I have to go shortly | 18:21 |
bb|hcb | Let us know when it happens, so we can discuss how to proceed with it | 18:27 |
Arsen | well it already did, it's just slightly out of date | 18:38 |
Arsen | https://git.aarsen.me/systemd-udevonly.git/ | 18:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!