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

Lucas Hazel lucas at die.net.au
Mon Apr 16 03:01:38 UTC 2012

What Brett has mentioned is a common theme. Many people get maintenance
burn out, the same thing happened to me trying to maintain a multilib
version. The one problem that has always persisted in the CRUX community is
the lack of man power to maintain ports. I think making it easier for the
community as a whole to maintain ports would be of great benefit. Has there
been any consideration to moving the git repos to a more social platform
such as github, or a self-hosted solution such as gitlab? This would make
it easier for the community to push change requests to the official

On 8 April 2012 09:08, Brett Goulder <predatorfreak at dcaf-security.org>wrote:

> 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<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<https://github.com/horrorStruck/community-patches-queue>
>> or
>> git clone git://github.com/horrorStruck/**community-patches-queue.git<http://github.com/horrorStruck/community-patches-queue.git>
>> what's in there so far (not much):
>>  opt/alsa-lib-**patch   |   59 ++++++++++++++++++++++++++
>>  opt/alsa-oss-1.0.17-1.0.25.**patch     |   26 ++++++++++++
>>  opt/alsa-utils-**25.patch |   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<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
> ______________________________**_________________
> crux-devel mailing list
> crux-devel at lists.crux.nu
> http://lists.crux.nu/mailman/**listinfo/crux-devel<http://lists.crux.nu/mailman/listinfo/crux-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.crux.nu/pipermail/crux-devel/attachments/20120416/aeac5bd8/attachment.html>

More information about the crux-devel mailing list