The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of #fedora-meeting. Here is the expected agenda:
* CMPI Plugin Guideline: https://fedoraproject.org/wiki/PackagingDrafts/CMPIPlugins
* Static Library PICness: https://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines
* Mark VCS in spec files: https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
* Use %{_isa} to make hardcoded Requires Arch Specific: https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
* Correct existing definitions of RPM Macros in guidelines to match current reality: https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
=====
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
The process for proposing a change to the Fedora Packaging Guidelines is documented here: https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedur...
Also, to attempt to restore some sense of regularity to the FPC meetings, the FPC will also meet on the following days:
* Wednesday May 26, 2010 - 16:00 UTC * Wednesday June 9, 2010 - 16:00 UTC * Wednesday June 23, 2010 - 16:00 UTC
FPC members, please be sure to attend.
Thanks,
Tom "spot" Callaway, Fedora Packaging Committee Chair
On Mon, 10 May 2010, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of
#fedora-meeting. Here is the expected agenda:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd be interested in hearing the opinions of the FPC on:
https://fedorahosted.org/fesco/ticket/373
and in general metadata explosions of its type.
-sv
On 05/10/2010 08:56 AM, Seth Vidal wrote:
On Mon, 10 May 2010, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of
#fedora-meeting. Here is the expected agenda:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd be interested in hearing the opinions of the FPC on:
https://fedorahosted.org/fesco/ticket/373
and in general metadata explosions of its type.
-sv
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Sweet weeping $_DEITY!
More nuanced views and suggestions to follow at FPC meeting. . .
-J
Tom spot Callaway (tcallawa@redhat.com) said:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd like FPC to decide and clearly state their Official(tm) opinion on FESCo review of approved guidelines; it came up again in the thread-of-doom, with claims both that FPC-as-a-whole wanted FESCo to review, and that they *didn't* want FESCo review.
Bill
On 05/10/2010 01:46 PM, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd like FPC to decide and clearly state their Official(tm) opinion on FESCo review of approved guidelines; it came up again in the thread-of-doom, with claims both that FPC-as-a-whole wanted FESCo to review, and that they *didn't* want FESCo review.
Well, I want FESCo review. If the FPC disagrees with me and wants to vote on it, I'd be happy to let them. I think the fact that things have passed FPC, only to be reviewed by FESCo and found wanting (which then went back to FPC for revision and eventual acceptance) means that the procedure works, even if it is rare that FESCo find anything at issue with the FPC proposals.
~spot
On 05/10/2010 01:14 PM, Tom "spot" Callaway wrote:
On 05/10/2010 01:46 PM, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd like FPC to decide and clearly state their Official(tm) opinion on FESCo review of approved guidelines; it came up again in the thread-of-doom, with claims both that FPC-as-a-whole wanted FESCo to review, and that they *didn't* want FESCo review.
Well, I want FESCo review. If the FPC disagrees with me and wants to vote on it, I'd be happy to let them. I think the fact that things have passed FPC, only to be reviewed by FESCo and found wanting (which then went back to FPC for revision and eventual acceptance) means that the procedure works, even if it is rare that FESCo find anything at issue with the FPC proposals.
~spot
packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
Words right out of my mouth, but I'd definitely like to have conversation around it in the next meeting.
-J
On Mon, May 10, 2010 at 02:14:33PM -0400, Tom spot Callaway wrote:
On 05/10/2010 01:46 PM, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd like FPC to decide and clearly state their Official(tm) opinion on FESCo review of approved guidelines; it came up again in the thread-of-doom, with claims both that FPC-as-a-whole wanted FESCo to review, and that they *didn't* want FESCo review.
Well, I want FESCo review. If the FPC disagrees with me and wants to vote on it, I'd be happy to let them. I think the fact that things have passed FPC, only to be reviewed by FESCo and found wanting (which then went back to FPC for revision and eventual acceptance) means that the procedure works, even if it is rare that FESCo find anything at issue with the FPC proposals.
I'd like FESCo to have the right of appeal but not necessarily review. If I just link to my previous writeup, will other FPC members be good enough to read it? https://fedorahosted.org/fesco/ticket/358#comment:8
Basically, I think the current way that ratification by fesco works in practice delays guidelines getting put into effect and getting written up with little benefit.
The actual times when FESCo points out problems are largely when the issue gets discussed on the mailing lists between the FPC meeting and the FESCo meeting. This could just as easly tie into the process where FESCo represents the packagers to the FPC to get a change in an established guideline as opposed to having a separate step where the guidelines must be explicitly ratified by FESCo. In our present process, fesco is supposedly reviewing the Guidelines between the time that the FPC passes them and the FESCo meeting but it's apparent that this seldom happens in practice.
As noted in that ticket, it would make it easier to get FPC guidelines written up as the accountability for writing up passed guidelines could be handed out directly following the meeting rather than getting lost in the shuffle between FPC meeting - FESCo meeting - FPC meeting.
The real benefit is probably to FESCo, though, as it clears out ten to fifteen minutes that they would no longer need to spend on it in meeting and however long the members actually do spend on reviewing the guidelines outside of the meeting as the current method of review is assuming they do.
So if it's brought to a vote in FPC, I'll vote that FESCo stop explicitly having a review step and moves to just pushing things they notice as problems back to FPC. But I won't mind overly much if it doesn't win out there -- I'd be more concerned about it if I were on FESCo and had to try to add reviewing of the guidelines to the other things on the FESCo agenda.
-Toshio
On 05/10/2010 05:16 PM, Toshio Kuratomi wrote:
On Mon, May 10, 2010 at 02:14:33PM -0400, Tom spot Callaway wrote:
On 05/10/2010 01:46 PM, Bill Nottingham wrote:
Tom spot Callaway (tcallawa@redhat.com) said:
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
I'd like FPC to decide and clearly state their Official(tm) opinion on FESCo review of approved guidelines; it came up again in the thread-of-doom, with claims both that FPC-as-a-whole wanted FESCo to review, and that they *didn't* want FESCo review.
Well, I want FESCo review. If the FPC disagrees with me and wants to vote on it, I'd be happy to let them. I think the fact that things have passed FPC, only to be reviewed by FESCo and found wanting (which then went back to FPC for revision and eventual acceptance) means that the procedure works, even if it is rare that FESCo find anything at issue with the FPC proposals.
I'd like FESCo to have the right of appeal but not necessarily review. If I just link to my previous writeup, will other FPC members be good enough to read it? https://fedorahosted.org/fesco/ticket/358#comment:8
Good food for thought, I will certainly mull this over the next 27 hours.
One thing this highlighted for me, and maybe it's something I missed, being the FPC NKOTB, but it never occurred to me that FPC members could attend FESCO meetings. I see the notifications, I just never put 2 and 2 together. <facepalm>
In any event, thanks for writing this up, it gives us a good place to debate from and, I hope, will lead to a more efficient process without sacrificing quality.
-J
Basically, I think the current way that ratification by fesco works in practice delays guidelines getting put into effect and getting written up with little benefit.
The actual times when FESCo points out problems are largely when the issue gets discussed on the mailing lists between the FPC meeting and the FESCo meeting. This could just as easly tie into the process where FESCo represents the packagers to the FPC to get a change in an established guideline as opposed to having a separate step where the guidelines must be explicitly ratified by FESCo. In our present process, fesco is supposedly reviewing the Guidelines between the time that the FPC passes them and the FESCo meeting but it's apparent that this seldom happens in practice.
As noted in that ticket, it would make it easier to get FPC guidelines written up as the accountability for writing up passed guidelines could be handed out directly following the meeting rather than getting lost in the shuffle between FPC meeting - FESCo meeting - FPC meeting.
The real benefit is probably to FESCo, though, as it clears out ten to fifteen minutes that they would no longer need to spend on it in meeting and however long the members actually do spend on reviewing the guidelines outside of the meeting as the current method of review is assuming they do.
So if it's brought to a vote in FPC, I'll vote that FESCo stop explicitly having a review step and moves to just pushing things they notice as problems back to FPC. But I won't mind overly much if it doesn't win out there -- I'd be more concerned about it if I were on FESCo and had to try to add reviewing of the guidelines to the other things on the FESCo agenda.
-Toshio
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Monday 10 May 2010, Tom "spot" Callaway wrote:
- Use %{_isa} to make hardcoded Requires Arch Specific:
https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
Two potential trivialish changes spring to mind:
- * A non-noarch -devel package depends on another -devel package. + * A non-noarch -devel package depends on another non-noarch -devel package.
- A non-noarch subpackage's dependency on its main package (Eg. libfoo-devel depends on libfoo). + A non-noarch subpackage's dependency on its non-noarch main package (Eg. libfoo-devel depends on libfoo).
...right?
BTW it would result in less broken dependency churn if packagers would go through their subpackages (-devel in particular) that are candidates for switching to noarch and did the switch before the MUST to make deps to these arch qualified where applicable takes effect.
On 05/10/2010 03:49 PM, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of
Thursday, May 13 is a public holiday in Germany.
Therefore, it's likely I'll quit working "early" on May 12, and not be able to attend the meeting at 16:00 UTC (18:00 local time).
Ralf
On 05/11/2010 04:25 AM, Ralf Corsepius wrote:
On 05/10/2010 03:49 PM, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of
Thursday, May 13 is a public holiday in Germany.
Therefore, it's likely I'll quit working "early" on May 12, and not be able to attend the meeting at 16:00 UTC (18:00 local time).
Thanks for the heads-up, enjoy your holiday.
~spot
On 05/10/2010 03:49 PM, Tom "spot" Callaway wrote:
The Fedora Packaging Committee will meet on Wednesday, May 12, at its regular time of 16:00 UTC, and in its regular location of #fedora-meeting. Here is the expected agenda:
As I'd likely not be able to attend, here are my preliminary votes:
- CMPI Plugin Guideline:
This is useful as "cooking recipe" for packaging such packages, but feel this is too specialized to be suitable for guidelines.
OK as an "inofficial" appendix, but not OK as part of the main FPG.
- Static Library PICness:
https://fedoraproject.org/wiki/User:Ajax/Static_Library_PICness_Guidelines
Basically OK, except of the naming proposal (libpic-foo.a etc.).
-1 in its current shape, because this would a) break with tradional usage of static libs. b) would require intrusive works on some packages' sources.
+1 with the library naming scheme removed.
- Mark VCS in spec files:
https://fedoraproject.org/wiki/User:Walters/Packaging_VCS_key_proposal
-1 ... superfluous bureaucracy.
- Use %{_isa} to make hardcoded Requires Arch Specific:
https://fedoraproject.org/wiki/PackagingDrafts/ArchSpecificRequires
As repeatedly said, I am opposed to using %{_isa} in general, because I consider it to be redundant to library paths and to only be adding bloat.
Also, the current proposal seems "uncooked", to me (E.g. I don't understand when the author want packagers to use %{_isa} or not).
Proposal: Have the author rework it and table it for now.
Should you insist on voting on it, count me as "-1".
- Correct existing definitions of RPM Macros in guidelines to match
current reality: https://fedoraproject.org/wiki/PackagingDrafts/RPMMacros_sharedstatedir_optf...
It's step into the right direction, but if being pedantic, there are mistakes in this draft:
* autoconf variable datarootdir is missing (Off head, I don't know if rpm meanwhile has adopted it. It's in autoconf for many (10?) years)
* _lib is not an autoconf variable. Its documentation should be moved into the "non-autoconf" section.
Otherwise OK.
+1 with the changes above applied, 0 otherwise.
=====
If there is something else that you feel should be on the agenda for this meeting, please feel free to let us know.
We need strict definitions (or at least documentation) of which packages to expect in each specific distro's buildroots, shouldn't we already have them (ATM, I can't find them).
Background: In recent days, I have been observing "package-rebuild errors", seemingly originating from some packages having been removed from buildroots. As I was rebuilding packages maintained by other folks, I don't know for how long these build error have been present (they did not cause build aborts, but caused the packages to be "mis-built").
Ralf
On 05/11/2010 10:03 AM, Ralf Corsepius wrote:
Basically OK, except of the naming proposal (libpic-foo.a etc.).
-1 in its current shape, because this would a) break with tradional usage of static libs. b) would require intrusive works on some packages' sources.
+1 with the library naming scheme removed.
I don't know how you accomplish shipping both PIC and nonPIC versions of the same shared lib without renaming the library. I'm open to alternative suggestions.
~spot
packaging@lists.fedoraproject.org