[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-list
Subject:    Fw: RPM -- plans, goals, etc.
From:       Matthias Saou <thias () spam ! spam ! spam ! spam ! spam ! spam ! spam ! egg ! and ! spam ! freshrpms ! n
Date:       2006-12-14 17:57:58
Message-ID: 20061214185758.3bc640d0 () python3 ! es ! egwn ! lan
[Download RAW message or body]

FYI.

A few quick things :
1) Maybe it's now time to rearrange the existing mailing-lists and have
everything @rpm.org, both a user and a developer lists?
2) I really hope some (most?) of the new features Jeff's rpm has been
getting will be backported/forwardported (hmm...) to this "new" rpm.

I also hope that Jeff will continue working on rpm. I don't know all of
the personal and political issues surrounding all this, but it seems
that it's not just a "Fedora fork", but rather an effort to bring many
distro developers to cooperate, so hopefully those still interested in
having rpm work in various proprietary *nix systems will stick around,
although it does seem that the main focus will be Linux-based distros.

Jeff : Whatever you decide from here, I personally wish to thank you for
all your hard work on rpm over these many years!!!

Matthias

--

Begin forwarded message:

Date: Thu, 14 Dec 2006 12:42:03 -0500 (EST)
From: Max Spevack <mspevack@redhat.com>
To: fedora-announce-list@redhat.com
Subject: RPM -- plans, goals, etc.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
+ http://fedoraproject.org/wiki/MaxSpevack
+ gpg key -- http://spevack.org/max.asc
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFgYzyL9vLRloXzyERAtbwAJ9vvFk9JgiyIV0wmqcRNpS818NLGwCgnHX5
606VyFF7nCwtY24obdDN+ws=
=qQA7
-----END PGP SIGNATURE-----

-- 
fedora-announce-list mailing list
fedora-announce-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-announce-list


-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 6 (Zod) - Linux kernel 2.6.18-1.2835.fc6
Load : 0.20 0.18 0.25

[prev in list] [next in list] [prev in thread] [next in thread]