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 repositories.
On 8 April 2012 09:08, Brett Goulder <predatorfr...@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@gmail.**com<monster.roms...@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-1.0.24.1-1.0.25.**patch | 59 ++++++++++++++++++++++++++ >> opt/alsa-oss-1.0.17-1.0.25.**patch | 26 ++++++++++++ >> opt/alsa-utils-1.0.24.1-1.0.**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@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@lists.crux.nu > http://lists.crux.nu/mailman/**listinfo/crux-devel<http://lists.crux.nu/mailman/listinfo/crux-devel> >
_______________________________________________ crux-devel mailing list crux-devel@lists.crux.nu http://lists.crux.nu/mailman/listinfo/crux-devel
