procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
mitr at volny.cz
Mon May 14 20:33:22 UTC 2012
On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering
<mzerqung at 0pointer.de> wrote:
> On Mon, 14.05.12 14:45, Stephen Gallagher (sgallagh at redhat.com) wrote:
>> * #851 F18 Feature: procps-ng (next generation procps tools) -
>> https://fedoraproject.org/wiki/Features/procps-ng (sgallagh,
>> * AGREED: Feature procps-ng is accepted (9 +1) (sgallagh, 18:14:47)
> Karel Zak has made clear that he is happy to merge procps into
> util-linux (Karel is both upstream and downstream for u-l), and has offered
> to do the work.
Yet he told me that he is happy with procps-ng, and the revival was
very much needed. Karel?
> util-linux is the much better place for these utilities,
> so that common code, the development infrastructure, the build system,
> the documentation scheme, the release cycle and the maintainership can
> be shared.
Why is the pairing of procps and util-linux any more special than
pairing, say, coreutils and bzip2? "Common code, development
infrastructure, documentation scheme, release cycle and
maintainership" can always be shared.
IMHO common code belongs in a generally useful library for the
platform (e.g. glibc, glib2), not in some package-private git
repository in each project, where the code slowly rots.
And if /proc accesses are that generally useful to be put into a
library, that library surely should have a stable API, belong in the
procps project, and be used by other projects (including
util-linux-ng) as necessary.
> There's really no point in all the bureaucracy for such a transition
> if it just replaces one bad situation with another bad situation. If you
> do a transition then do it right and merge procps into util-linux.
What bureaucracy? And if you look closely enough, the transition _has
already happened_, there is an actively maintained cross-distribution
shared git repo. The old and new situations are not at all same.
> I'd really like to see FESCO strongly ask the people behind procps-ng to
> help working in the integration of its tools into util-linux, to make
> the basic set of tools more nicely integrated rather than continue to
> grow apart!
What does "nicely integrated" mean, really? The tools have their
documented behaviors. Putting them into one git repo won't make them
magically more integrated - and it won't even make them magically more
maintaned; actually, two separate projects means more proud
maintainers, so it is pretty likely to mean more manpower overall.
> There's really no point in just rubberstamping everything
> people suggest. FESCO should push people in the right direction, and
> push them towards collaboration. FESCO, please steer fedora (and Linux)
> in the right direction here, that's your job!
Ignoring the obvious difficulties, how can FESCo push upstreams to
start or not to start work on a particular project, and how can it do
so before the project is done enough to be proposed for integration?
We had an unmaintained procps upstream and 50 Fedora-specific patches.
Now we have a distribution-common upstream with active development.
Seems pretty close to the right direction to me.
 Opinions differ on the Right Direction. I wonder how pushing
systemd to be less "nicely integrated" would be received, for example
:) Or the eternal "non-technical user simplicity" vs. "syadmin
 Even introducing some F17->F18 incompatibilities to be the same
across distributions. Great, right?
More information about the devel