8:18 a.m.
Following is the list of topics that will be discussed in the FESCo
meeting Monday at 17:00UTC (1:00pm EDT) in #fedora-meeting on
irc.freenode.net.
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
No old business this week
= New business =
#topic #847 Request to have guidance on growing use of LLVM
.fesco 847
#topic #849 Build and host request for French live ISOs
.fesco 849
#topic #850 Unmounting USB devices is unsafe in Fedora 17
.fesco 850
#topic #851 F18 Feature: procps-ng (next generation procps tools) -
https://fedoraproject.org/wiki/Features/procps-ng
.fesco 851
#topic #852 F18 Feature: OpenShift Origin -
https://fedoraproject.org/wiki/Features/OpenShift_Origin
.fesco 852
#topic #853 F18 Feature: New Installer UI -
https://fedoraproject.org/wiki/Features/NewInstallerUI
.fesco 853
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
1:45 p.m.
New subject: Summary/Minutes from today's FESCo Meeting (2012-05-14)
===================================
#fedora-meeting: FESCO (2012-05-14)
===================================
Meeting started by sgallagh at 17:00:13 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-...
.
Meeting summary
---------------
* init process (sgallagh, 17:00:13)
* limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m all
present (sgallagh, 17:03:25)
* #847 Request to have guidance on growing use of LLVM (sgallagh,
17:04:03)
* AGREED: Packages may only build with an alternative compiler to gcc
if upstream does not support gcc (6 +1) (sgallagh, 17:50:30)
* #849 Build and host request for French live ISOs (sgallagh, 17:50:37)
* AGREED: Send this to the Fedora Advisory Board (9 +1) (sgallagh,
17:58:23)
* #850 Unmounting USB devices is unsafe in Fedora 17 (sgallagh,
17:58:36)
* AGREED: USB unmounting issue is a blocker, needs immediate attention
(9 +1) (sgallagh, 18:11:26)
* #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)
* #852 F18 Feature: OpenShift Origin -
https://fedoraproject.org/wiki/Features/OpenShift_Origin (sgallagh,
18:14:52)
* AGREED: Feature: OpenShift Origin is accepted (9 +1) (sgallagh,
18:16:02)
* #853 F18 Feature: New Installer UI -
https://fedoraproject.org/wiki/Features/NewInstallerUI (sgallagh,
18:16:06)
* AGREED: Feature: New Installer UI is accepted (9 +1) (sgallagh,
18:19:51)
* Next week's chair (sgallagh, 18:20:11)
* AGREED: t8m will chair the 2012-05-21 meeting (sgallagh, 18:20:47)
* Open Floor (sgallagh, 18:20:53)
* ACTION: sgallagh to file FPC ticket for new compiler policy
(sgallagh, 18:23:33)
* ACTION: sgallagh to file an Advisory Board ticket for the localized
compose (sgallagh, 18:24:35)
Meeting ended at 18:35:13 UTC.
Action Items
------------
* sgallagh to file FPC ticket for new compiler policy
* sgallagh to file an Advisory Board ticket for the localized compose
Action Items, by person
-----------------------
* sgallagh
* sgallagh to file FPC ticket for new compiler policy
* sgallagh to file an Advisory Board ticket for the localized compose
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* sgallagh (103)
* pjones (76)
* notting (63)
* mitr (60)
* t8m (55)
* mjg59 (50)
* nirik (49)
* limburgher (30)
* mmaslano (15)
* zodbot (11)
* nb (9)
* mclasen (6)
* drago01 (5)
* kparal (1)
* tibbs|w (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
3:10 p.m.
New subject: 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 (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)
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.
3:21 p.m.
New subject: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
Lennart Poettering (mzerqung(a)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
<putting FESCo hat on>
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
3:33 p.m.
New subject: 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
<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?
3:26 a.m.
New subject: 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
<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?
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(a)redhat.com>
http://karelzak.blogspot.com
7:03 a.m.
New subject: 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
2:01 p.m.
New subject: 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
3:38 a.m.
New subject: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
From: "Matej Cepl" <mcepl(a)redhat.com>
To: devel(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
10:58 a.m.
New subject: procps-ng is a mistake (was: Re: Summary/Minutes from today's FESCo Meeting (2012-05-14))
Jaromir Capik (jcapik(a)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
12:15 p.m.
New subject: 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
4362
days inactive
4364
days old
10 comments
7 participants
participants (7)
-
Bill Nottingham -
Jaromir Capik -
Karel Zak -
Lennart Poettering -
Matej Cepl -
Miloslav Trmač -
Stephen Gallagher