Jump to content

The Future of RPM


arctic
 Share

Recommended Posts

I just read this at fedoraforum.org. I found it pretty interesting thus post it here, too.

The Future of RPM

- by Max Spevack -

 

There has been a lot of discussion in the past few months about RPM -- its

present state, its future plans, and its leadership team. In particular,

the Fedora Project has received numerous requests asking us, "what are you

guys doing about RPM?"

 

Here is our answer, in a few words. Then if you want more, you can read

the rest of this note:

 

The Fedora Project is leading the creation of a new community around RPM.

One in which the leaders can come from Fedora, from Red Hat, from Novell,

from Mandriva, or from anywhere. Job #1 is to take the current RPM

codebase and clean it up, and in doing so work with all the other people

and groups who rely on RPM to build a first-rate upstream project.

 

==========

 

The Fedora Board has spoken with Fedora stakeholders both inside and

outside Red Hat, developers/maintainers in Novell, and other parties who

rely on RPM as the foundation for their distributions. We wanted to make

sure those parties agreed that this was the right thing to do for their

respective communities. We touched base with some of these people at the

recent LSB conference, and the overwhelming community opinion there was in

favor of what we are outlining here.

 

At the most fundamental level, we begin with two points:

 

(1) RPM is an important piece of technology, not just for Fedora or for

Red Hat, but for many other distributions and users. Its stability and

maintenance are critical.

 

(2) Red Hat realizes the need to build a strong community of contributors

around RPM, that the upstream of RPM needs to be handled in a manner which

allows contributors and developers to have maximum freedom in their

modifications, and that those modifications can be easily shared across

distributions.

 

Expanding on that:

 

(3) RPM, as a file format, is good at what it does and capable of being

the core of a Linux distribution. From the Fedora perspective, we are not

particularly interested in making any grand deviations from it at this

time.

 

(4) RPM, as an application, has a fairly mature feature set that we are

very interested in stabilizing and bug fixing. Furthermore, we want to

make sure that RPM is a stable and simplified base for the building of

other technologies on top of it. Down the road, we might be interested in

exploring a variety of new features, but we don't believe that should be

the initial focus of our efforts.

 

Ultimately, the Fedora Project and Red Hat are committed to seeing RPM be

as healthy and vibrant as many other large open source projects -- GNOME,

Xorg, etc -- consumed and contributed to by many companies, users,

distributions, and developers. Our overall goal for RPM is to ensure that

is has consistency, reliability, and stability.

 

We switch now to a handy Q&A format:

 

Q -- So what, specifically, are you doing with RPM? And where is the work

going to happen?

 

We have set up a new repository, wiki, and webspace -- external to any

distribution or company -- for RPM, to which anyone can contribute. A

reboot of the upstream, if you will. We don't expect that everyone will

be running the same version of RPM, or run with the same patches, but we'd

like for there to be a single place that everyone can refer to as

upstream, and be able to contribute patches.

 

There is already a contributor base that exists around RPM -- engineers

within Red Hat, Novell, Mandriva, and other organizations. We don't want

to leave those people behind -- we want to do a better job of

collaborating and accepting their work.

 

Everything will live at rpm.org, with a relaunched wiki, code repository,

and mailing lists. As for rpm.org itself, its hosting and maintainership

is outside of Red Hat, and is being generously provided by Duke

University.

 

Q -- How is that different from what currently exists?

 

What we're doing here is collecting together everyone who has a stake in

the future of RPM and building a healthy community around it. This

involves major bug fixing, development work, performance work and making

regular, predictable releases. As it stands today, we don't have these

things. This is a good first step. Could you call it a fork? Maybe. But

we're doing it because we think it's the right thing to do, for

distributions all the way down to the individual users of RPM.

 

Q -- Where is all this stuff going to happen? What's the public mailing

list and wiki? What *EXACTLY* is Fedora or Red Hat going to do?

 

Short answer -- http://rpm.org

 

Over the past few years, engineers from Red Hat and other companies, as

well as a community of independent contributors, have been working on and

maintaining their own versions of RPM -- sometimes sharing patches,

sometimes not. It is important that these contributions move through an

upstream process like many other projects do, in order to maintain a

healthy community and proper checks and balances.

 

To that end, Red Hat is adding an additional engineer that works full time

on upstream issues including patch reviews, community development, etc.

Additionally other Red Hat engineers will contribute to RPM like any other

open source project -- working on the release-engineering parts of RPM

such as rpmbuild, and doing maintenance work.

 

Additionally, here are some of our initial goals:

 

* Give RPM a full technical review, based off of RPM 4.4.2. This is the

common base for Novell and Red Hat. Look what vendors have on top of

4.4.2 and work towards a shared base. Figure out which pieces or code

paths are unnecessary, poorly implemented, or receive little to no use,

and either clean them up or clear them out. Make RPM simpler.

 

There's a lot of folks out there who are using RPM, including the various

Red Hat/Fedora based distros, Suse, and Mandriva, just to name a few.

Simplificaion and focus on the parts of RPM that are core to these

stakeholders is a good way to start.

 

* In turn, this gives us a chance to do a better job with bug fixes.

Squashing bugs that already exist, or closing out bugs that are related to

parts of RPM that are superfluous.

 

* Give RPM the stability that it needs to continue to be the cornerstone

of many distributions.

 

* Enhance the rpm-python bindings, which includes understanding and

gathering together the work that already exists in this area.

 

Most importantly, this work will be done in the community, fully

transparent with the help of the community and RPM stakeholders outside of

Red Hat or Fedora. This is all about incremental steps, not blowing

everything away and starting from scratch.

 

Q -- When is all of this happening?

 

Starting now. Planning and review happening over the next 3-6 months, at

rpm.org. Implementation happening appropriately alongside that planning,

as in most any free software project. Initially, Paul Nasrat is the

primary developer/maintainer dedicated to RPM from Red Hat. At the same

time, we want to make sure that leadership has a chance to develop and

emerge, rather than be mandated.

 

Q -- How did we end up here?

 

This is the part of the email in which Red Hat takes some accountability

for the current situation:

 

* Several years ago, the maintainer of RPM worked for Red Hat. When he

left, he continued his own work on RPM, which he acknowledges is a fork.

And that's fine -- we support anyone's right to fork, since forking is one

of the paths to innovation in open source software.

 

* Red Hat didn't commit the necessary resources to RPM following that

departure.

 

* RPM, without a strong upstream, has languished as a result.

 

* The community has (rightfully) been demanding that the situation be

fixed, and this is the first step in that effort.

 

--

Max Spevack

Link to comment
Share on other sites

* Several years ago, the maintainer of RPM worked for Red Hat. When he

left, he continued his own work on RPM, which he acknowledges is a fork.

And that's fine -- we support anyone's right to fork, since forking is one

of the paths to innovation in open source software.

 

So, what is the fork called? Or is RPM the fork and no work continued on it from RedHat?

Link to comment
Share on other sites

Personally, I have always appreciated rpm, and I think it is a better philosophy for distributing software. I realize that it is not as pure as working with tarballs or compiling from source. But rpm is "user friendly." I am glad to see this development.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...