On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
On Mon, 14.05.12 14:45, Stephen Gallagher (sgallagh(a)redhat.com)
wrote:
> * #851 F18 Feature: procps-ng (next generation procps tools) -
>
https://fedoraproject.org/wiki/Features/procps-ng (sgallagh,
> 18:11:34)
> * 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[1], 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.[2]
Mirek
[1] 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
flexibility" debate.
[2] Even introducing some F17->F18 incompatibilities to be the same
across distributions. Great, right?