Este blog é alimentado pela comunidade aqui na rede SoftwareLivre.org e pelo feed do Planet Mageia English.
Mageia made it to SCaLE 14x for the first time in sunny California, with one of our dedicated QA deputy leaders to man the booth.
Bill Kenney, or wilcal as he is known here, did an amazing job running the Mageia booth at SCaLE. This is an extract from his report on the event.
The Mageia booth was located right in the centre of the Pasadena Convention Center on January 22nd – 24th. Friday saw the highest traffic, Saturday was quieter, but lots of families came down to see the exhibits, which is always nice to see.
Our booth was next to SUSE’s, and sharing the running of the booths was a great show of community and cooperation between Linux projects.
We had Hewlett Packard Enterprise as neighbors; they were running an almost continuous magic and tricks show which always ensured a big crowd in front of the Mageia booth. I made the decision not to give away some kind of “swag” and that was a good decision as I would have needed thousands of items. Also, I opted to put the Mageia literature (English and French) in displays rather then giving pieces of paper away. Again a good decision, as most people just took pictures of the literature if they wanted a copy.
The principal thrust here was to show the Mageia flag, sharing its history and talking about the present and future status. That was the right message. There were lots of people who simply already knew about the Mandrake → Mandriva → Mageia fork tree and most of the time was spent reminiscing about old times with Mandrake. Many indicated that Mandrake was their first Linux distro.
The organizers of SCaLE 14x were appreciative of Mageia making a presence at SCaLE and are certainly open to us returning next year.
Here’s a picture of the Mageia stand with Bill there.
Here’s an 8 min video that Bill shot of the show. Most of the “footage” was shot before show hours. At times this venue was packed with Linux geeks. Enjoy the show:
As it does every year in March, the German event Chemnitz Linux Days will take place during the coming week-end (19th and 20th of March). And as almost every year we are pleased to attend the event and present our distribution there. Please come around and discuss with us the current release as well the upcoming version 6, which is in preparation right now. We will also have nice USB sticks and other Mageia goodies to hand out
Beside our booth, you will find many other interesting projects and companies from the open source community. Furthermore there will be interesting talks, workshops and even activities especially for the younger guests.
Please come along to have a nice and informative weekend with us in Chemnitz.
We are looking forward to seeing you there!
In Mageia 5 I packaged Mopidy , so now that Mageia have a arm port, you can make a Mageia music box with a Raspberry Pi and Mopidys.
I use my self an old netbook for that with an U-Sabre Mini USB DAC .
For Mageia 6 I packaged a backup tool : BorgBackup . some friends use it with success, so I tried it and adopted it. I have my own local backport in Mageia 5, and now my main computer is backuped with BorgBackup.
Here you can read some slides about BorgBackup.
Cantor, the software to scientific programming in worksheet-style interface, had (and has!) several developers working in different parts of the code along the years. Thanks to the plugin-based architecture of Cantor, a developer can to create a new backend to communicate with some new programming language, an assistant, or some other piece of software, requiring just the knowledge of Cantor API.
Because it Cantor has 10 backends using different sets of technologies to provide communication between the software and some programming language. Citing some examples, Python 2 backend uses the Python/C API, R and Python 3 backends use D-Bus protocol, and Scilab backend uses KProcess. So, there are a mix of different technologies in the project.
You can think the maintenance of Cantor can be a headache if the work is done by just one person. Since I received the maintainer status, I am trying to improve the coordination of the project, including the distribution of responsibilities among developers.
In this way, I requested to KDE sysadmin and that amazing team created in KDE Bugzilla different components to each backend in Cantor. For now I asked to some developers to take the responsibility and manage the bugs reported to backends developed by them, but some components are missing maintainers yet, specially the backends of Maxima, Qualculate, R, and Sage.
So, if you were a developer of some of those backends and you would like to continue developing Cantor, please comment in this post or send an e-mail to me in filipe at kde.org and I will put you as the maintainer of the component.
Of course, all developers can to contribute for Cantor and solve his bugs, but the work as maintainer of some component will help us in the task of manage and improve the project.
Projects and software developed by KDE community are going to migrate for a new tool to manage our code, commits, reviews, tasks, and more. This tool is Phabricator and you can visit the instance for KDE projects in this address.
Since November 2015 we are migrating Cantor to Phabricator. After our first successful review code some days ago, I decided to write a post about which tools our contributors must to use while the migration process is not finished.
Phabricator has an app to project management where we can to put some useful information and make coordination of tasks. The page for Cantor project is online and configured.
Projects app in Phabricator has an application to this same objective, Workboard. We are using it currently to track tasks of SoK student Fernando Telles. I intent to use it to manage the development of Cantor for each new release.
Tasks, bugs, wishes
The Phabricator app named Maniphest is the tool to create and track bugs, tasks and wishes (feature requests).
But in KDE we have a heavily customized Bugzilla, so for the moment there is not a decision about how to migrate our bugs reports tool.
Therefore, KDE Bugzilla is our bugs reports tool yet. However, I invite the contributors to use Maniphest to submit wishes of new features. We never used Bugzilla for this last objective, so there is no problem if we begin to use the new tool for it.
Like the most of KDE Projects, Cantor has their source code managed by git. Phabricator has an application named Diffusion to navigate and see a lot of data about a source code repository.
This application is configured for Cantor and it is available in this link.
The Phabricator app to code review is called Differential and it is available to Cantor as well.
However, there is not a decision about the migration and the shutdown of the current code review tool used by KDE, Reviewboard. Therefore our contributors can to use one or other tool (please, not both together!), but I strongly recommend to use Differential.
Yes, Phabricator has an own application to wiki pages, named Phriction. Currently Cantor has a wiki page just in Userbase. We are not using wiki pages at the moment, so we will decide if Phriction will be our tool for wikis just at some point in the future.
Ok, Phabricator also has a tool for communication, Conpherence. However, Cantor contributors can continue to use our current communication tools provide by KDE Edu, the #kde-edu IRC channel at Freenode network and the KDE Edu mail list.
Despite I have some criticism about Phabricator (for instance, I don’t like the Application -> Project architecture; I prefer Project -> Application), it is a very nice tool for projects management and it has a lot of applications for specific tasks. In this text I listed several of them, but there are many others to be explored and evaluated.
I hope this post can help Cantor contributors about which tool must to be utilized for some task of the project. Maybe the text can to present some news to future Phabricator users and help KDE developers in the path of the migration.
The impact of Phabricator in KDE community is something to be analyzed in the future. This tool has a lot of applications and it can change the way how the KDE subprojects are organized. Let’s see what the future will say for us.