On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mon, 14.05.12 14:45, Stephen Gallagher (sgallagh@xxxxxxxxxx) 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? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
