procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))

[Karel Zak]

On Mon, May 14, 2012 at 10:33:22PM +0200, Miloslav Trmač wrote:
> 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,
> >>   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?

 I'm very happy that we have active procps upstream now, this project
 was in horrible condition for years. There is a lot of work to do at
 libproc and proc utils.

 Anyway, I suggested merge procps into util-linux 1-2 years ago and
 I'm still open for this idea.

> > 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.

 Well, Lennart is talking about project infrastructure etc. It's
 easier to maintain only one infrastructure, release and distribute
 one tarball. Our experience is that one large project is better than
 many small projects.

> What does "nicely integrated" mean, really? The tools have their
> documented behaviors.

 - share build system
 - share regression test infrastructure
 - share code (only in Ideal World is all in shared libraries:-)
 - share coding and man pages style
 - large community
 - better connection with another upstreams

 But again, I'm happy that procps is active and this all is only
 a friendly offer :-)

    Karel

-- 
 Karel Zak  <kzak at redhat.com>
 http://karelzak.blogspot.com