Tom Wijsman posted on Sat, 07 Jun 2014 20:19:20 +0200 as excerpted:

> The OpenRC project appears less active these days than it used to be.
> 
> There are many commits per month the last years, but the amount of
> commits in 2014 per month has noticeably decreased to a crawl [1].
> Alongside that, there appears to be around ~100 bugs open for OpenRC [2]
> on Gentoo Bugzilla; some of which are left without a response.
> 
> This gives the impression that the development of it is slowing down.
> 
> Worth noting is that WilliamH recently had problems with his system, we
> have since not seen him on IRC for almost a month; so, this can for a
> part explain the last month of inactivity.
> 
>  [1]: Short log of proj/openrc history, decreasing commits in 2014.
>  http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=shortlog
> 
>  [2]: Overview of bugs that involve OpenRC, most for the package itself.
>  https://bugs.gentoo.org/buglist.cgi?quicksearch=openrc

Also worth noting.

For several years I was one of the few users (where gentoo devs count as 
users too) running live-git openrc-9999 and reporting issues, a 
significant number of which were fixed before they made it into a release 
at all.  Filter bugs on ALL sys-apps/openrc-9999 and take a look[a], 
there's others reporting issues early on, but since 2010, all but two of 
the bugs are mine, the two being the latest bug, filed and fixed in mid-
January, and one from 2013 that's actually a feature-request to duplicate 
git-log functionality in a changelog that was RESOLVED/WORKSFORME.

But I recently took the plunge and switched to systemd.  Given the bug 
history, that very likely means there is now almost almost *NO* one doing 
pre-release testing and bug-filing on live-git openrc-9999!  For openrc 
users and supporters[b] that could/should be quite an alarming danger 
sign!

For gentoo users/admins that are reasonably good in shell but don't 
really do C/C++ or even perl/python/etc, because so much of openrc is 
effectively shell scripts this is a rare opportunity to actually read 
code and very possibly contribute real patches, not just report bugs that 
otherwise there's limited opportunity to actually participate in fixing! 
=:^)

The biggest problem from my perspective as an openrc tester was (as 
bernalex already mentioned in a more general context) lack of 
documentation on the openrc-specific commands/shell-vars
called/used from what is otherwise effectively shell code.

Some of the vars are/were documented as part of the runscript (8) manpage, 
but for the commands, generally symlinks to the (single executable, multi-
call) executable itself, the only documentation I could find is that 
available from their help option, which is slightly inconvenient to get 
since these executables are considered openrc internals and are thus not 
exposed from the standard $PATH var.  I had filed a couple bugs [c,d] on 
this too but recently closed the commands bug [c] with a note that I'm on 
systemd now and thus couldn't really test documentation anyway, but that 
the bug could be reopened if anyone else was interested.  Williamh closed/
fixed the vars bug [d] back in January, but I didn't really look too 
closely to see how well the new documentation works as I switched not 
long after.

So anyway, "position open" for live-git openrc tester.  And should 
someone familiar enough with the openrc-internal commands to document 
them wish to do so, it would surely help anyone volunteering for that 
open position. =:^)

---
[a] 
https://bugs.gentoo.org/buglist.cgi?cmdtype=runnamed&namedcmd=openrc-9999

[b] While I'm no longer a user (except technically on one old system that 
I don't keep current) I still consider myself a supporter.

[c] Commands bug: https://bugs.gentoo.org/show_bug.cgi?id=489356
sys-apps/openrc many helper command symlinks undocumented

[d] Vars bug: https://bugs.gentoo.org/show_bug.cgi?id=489344
sys-apps/openrc RC_* vars undocumented in runscript (8)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to