Alexe Stefan <[email protected]> writes: > It seems like the discussion got way off-topic. > To see where where at, I'll try to summarize what was said so far. > > The claims are that eudev is unmaintained upstream, downstream and has > open bugs. > Upstream, last commit was 3 weeks ago.
Please, take into account the contents of said commits. One of the more recent ones bumps the version in the .pc file while /stubbing/ only one of the APIs versions up to and including that one added. I've originally advocated for keeping eudev, and have put in some effort to restart the project by essentially reforking systemd 'today' (i.e. at the time a few years ago). Since then it has been effectively demonstrated to me that there is no interest in doing that (which is, mind you, the only viable path for remaining compatible. Note that competition here is perfectly useless, so staying compatible is the only viable path for the existence of the project *at all*); as a result, I began to lose motivation to continue, combined with being quite busy that year, I ended up simply switching to systemd-utils[udev], which was equivalent, except up-to-date, without ever finishing extracting/porting the needed shared code. The merge-base (which is a rough measure but it provides a time frame) of eudev and systemd is from Nov 2012, since then, only 1.3k commits were added to the eudev tree (as opposed to the systemd tree, where 57.5k commits were added, note that not all of those, or even many of those, are udev-related, but many are shared code between udev and other components). On top of that, only 143 of those were added to the repository since Gentoo stopped maintaining eudev. I estimate ~800 commits were added to systemd's udev since the eudev project got separated (and then eudev was already trailing long behind!), without counting shared code, so it's clear that eudev is failing to keep pace, let alone catch up I agree that upstream is alive. That's what life support is. > Downstream, Orbea said he is willing to help maintain it. He is known > for his great work on libressl(thank you), so there should be no > problems here. LibreSSL is an excellent example of a fork that is only useful if it remains compatible failing to be useful because it fails to be compatible. Thank you for bringing it up, it is quite a good cautionary tale. (naturally, I also used that back in the day...) > Most of those bugs are invalid, outdated or being worked upon. > > Are there any other problems here? The approach of forking in the traditional sense is fundamentally flawed here. If you want to keep eudev alive, please, do us all a favor and give upstream a hand at re-forking systemd, and finding a sustainable approach for keeping the fork up-to-date. I originally did this by filtering down the systemd repository into the appropriate directory structure, and then adding in a new build system and extracting the shared code. The filtered repository can then be used as a branch or separate repository that's merged into the new build system (either as a subtree or as the toplevel). This should have kept most of the code easy to update. PS: I had decided to respond to ~5 emails in this thread, but I realized that the answer to all of them would be exactly what I wrote here. This thread feels like a lot of repetition. Have a lovely day. -- Arsen Arsenović
signature.asc
Description: PGP signature
