Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> > You're partially right. > > If we talk about the Fedora's package name, then it could remain > > untouched. > > But since the new upstream name had to be changed and I wanted > > others to know > > they're installing the -ng version, I changed the name to > > procps-ng. > > Moreover, I initially wanted to introduce both version concurrently > > and later I decided to drop procps completely because of > > unclarities > > in the resolution of virtual provides. > > Right, having multiple procps-style packages installed at once is way > more > effort than it would ever be worth. Exactly. It would surely cause more troubles, than we can imagine at the moment. > > > Packaging guidelines also say that package names should match the > > upstream > > tarball or project name and the name change seemed to me as the > > clearest > > and best solution. > > Is it intended to ever name it back if the older version dies off? Good question. I know that a similar thing happened in case of util-linux. I'm personally not fully against that. But playing with names seems to me unnecessary unless the name conflicts with other projects and therefore renaming back is not absolutely necessary. > > Bill Jaromir. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
Jaromir Capik (jca...@redhat.com) said: > You're partially right. > If we talk about the Fedora's package name, then it could remain untouched. > But since the new upstream name had to be changed and I wanted others to know > they're installing the -ng version, I changed the name to procps-ng. > Moreover, I initially wanted to introduce both version concurrently > and later I decided to drop procps completely because of unclarities > in the resolution of virtual provides. Right, having multiple procps-style packages installed at once is way more effort than it would ever be worth. > Packaging guidelines also say that package names should match the upstream > tarball or project name and the name change seemed to me as the clearest > and best solution. Is it intended to ever name it back if the older version dies off? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> From: "Matej Cepl" > To: devel@lists.fedoraproject.org > Sent: Tuesday, May 15, 2012 9:01:00 PM > Subject: Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's > FESCo Meeting (2012-05-14)) > > On 15.5.2012 14:03, Jaromir Capik wrote: > > There is. We had to change the name, since the former upstream > > is still somehow alive, but not enough to make us happy. > > Do we? I mean if the old procps package will be killed in Fedora > (which > I think it will be, right?) then what you describe could just happen > by > changing URL in Source0, cannot it? Ahoj Matěji. You're partially right. If we talk about the Fedora's package name, then it could remain untouched. But since the new upstream name had to be changed and I wanted others to know they're installing the -ng version, I changed the name to procps-ng. Moreover, I initially wanted to introduce both version concurrently and later I decided to drop procps completely because of unclarities in the resolution of virtual provides. Packaging guidelines also say that package names should match the upstream tarball or project name and the name change seemed to me as the clearest and best solution. Jaromír. > > Matěj > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On 15.5.2012 14:03, Jaromir Capik wrote: There is. We had to change the name, since the former upstream is still somehow alive, but not enough to make us happy. Do we? I mean if the old procps package will be killed in Fedora (which I think it will be, right?) then what you describe could just happen by changing URL in Source0, cannot it? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
> > * #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) > > Ahem. I think is is a really bad idea. "-ng" packages point to a huge > failure in the handling of the packages in question, and should not > be deemed a feature for Linux but a failure of Linux. Says who? You? It must be true then! It seems you really know, how to manipulate people, because the first thing I told to myself after reading this part of your message was : "What a melodic statement!" > 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. util-linux is the much better place for these > utilities, Is it? > so that common code, the development infrastructure, the build > system, > the documentation scheme, the release cycle and the maintainership > can > be shared. Why don't we create just one big package called for example "fedora-distribution" ? We could merge everything inside, because there must be a lot of common functions in all Fedora packages. Let's start doing it immediately, because it could take quite a long time! How much do you know about the procps and util-linux internals? Is it the knowledge or self-importance what makes you claim that? > There's really no point in all the bureaucracy for such a transition > if it just replaces one bad situation with another bad situation. There is. We had to change the name, since the former upstream is still somehow alive, but not enough to make us happy. And as there can't be two independent upstreams called procps, we decided to change the name to avoid conflicts. I strictly disagree with your opinion here. I don't consider procps-ng a replacement with another bad situation. I'm curious where you get enough courage to disparage effort and work of other people. That's the same like claiming that systemd is replacement of bad situation with even worse situation. How do you like it? > If you do a transition then do it right and merge procps into util-linux. Please, stop being always right, especially when you don't know much about projects you're trying to break. > We really don't need two packages with such overlapping > functionality. Is it overlapping? I believe it isn't. The tools would need to be completely redesigned and rewritten to possibly have at least a small set of common functions with util-linux. The question is if it is worthy enough for such a change. The current procps state is so bad, that we had to act really quickly and the unification in form of procps-ng was really inevitable. > Both of them had long phases in their history where > they > were slowly rotting along. The best way to fight that is having a > single > package from it so that this easier kept an eye on. Again. Why would it be easier? Because you said that? > They do very similar stuff Do they? You mean that tiny part touching the proc filesystem? Sorry, but I don't consider tools like fdisk or fdformat similar to tools like top or vmstat. Each of the tools has it's purpose and if anything inside is overlapping, then it's just a very small part and that could eventually be moved to a common library one day. But I believe there's more important work to be done here than playing with reordering the particular tools, moving them from package to package and creating just one huge monolithic rpm, that breaks the basic principles of modularity. > ,they need the same expertise from the hackers and maintainers > and > they should justbe one. > > Really, nobody needs transitions, renames and multiple independent > repos > for stuff that is very very similar in purpose and behaviour. Nobody? That means we're nobody for you, right? I remember such superior attitude from somewhere. Yes. It was one of my previous jobs where everybody was leaving the team because of one manager with similar attitude. > > 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! 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! I'm happy that FESCO members are rational enough and are able to have their own point of view and opinions. > > Lennart Jaromir. > > -- > Lennart Poettering - Red Hat, Inc. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On Mon, May 14, 2012 at 10:33:22PM +0200, Miloslav Trmač wrote: > On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering > wrote: > > On Mon, 14.05.12 14:45, Stephen Gallagher (sgall...@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 http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On Mon, May 14, 2012 at 10:10 PM, Lennart Poettering wrote: > On Mon, 14.05.12 14:45, Stephen Gallagher (sgall...@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
Lennart Poettering (mzerq...@0pointer.de) said: > > * #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) > > Ahem. I think is is a really bad idea. "-ng" packages point to a huge > failure in the handling of the packages in question, and should not be > deemed a feature for Linux but a failure of Linux I read this as simply a feature saying we're switching from procps upstream X to procps upstream Y. To be honest, I'm not sure it's even worthy of a Feature. The -ng naming is unfortunate, but so are many other things. In fact, we're shipping a version from this upstream already, just not the new all-distro-patches-merged version. So, it's essentially a no-op. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
On Mon, 14.05.12 14:45, Stephen Gallagher (sgall...@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) Ahem. I think is is a really bad idea. "-ng" packages point to a huge failure in the handling of the packages in question, and should not be deemed a feature for Linux but a failure of Linux 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. 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. 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. We really don't need two packages with such overlapping functionality. Both of them had long phases in their history where they were slowly rotting along. The best way to fight that is having a single package from it so that this easier kept an eye on. They do very similar stuff, they need the same expertise from the hackers and maintainers and they should justbe one. Really, nobody needs transitions, renames and multiple independent repos for stuff that is very very similar in purpose and behaviour. 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! 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! Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
