El Blog de Pacho

http://blog.launchpad.net/general/launchpad-is-now-open-source:

This is a post I’ve been looking forward to for a long time:

Launchpad is now open source!

We released it today under the GNU Affero General Public license, version 3. Note that although we had previously announced that we’d be holding back two components (codehosting and soyuz), we changed our minds: they are included — all the code is open.

Big congratulations (and thanks) to the Canonical Launchpad team, who worked overtime to make this happen sooner rather than later, and to Mark Shuttleworth, whose decision it was to open source Launchpad in the first place.

Rather than repeat the various release announcements, I’ll just point to them:

* launchpad-users mailing list
* Blog post at Canonical.com
* Press release
* The development wiki
* Instructions for getting the code.

The Canonical Launchpad developers will be on IRC in channel #launchpad-dev on irc.freenode.net. That’s the place to go for real time development discussion and questions. For usage issues, #launchpad is still the place, as before.

The mailing list is launchpad-dev {AT} lists.launchpad.net, which you can subscribe to by joining the ~launchpad-dev team. Again, that’s the development mailing list; user questions should still go to launchpad-users {AT} lists.launchpad.net.

Please bear with us as we learn how to be an open source team. Many of the Launchpad developers have open source experience already, of course, but as a team we’ve been working on Launchpad in-house for some years. This is a big change. We’ve been looking forward to it, though, and are ready and eager.

That’s all. Happy hacking :-).

-Karl Fogel

Great to see this great tool opensourced :-D

http://www.nytimes.com/2009/05/29/business/energy-environment/29nuke.html?_r=2&ref=global-home

Hello

I want to remember everybody that Triage Team is always needed of manpower. Currently, we are only 8 members. Most are volunteers that have other tasks to do in real life, then, you will see that we cannot triage your bugs as fast depending on our real life and available free time.

For example, some months ago, roudoudou and Skeletch did a really great job but, like me, we don't have enough time always, then, currently most of the work is being done by Ahmad because the remaining members are too busy for doing more. What would occur if Ahmad or anybody else is unable to dedicate as much time for triaging in the future?

This is the reason for suggesting you to join to BugSquad: if we are more people, everybody will have to do less work, having more free time and, also, being able to dedicate a bit more time to every report for triaging them better.

We don't expect you triaging 200 bugs, we welcome small contributions also ;-), as they will help all Triage Team.

The way for joining is really simple: if you have a certain level of familiarity with Linux in general, Mandriva Linux in particular, and the Bugzilla bug tracking system... simply subscribe to our mailing list and send us a message volunteering.

We will guide and help you to get enough knowledge about Bug Policy, triaging and bugzilla management and, then, give our aproval to you appliance.

As a start point, I suggest you to read the following links (if you detect any problem with them like inconsistencoes, outdated info or anything else, please contact me for fixing them):
Triage Team - How to triage bugs
Bug Policy
Triage Guide

Thanks a lot

Michael Scherer just announced this:

Hi fellows packagers,

( and fellow cookers too, by the way )

As announced by Anne some days ago, next week will be devoted to package cleaning. By package cleaning, this mostly mean patchs cleaning, as explained on http://wiki.mandriva.com/en/2010_patchreview

The goal are multiples :
1) be sure that our contributions, when relevant, are integrated upstream, since this ease the maintenance, and also enhance the free software ecology. After all, the sharing of code is the heart of our ideals.

2) be sure that the patchs are still needed, less patch means less problem when updating, less complexity, and less work the next time we do such a week.

3) be sure that patchs are annoted, so we can know why the patch is here, what problem does it solve, etc, etc.

For this event to be sucessful, we need some kind of coordination, and we also would like to be able to count how much packages where cleaned.

So here is what I suggest :

1) use a tag [prw] ( for patch review week, the shorter, the better ) in commit when we cleaned a rpm

2) go in the irc channel #mandriva-commits, and see what packages are currently cleaned,

3) even if I doubt many conflict while arise, it would be good to announce what packages or packages types you are trying to clean. For exemple, games, gnomes, kernel related, etc. Please announce it here, so people can organise them self in small team ( even if this is a team of one ). Priority is to clean main, but you are free to work on contribs too.

4) for each patch, see if it still applies, and if the patch is still needed. If not needed, drop it,

If needed, add a description, the origin of the patch ( ie, upstream, other distribution ), and a possible bug number or url, in the spec file as a comment.

If needed, and relevant for upstream, try to clean it and submit it upstream ( after checking the latest code of course ). Also add that it was sent upstream, how, and possibly with a url.


We do not plan to parse the information or anything, so the format of the entry is free.

Of course, we will not be able to clean everything in one week, even with our super packaging powers. The goal is to start, and to do the cleaning later when it is needed, when we see a package was not cleaned.

And we would also like to make sure that this operation will enhance the karma of the distribution, so do not hesitate to post about it on your blog ( and if you are a packager not syndicated on planet mandriva, just ask the PM team to add your blog ).


So to start, I announce that I plan to clean python, and python modules.

See you tomorow with your broom to clean the svn.

--
Michael Scherer