my name is suraj patil im a newbie to the open source world. im very passionate and enthusiastic person to work with the fedora and open source
i want to add one blog regarding how to use ll (long-list) command please help for this
warm & regards
Hi, I am Alain, FAS: avigne
As discussed today in #fedora-devel, here is some feedback about my
experience trying to join Fedora as a contributor -> packager.
TLDR: Adding a new package and become a Fedora packager is NOT easy.
I am not a computer scientist, but as an Integrated Circuit designer, I am
using eCAD proprietary tools heavily.
With my years of experience, I came up to know how to use Fedora, and I
like this distro because it is reliable, and fairly up to date with
When Fedora FEL spin was alive, I picked up some tools, and slowly learn
how to use them. gEDA, PCB, NGspice, GerbV, etc...
At some point, 2 years ago, I thought Open Source world gave me a lot, it
was time to give back... So I contacted the pcb-rnd project , and
started to contribute code around GTK, and GUI aspects of the application.
Naturally, as I am developing with a Fedora system, I thought it could be
nice to have pcb-rnd for Fedora... I had no clue on how to proceed, and
first, I tried to find someone who can do that for me...
Found no one. (I should have known :).
Time passes by, and one day a pcb-rnd Mageia contributor showed me the
.spec file he wrote for Mageia. I was curious about what was behind all
those commands and how this "recipe" (the .spec file) can lead to a package.
So I dug into the documentation (mainly Fedora wiki) learning how to first
build an RPM, then after a successful local "mock", my curiosity was
satisfied. I thought I understood the purpose of those tools (rpmbuild,
That is when I started to think about contributing this package to Fedora.
"It should be easy, I have the recipe, I just need to find where to
check-in the .spec file..." Easy thought, no ?
Unfortunately, no, this is not easy.
First, there are tons of pages describing the process, and what to do. In
theory the process is well described.
In practice, I got stuck in the "need a sponsor" phase where I think there
is kinda chicken-and-egg problem for a new contributor.
I might detail that, later, if someone is interested in this list.
My feeling today, 6 months after I jumped in the unknown is not very much
I had to register, open accounts, leave traces on many systems before being
able to .... get nothing at the moment
- mailing list
- Freenode registration
I feel like someone who has a complicated map under the eyes, walk, try and
error to make sense of the map, up to a point where the map says: next step
is "find a sponsor" and I have no idea how this is being done.
And time passes by... Slowly. I am silently ignored.
Somebody says today : "Do informal reviews [a suggestion on the wiki, but
what can I suggest ? I have no experience ->chicken and egg problem], make
some mails, fill some bugs and you will get noticed".
I think this is the problem: nobody noticed, it seems nobody cares having a
So, I am concluding: Fedora = too big ship, mainly automated, with a lot of
processes (procedures, way of working) and a community not open to new
contributors [I recall, my experience is only about contributing a new
package], because this is too complicated (which I agree and understand).
That said, I am a patient man, and I have done all this travel not to being
stop by a wall. I spent my life trying to get around, over, across... so
many walls, so, I won't surrender here !
Thanks for reading till that point, and let us open the debate.
PS: I am French, not EN native speaker, pardon my language if it does not
make sense to you.
I started writing this a while ago and never got it fully formed. Rather than let it keep rotting in my drafts folder I wanted to share it and see if it made sense to anyone else.
Warning - rough edges ahead!
Conversations with several people have resulted in distilling the following idea:
== Changing metadata
Modify the table that drives fedoraproject.org/easyfix that is located at https://fedoraproject.org/wiki/Easyfix
The table would now include two additional columns (optional)
Col 1 = existing reference to the issue tracker. We should consider adding gitlab.com support
Col 2 = existing point of contact
Col 3 = category of task (documentation, infrastructure, programming-Haskell, programming-Ruby, etc.)
Col 4 = SIG/WG/etc. this project is related too (Design, Council, KDE, etc.)
== Changing fedoraproject.org/easyfix
Today we show only two categories: Issues from Pagure/Github and Bugzillas
I believe those categories are not the right categories for consumers of the page. Using the new category (col 3) above, we would break things out by the kind of contribution. This would serve to let people browse related tasks more easily and to reduce the overwhelming nature of the current lists.
For BZs we are either going to have to guess based on BZ metadata or leave them lumped together.
WCDIFF should be extended to show the categories and groups appropriate for the various endpoints. This way the person who navigates WCDIFF has the option of reading a specific task they could work on right now, if they so desire.
The categories give us the opportunity to promote our easyfixes as a great way to join or contribute in a targeted manner. This could come in the form of articles, tweets, or live conference appearances.
What do people think?
What do folks think of increasing our meeting frequency to weekly
instead of fortnightly?
I think we're active enough to meet each week. It also means that if we
skip a meeting one week, we can get back to our tasks the very next
week. In our current set up, the gap between meetings in such a scenario
becomes 4 weeks, which is far too much.
Please comment on the ticket I've filed for this here:
Ankur Sinha "FranciscoD"
Time zone: Europe/London