Mageia forum

Hi all,

We are short on contributors, which is unbelievable, because contributing to Mageia is so great, so magical! Mageia is the most rewarding (not in money, of course ) project I've ever worked for.

About five weeks ago we tried to get our association members to do some brainstorming about how to increase the number of active contributors. There were too few replies, maybe because it was impossible to come with ideas anonymously, maybe because it hadn't been mentioned that whoever comes up with an idea, isn't automatically expected to implement it.

Anyway, if you have any ideas about how to find more contributors or revive "hibernating" ones, please say so and don't be shy.
If you prefer to give your ideas in private, just message me via this forum.

The ideas are meant to be added here: https://wiki.mageia.org/en/Brainstormin ... ntributors

Thanks for your help,
Marja

Is there an identified list of things that we most need contributors to do?

Well, basically contribute in at least one of the roles from https://www.mageia.org/contribute/ - there's not really some kind of fixed list
(apart maybe from QA / bug squad teams and those result from the reported bugs and QA update candidates)

But maybe I misunderstood your question ?

Well, if we are brainstorming about how to increase contributors, I would say that there are several things that would help.

• Demonstrate that contributing has tangible benefit to the community.
• Share details of what, specifically, help is needed with.
• Provide a clear path for getting involved.

I contribute to more than one Linux distro but reviewing the contribution link above provides no information that would make me want to get involved. That is just a list of the things that all distros need to operate. It tells me nothing about where Mageia most needs help and what needs to be done.

If we are trying to figure out how to increase contributors, I would speculate that we have contribution shortfalls that are either causing things to not get done in a timely manner, we are too much burden on a small group of people or both.

We must know the areas in which we most need to help and what needs to be done. If a list of priorities hasn't been developed yet, I would recommend creating one.

Thanks, dalto, your feedback has been added to the bottom of https://wiki.mageia.org/en/Brainstormin ... ntributors for now and may later be added to one or more sections higher up in the page.

Don't know about the availability of a Mageia-sub-reddit.
I guess many youngsters and (potential) Linux-enthusiasts would be found there.

There is one, but it's pretty inactive: https://www.reddit.com/r/Mageia/

Just adding a very personal point for view, but I think this might be the same for other people too.

In two situations I considered becoming a packager for packages I wanted in Mageia but weren't present. When I checked how to become one, I found so many constraints that I finally gave up. From the top of my memory, the only of those constraints I remember now is that packagers have to attend a meeting (I have more than enough at work) every Tuesday at a time I'm having dinner with the family or doing something else.

On the other side, I see the interest for Mageia of having such meetings, but it was not good for me.

I'm not criticizing. Just providing my personal experience.

I see from dev list (im not a packager but lurk there) that meetings have been scarse, and on list you can propose and discuss/vote for when next meeting to be held.
I am myself frequent in QA but have never been in our meetings... I use the discusison mail list, and meeting logs can be read.

Thanks a lot, all, for your replies. I'll try to integrate them into the wiki page asap.

Maybe you should really care about the ones that are really interested in contribute to Mageia. I literally got tired of trying to find a new mentor, few years ago Zezinho(who passed away) was mentoring me, and then I wrote in the list since I wanted to continue my path in becoming a packager. Got no response from users. So I guess delegate the labour of recluting people to this project might be a good start.

emel_punk wrote:Maybe you should really care about the ones that are really interested in contribute to Mageia. I literally got tired of trying to find a new mentor, few years ago Zezinho(who passed away) was mentoring me, and then I wrote in the list since I wanted to continue my path in becoming a packager. Got no response from users. So I guess delegate the labour of recluting people to this project might be a good start.

Hi emel_punk,

Thank you for your reply, I've added it to the bottom of the wiki page, to be merged later.
I do very much regret what happened to you. I see you here https://wiki.mageia.org/en/Becoming_a_M ... n_progress
Neoclust seems to be your new mentor.
Did you already do the next step, file a bug report? I did not manage to find you in https://bugs.mageia.org
Please read https://wiki.mageia.org/en/How_to_report_a_bug_properly before you file one.
Neoclust might be a bit less available now, I suggest you write a mail to dev ml with "[mentoring]" at the beginning of the subject line and ask for neoclust or another packager to review your bug report and add "done" to the related field in the apprenticeship table if it is OK

Thank you. Neoclust was assigned but I never got reponse from him, I guess he is busy. I will try to continue my path.

IMHO the key to increase the number of contributors is to increase the number of users.
If 100 new users finds a home in Mageia maybe 5 or 10 of these will become active contributors.
But nowadays a large portion of linux users doesn't even know of the existance of Mageia or that it's still alive.
So, always IMHO, it's needed to improve the communication and show to the world what Mageia has to offer and improve other technical aspects.
Mageia is a rock solid distro that embrace the "when it's ready" philosophy. That's a great thing but between two releases the software bacame dated.
One possibility is to use the backport repos populating it with packages from cauldron, even if these aren't deeply tested. Obviously this has to be done with those packages that are less prone to eat the user's hamster.
To do this adopt something like openQA from openSUSE or other tools that can increase the automation of the maintenance of the distro could be an idea.
Also I think Mageia should be as vanilla as possible and stick with upstream. This would improve the speed of updating the various packages as the time used for various changes would be decreased.
Another improvement based on what openSUSE already has could be something like Open Build System (OBS).
This would let users to create, and possibly maintein, their own packages and share them with the community in the easiest way possible.
A thing would be combine AUR (from Arch Linux) with OBS, a centralized repository populated by user-created packages using a system that assists them in building and maintaining these packages.
I know some of my words are the same reported here https://wiki.mageia.org/en/Brainstormin ... ntributors but i want to speak my mind with you anyway.
I started my Linux journey with Mandriva and I'd like to see Mageia flourish.
Thank you for your hard work.

Hi there,
nowadays since there is stuff like flatpaks and appimages easily available, I don't think backports from cauldron is the way to go.
Also, why would regular users care about "dated" software if it works?

Regarding OpenQA, I've worked on packaging that in the past and that wouldn't really help that much, as the overhead on operating the OpenQA server
and writing the tests and the screenshots required for the tests adds quite a lot of overhead. That might be feasible for a distro like OpenSUSE where
quite a lot of developers are employed and can work fulltime on this.

Regarding OBS, this is already possible via Copr, see https://wiki.mageia.org/en/Fedora_COPR

doktor5000 wrote:Also, why would regular users care about "dated" software if it works?

Because there are also users out there, which know the computer basics. They care about security and don't want to work with 2 years old apps with known vulnerabilities.
If you follow bugzilla closely, you will notice that the vulnerability monitoring and reporting seems broken. Compared to other distributions there are way less security issues reported in bugzilla. And don't draw the wrong conclusion. No, it is not because the used software versions in Mageia have less bugs or are secure by default...

doktor5000 wrote:Regarding OBS, this is already possible via Copr, see https://wiki.mageia.org/en/Fedora_COPR

No. This is not the same. You don't want users which adds additionally barely managed (unmaintained) stuff to additional repositories like with copr. You wan't to run the complete build process of the distribution on a modern, powerful, fast and well maintained platform like OBS. That means the build process and sources are transparent and accessible for every registered user. And every registered user can (as already explained by me in the wiki) do following:
"branch a package, apply fixes, update, test the build and submit the branched package via service request for review. The last few maintainers of Mageia can accept the service request, recommend changes or reject the request. This would ease the workload of the last few maintainers because they only would need to review the service request instead of doing all the packaging work alone. In this way, also packages without fixed maintainers would get updates and some attention."

The package building process, rights management and hardware of Mageia is heavily dated, ineffectiv and not open and transparent.
Unfortunately one of the last maintainers of Mageia is strongly against OBS (in my opinion because of lack of understanding what OBS is and what it does).

But whatever...
I contribute now to another distribution which uses OBS for the complete build process of the distribution. I fix broken builds, update packages, apply fixes for CVEs and so on. I do all stuff what is not possible with Mageia as long as you are no Mageia packager.
(I use another name there which has no connections to Mageia). It is easy to learn, fast to use, no local resources needed and much more. With that i can ease the job of the main maintainers (and get named in the changelog as goodie )

And guess what: no inefficient "becoming a packager" training like with Mageia necessary. This process is broken (as can be already seen in the wiki and here in the forum), as there are no packagers left which have time to mentor a new packager for months or years (besides the main job to mainatin several hundreds or thousends of packages...).


I started with Mandrake, used Mandriva and afterwards Mageia. I was a fan of it. But with that long usage you also know what is broken far beyond recognition. And to explain one of the reasons why i switched away from Mageia lets cite you once again:

doktor5000 wrote:Also, why would regular users care about "dated" software if it works?

Because it doesn't work. Mageia didn't work with my modern machine as the software is dated. That's why i switched to a better maintained distro. If you spend some € for an up to date machine and the distro is so dated and hold together by self written stuff (as example net_applet), you simply throw out the distro...even if you were a user for decades.

doktor5000 wrote:Hi there,
nowadays since there is stuff like flatpaks and appimages easily available, I don't think backports from cauldron is the way to go.
Also, why would regular users care about "dated" software if it works?

Because:
1) Flatpak and appimages aren't so wide spread, I mean not all the apps are packages in that way. Also containerized applications can give more problems than they solve (personal experience).
You have a whole repo called "backports" so I don't understand why don't use it.
2) Why nowadays the most used distros are those who embrace the rolling philosophy (Arch and its derivatives, openSUSE Tumbleweed, ecc.) and who has up-to-date software in their repos (Fedora)?
The reason is regular users actually care about "dated" software. New software brings new features, fixed security issues and so on...
It's about the freedom of choice, connecting me to the idea of using the backports repo more a user can choose to stay with the core repo and have rock solid packages or upgrade the system with the packages of the backport repo and still stay safe with a system that won't break down.
Also you can integrate snapper so if something goes wrong you can easily recover your system.

doktor5000 wrote:Regarding OpenQA, I've worked on packaging that in the past and that wouldn't really help that much, as the overhead on operating the OpenQA server
and writing the tests and the screenshots required for the tests adds quite a lot of overhead. That might be feasible for a distro like OpenSUSE where
quite a lot of developers are employed and can work fulltime on this.

openQA was just a suggestion, different tools can be used to get to the same result.
The important thing now is to find a solution to automate as much as possible the process of packaging and maintaining the packages in the repos.
This is with the aim of taking some weight off the shoulders of developers and packagers.
Also it's vital to make easier became a packager so if you have a tool that verifies the degree of goodness of the work this would make it easier for everyone, and not by a little.

Other cool tools are "autospec", "autodist" and "distromatic" from openmamba.
Openmamba is an italian distro, based on rpm and dnf as package manager, with a good amount of packages really well maintained and its team is very small.
The development of openmamba consists primarily of packaging software components from archives that contain the source code (often tar.xz,tar.bz2 or tar.gz format) publicly available on websites that host open source software such as sourceforge.
To make it easier for developers to create rpm packages is used autospec. It offers a dozen operations to be performed sequentially either manually or automatically with the aim of simplifying the process of creating and updating individual software components.
Following in the footsteps of autospec has been developed autodist, that aims to automatically manage an entire repository using autospec in batch.
In the end, the control and the database of the distro is managed by distromatic, that checks for correct dependencies and provides detailed information on each repository.

The semi-automatic openmamba build system:


Also in 2012, a web interface for developing and maintaining openmamba called Webbuild was created.

doktor5000 wrote:Regarding OBS, this is already possible via Copr, see https://wiki.mageia.org/en/Fedora_COPR

IMHO what has permitted the miracle of the Chinese economy was their ability to gain the "know how" copying others but making their own.
I understand that reinventing the wheel is not always the best thing but copr it's the solution to all the problems of lack of software.
When I was using Fedora I really found copr packages poorly maintained and the repos management a real mess.
Multiple copr repos for the same package but with different versions, one more updated, one less updated and one with just the alpha version of that package.

Also to use copr on Mageia you have to use dnf.
Put yourself in the shoes of a new user, you don't know the OS and you find:
- 2 methods for managing software with a GUI (rpmdrake, kde discover/gnome software);
- 2 methods for managing software with the terminal (urpm* and dnf);
- to use copr I have to use dnf.

I think it could be a little overwheling.

After all of these words the biggest stumbling block to be addressed and overcome as soon as possible is given on the page https://wiki.mageia.org/en/Brainstormin ... ntributors
under the heading “Evolve faster”:
<< Some have proposed things to improve the look of the distribution, but they quickly stopped because they felt that we did not like breaking our habits and that ultimately we did not want to evolve. >>
Everything on that page is shareable but I think that last sentence encapsulates a lot of meanings.