[crux-devel] Encouraging CRUX community efforts to support CRUX developers.

Brett Goulder predatorfreak at dcaf-security.org
Sat Apr 7 23:08:15 UTC 2012

On 04/03/2012 11:53 AM, Emmanuel Benisty wrote:
> Hi Danny and list,
> On Sun, Apr 1, 2012 at 7:01 PM, Danny Rawlins<monster.romster at gmail.com>  wrote:
>> On 01/04/12 21:07, Emmanuel Benisty wrote:
> [---snip---]
>>> If some ports are behind the latest versions, I would imagine that's
>>> because CRUX is lacking manpower. On the other hand, I understand that
>>> CRUX can't accept any random user as a developer. Most of the time,
>>> I've been updating ports by myself, on my machines, but I think it's
>>> rather sad that 1. it can't benefit the whole community 2. it's a
>>> duplicate effort as sooner or later, the official maintainer will
>>> update those ports. I've been posting few patches on IRC or sometimes
>>> sent them to maintainers by email but that is not always efficient
>>> because if you're too busy to update your ports, you're most likely
>>> too busy to review others' patches too. So I've been thinking about
>>> the following:
>>> What would you think about the creation of a community-patches-queue
>>> git repo accessible by, well, CRUX community. This is how it could
>>> work:
>>> 1. User U has updated port P on his machine, he would then commit a
>>> diff patch to community-patches-queue (we could also make a ports repo
>>> out of it and encourage people to use and test those ports but that's
>>> another story)
>>> 2. One (or more?) CRUX developer, available at that time, would
>>> volunteer to review and sign-off the patch.
>>> 3. Signed-off patches are sent to the official maintainer (or
>>> committed to community-patches-acked) so he could review and apply
>>> them or just apply them with peace of mind if he's too busy to review
>>> them fully (or even let other devs apply them?)
>> I have done something smiler recently I forked the xorg repository and
>> updated nearly everything except a couple of ports that would break
>> things, if I post the site here it'll get this email spam filtered, it's
>> been on jaegers irc log a few times. I've thought of doing the same for
>> opt and perhaps contrib, but I would only be bumping stuff that I would
>> be confident to do so.
>> I am in opt so I guess I am a dev now, I would welcome some system
>> system for more community involvement.
> Thanks for your informative reply. The main difference is this would
> be open to random users (i.e. trust level of zero) - as opposed to you
> being a CRUX developer - hence the sign-off process proposal.
> I've created a repo and slowly started to add some patches. Anyone
> willing to join, please let me know your github username or repo to
> pull from.
> https://github.com/horrorStruck/community-patches-queue
> or
> git clone git://github.com/horrorStruck/community-patches-queue.git
> what's in there so far (not much):
>   opt/alsa-lib-   |   59 ++++++++++++++++++++++++++
>   opt/alsa-oss-1.0.17-1.0.25.patch     |   26 ++++++++++++
>   opt/alsa-utils- |   27 ++++++++++++
>   opt/gtk-2.24.8-2.24.10.patch         |   54 ++++++++++++++++++++++++
>   opt/pango-1.26.2-1.28.4.patch        |   76 ++++++++++++++++++++++++++++++++++
>   opt/syslinux-4.04-4.05.patch         |   62 +++++++++++++++++++++++++++
>   opt/wireshark-1.6.4-1.6.6.patch      |   50 ++++++++++++++++++++++
> Lastly, if you think this is just wasting bandwidth and spamming your
> inbox, don't hesitate to let me know.
> Cheers,
> -- Emmanuel
> _______________________________________________
> crux-devel mailing list
> crux-devel at lists.crux.nu
> http://lists.crux.nu/mailman/listinfo/crux-devel
Hello Folks,

It's been a long long time since I've posted here, but I figured I'd 
chime in here. I've basically had to give up using CRUX because it 
became too much work on my own part to maintain my CRUX systems, and I 
often don't have the time do that between work, school and real life 
stuff. Part of the issue that forced me to give it up was exactly the 
issue under discussion: duplication of work due to out of date ports.

A lot of the CRUX developers/maintainers are overloaded, making it hard 
to track every piece of software they are in charge of. The general 
solution Emmanuel proposed is definitely a step in the right direction, 
but it would be far better to leave this as a normal git repository. 
It's pretty easy to do merges with git, and that would allow it to 
mostly be a "review differences, merge into main repository" work flow. 
Obviously, this is all outside observation and I'm pretty far removed 
from the hands on day-to-day activity of CRUX, but a lot of these 
problems aren't new (heck, this issue was present when I began using CRUX).

Best Regards,
Brett Goulder

More information about the crux-devel mailing list