Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - On 19 January 2015 at 05:08, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Bohuslav Kabrda wrote: Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. Sure, but there is still a distinction in that proposal between first- class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without the political/maintainership issues that the old Core/Extras split had, there were also some technical issues, which this proposal is reintroducing. Those stem from the requirement that ring 1 be self-hosting. It means that not only everything required to build ring 1 packages must be in ring 1, but also everything required to build optional subpackages of ring 1 package SRPMs! In practice, this means that either, e.g., large portions of TeXLive end up in ring 1, or we end up having to disable features, documentation etc. for several packages, or build them as separate SRPMs (which is always painful; we try to avoid that for a reason). I personally don't have a problem with putting large portions of TeXLive into ring 1. Again, I have to repeat that this is only a categorization of a state that currently exists with no intention of changing it (except perhaps suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron). For those not familiar with the issue from the Fedora Core past, just have a look at EPEL, where the split still exists. We end up with hacks like a kde- plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be built in the RHEL package). Such an -extras package then typically needs to track the base package exactly, making updates painful (requiring coordination). (This would be much more of a problem in the fast-moving Fedora than in RHEL with its extremely conservative update policy.) We also end up with RHEL's KDE applications having many optional features simply disabled (at compile time), with no way to add them (other than replacing the entire packages with ones built with the optional features enabled from a third-party repository, in this case Rex Dieter's kde-redhat). IMHO, such a self-hosting ring 1 is a step backwards, even if the implementation keeps it open to all Fedora packagers. It's not. I don't see why we would need to do such hacks as are done in EPEL. The way I see it, if kde-plasma-nm builds several binary RPMs, then some of them are on LiveCDs, hence in ring 1, while others are not (= ring 2). And there's no problem with that. Or is there? The issues that come up are if ring0 and ring1 has a different update process than ring2. If an SRPM has both in them, then you may not be able to fix problems in ring2 because ring0, ring1 would supercede ring2. Thus you end up splitting out a lot of packages into sub-rpms to deal with what the developer sees as needless bureaucracy but the 'product manager' does not. Yeah, I meant that either a) the process shouldn't be different, at least from maintainers point of view - in other words, maintainer would work as he now does, but the package would be tested (for example in Taskotron) and bugs would be reported or b) if at least one binary RPM produced by a SRPM would be in 0 or 1, then all others should be there as well (making ring 1 defined by SRPMs, not RPMs) Since b) has a potential of significantly expanding ring 1, I'd vote for a). But again, that's my perception of this all, I'll make sure to bring this topic up on next Env Stacks meeting, so that others express their opinions as well. Slavek -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - Bohuslav Kabrda wrote: Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. Sure, but there is still a distinction in that proposal between first- class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without the political/maintainership issues that the old Core/Extras split had, there were also some technical issues, which this proposal is reintroducing. Those stem from the requirement that ring 1 be self-hosting. It means that not only everything required to build ring 1 packages must be in ring 1, but also everything required to build optional subpackages of ring 1 package SRPMs! In practice, this means that either, e.g., large portions of TeXLive end up in ring 1, or we end up having to disable features, documentation etc. for several packages, or build them as separate SRPMs (which is always painful; we try to avoid that for a reason). I personally don't have a problem with putting large portions of TeXLive into ring 1. Again, I have to repeat that this is only a categorization of a state that currently exists with no intention of changing it (except perhaps suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron). For those not familiar with the issue from the Fedora Core past, just have a look at EPEL, where the split still exists. We end up with hacks like a kde- plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be built in the RHEL package). Such an -extras package then typically needs to track the base package exactly, making updates painful (requiring coordination). (This would be much more of a problem in the fast-moving Fedora than in RHEL with its extremely conservative update policy.) We also end up with RHEL's KDE applications having many optional features simply disabled (at compile time), with no way to add them (other than replacing the entire packages with ones built with the optional features enabled from a third-party repository, in this case Rex Dieter's kde-redhat). IMHO, such a self-hosting ring 1 is a step backwards, even if the implementation keeps it open to all Fedora packagers. It's not. I don't see why we would need to do such hacks as are done in EPEL. The way I see it, if kde-plasma-nm builds several binary RPMs, then some of them are on LiveCDs, hence in ring 1, while others are not (= ring 2). And there's no problem with that. Or is there? (The ring 0 is likely subject to similar issues and I'm not convinced we need that, either, even though a self-hosting minimal system has been proposed for a long time.) Kevin Kofler -- Regards, Slavek Kabrda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 19 January 2015 at 05:08, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Bohuslav Kabrda wrote: Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. Sure, but there is still a distinction in that proposal between first- class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without the political/maintainership issues that the old Core/Extras split had, there were also some technical issues, which this proposal is reintroducing. Those stem from the requirement that ring 1 be self-hosting. It means that not only everything required to build ring 1 packages must be in ring 1, but also everything required to build optional subpackages of ring 1 package SRPMs! In practice, this means that either, e.g., large portions of TeXLive end up in ring 1, or we end up having to disable features, documentation etc. for several packages, or build them as separate SRPMs (which is always painful; we try to avoid that for a reason). I personally don't have a problem with putting large portions of TeXLive into ring 1. Again, I have to repeat that this is only a categorization of a state that currently exists with no intention of changing it (except perhaps suggesting that the ring 0+1 packages get more QE, perhaps in Taskotron). For those not familiar with the issue from the Fedora Core past, just have a look at EPEL, where the split still exists. We end up with hacks like a kde- plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be built in the RHEL package). Such an -extras package then typically needs to track the base package exactly, making updates painful (requiring coordination). (This would be much more of a problem in the fast-moving Fedora than in RHEL with its extremely conservative update policy.) We also end up with RHEL's KDE applications having many optional features simply disabled (at compile time), with no way to add them (other than replacing the entire packages with ones built with the optional features enabled from a third-party repository, in this case Rex Dieter's kde-redhat). IMHO, such a self-hosting ring 1 is a step backwards, even if the implementation keeps it open to all Fedora packagers. It's not. I don't see why we would need to do such hacks as are done in EPEL. The way I see it, if kde-plasma-nm builds several binary RPMs, then some of them are on LiveCDs, hence in ring 1, while others are not (= ring 2). And there's no problem with that. Or is there? The issues that come up are if ring0 and ring1 has a different update process than ring2. If an SRPM has both in them, then you may not be able to fix problems in ring2 because ring0, ring1 would supercede ring2. Thus you end up splitting out a lot of packages into sub-rpms to deal with what the developer sees as needless bureaucracy but the 'product manager' does not. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
Bohuslav Kabrda wrote: Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. Sure, but there is still a distinction in that proposal between first- class/Core (ring 1) and second-class/Extras (ring 2) packages. Even without the political/maintainership issues that the old Core/Extras split had, there were also some technical issues, which this proposal is reintroducing. Those stem from the requirement that ring 1 be self-hosting. It means that not only everything required to build ring 1 packages must be in ring 1, but also everything required to build optional subpackages of ring 1 package SRPMs! In practice, this means that either, e.g., large portions of TeXLive end up in ring 1, or we end up having to disable features, documentation etc. for several packages, or build them as separate SRPMs (which is always painful; we try to avoid that for a reason). For those not familiar with the issue from the Fedora Core past, just have a look at EPEL, where the split still exists. We end up with hacks like a kde- plasma-nm-extras SRPM that builds some plugins for the kde-plasma-nm package in RHEL (those that depend on VPN libraries not in RHEL and thus cannot be built in the RHEL package). Such an -extras package then typically needs to track the base package exactly, making updates painful (requiring coordination). (This would be much more of a problem in the fast-moving Fedora than in RHEL with its extremely conservative update policy.) We also end up with RHEL's KDE applications having many optional features simply disabled (at compile time), with no way to add them (other than replacing the entire packages with ones built with the optional features enabled from a third-party repository, in this case Rex Dieter's kde-redhat). IMHO, such a self-hosting ring 1 is a step backwards, even if the implementation keeps it open to all Fedora packagers. (The ring 0 is likely subject to similar issues and I'm not convinced we need that, either, even though a self-hosting minimal system has been proposed for a long time.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? -- Regards, Slavek Kabrda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. Inside of the Core team it was a giant pressure cooker of We have to get this out the f'ing door now and don't have time to talk. So it took 3 releases (5 if you count RHL 8 and RHL 9) for Extras to be actually accepted as being something that could be done, and it took 3-4 more releases before Core could be unwound and outside developers to be considered essential developers. Because this proposal is tone deaf to that history it can come across as insulting in various ways. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
- Original Message - On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. Inside of the Core team it was a giant pressure cooker of We have to get this out the f'ing door now and don't have time to talk. So it took 3 releases (5 if you count RHL 8 and RHL 9) for Extras to be actually accepted as being something that could be done, and it took 3-4 more releases before Core could be unwound and outside developers to be considered essential developers. Because this proposal is tone deaf to that history it can come across as insulting in various ways. -- Stephen J Smoogen. Ok, I think that there may be some misunderstanding happening here. The proposal as we discussed it was, that (as our WG sees it): * ring 0, ring 1 and ring 2 are the content built in Fedora's Koji == official Fedora repos * ring 0 is JeOS as defined by Matthew in the .Next proposal * ring 1 contains the packages that are critical in the sense that they are used to compose LiveCDs of our products/cloud images * ring 2 contains anything that anyone wants to build as an extension to rings 0 and 1 (and it's still in Koji as it is right now, e.g. bazillion of python/ruby/perl extension packages, applications that aren't on LiveCDs etc) We meant to categorize packages that are currently in Fedora (and we also wanted to extend the ring proposal to go beyond that with rings 3 and 4 - Copr/Playground and other stuff, but this was actually not discussed into detail yet). Please note, that this proposal is absolutely not about imposing some restrictions on who can/should maintain what. It's really just a categorization of packages based on our WG's perception of importance to Fedora. The only practical change that we suggested is that packages in rings 0 and 1 should get some more QE/integration tests to better guarantee stability. These packages are defined implicitly by their presence on LiveCDs/cloud image, there's no intention of creating a cool group. I hope this explains the matter. If this still feels wrong, I'd like to continue this discussion, as it's not our intention to make someone feel excluded or unimportant. Slavek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
On 01/16/2015 05:08 PM, Stephen John Smoogen wrote: On 16 January 2015 at 01:31, Bohuslav Kabrda bkab...@redhat.com mailto:bkab...@redhat.com wrote: - Original Message - Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler Not all of us were there. So what's the problem with that? Fedora Core was seen by many developers as You either work in the small team of Red Hatters and get stuff done or You are a volunteer or someone at Red Hat who isn't part of the cool group and don't get stuff done. If you were an Outsider and worked on a package that all of a sudden was core you found your version no longer was the one being worked on. That's a very polite description of the situation, then. In fact, it was a 2-class hierarchical society with 2 classes of humans. I do not want to see this dark age of fedora's history repeat. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
Honza Horak wrote: * Fedora Rings (hhorak, 12:03:21) [snip] * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) In other words, Fedora Core all over again? Been there, done that… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes for Env-and-Stacks WG meeting (2015-01-14)
#fedora-meeting: Env and Stacks (2015-01-14) Meeting started by hhorak at 12:01:10 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-01-14/env-and-stacks.2015-01-14-12.01.log.html . Meeting summary --- * hello-ing (hhorak, 12:01:44) * Fedora Rings (hhorak, 12:03:21) * LINK: http://mattdm.org/fedora/next/#15 (hhorak, 12:05:39) * LINK: http://mattdm.org/fedora/next/#20 (hhorak, 12:05:40) * there is no clear sense of the details of each ring.. e.g. definition, type of things in the ring, loose guidelines, users' expectations, motivation to use the rings (hhorak, 12:18:13) * IDEA: ring2 may be split into ring 2 and ring 3 - the new ring 2 should contain only system high-level stacks (we'll always need system versions of e.g. interpreted langauges) and ring 3 should contain copr/playground and possibly also upstream-type of repos (hhorak, 12:18:17) * ring 0 is a minimal bootable system - basically the domain of the Base WG (hhorak, 12:33:37) * IDEA: question is what can be moved out of ring 1 to ring 2? (hhorak, 12:40:13) * IDEA: the promotion idea.. as in ... the lower the number of ring the higher quality of the package and the more it must be maintained (hhorak, 12:40:13) * IDEA: definition of ring 1 is a minimal set of packages that give you a functional system, with some sort of approval (hhorak, 13:31:21) * IDEA: ring 1 should be self-hosted -- because you want to build very solid important packages using very solid important packages (hhorak, 13:31:21) * IDEA: WG-wkstn may want to package httpd differently than WG-server -- that could be solved on configuration - level like httpd-dev and httpd-prod (hhorak, 13:31:21) * IDEA: then ring 2 includes clean/good pkgs of other stuff; ring 3 good pkgs but not complete; ring 4 any old stuff (hhorak, 13:32:31) * IDEA: topic for ML or some of the next meetings: setting some technical expectations about how to differ ring 0, 1, 2.. (hhorak, 13:40:44) * IDEA: topic for ML or some of the next meetings: look more closely on users' wok-flow -- say he wants to develop or use some app from ring X -- what it actually means in practice.. (hhorak, 13:40:44) Meeting ended at 13:45:30 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * juhp_ (69) * bkabrda (64) * langdon (50) * hhorak (45) * vpavlin (28) * zodbot (4) * jzeleny-mtg (1) * samkottler (0) * tjanez (0) * sicampbell (0) * juhp (0) * ncoghlan (0) * pkovar (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
