Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 24. 07. 20 18:06, Neal Gompa wrote: On Fri, Jul 24, 2020 at 12:05 PM Miro Hrončok wrote: On 24. 07. 20 16:19, Vít Ondruch wrote: In this context, I'd be more than happy if the documentation discouraged use of the default streams. Something along these lines: "Modularity have default stream feature, but use it with caution only if you know what you do and what is the impact." In any context, default modular streams are not allowed. This Change proposal does not propose to change that and hence I still don't understand why the policy contains guidelines for default modular streams at all :/ You asked him to make a Change and build general guidelines for modules and module defaults for Fedora that could be applied to ELN. He did that. Thus, here we are. I've asked to discuss allowing default modular streams in ELN with wider community. Stephen offered to prepare a change proposal. The change proposal doesn't say anything about allowing default modular streams in ELN. Hence my confusion. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Fri, Jul 24, 2020 at 12:05 PM Miro Hrončok wrote: > > On 24. 07. 20 16:19, Vít Ondruch wrote: > > In this context, I'd be more than happy if the documentation discouraged > > use of the default streams. Something along these lines: "Modularity > > have default stream feature, but use it with caution only if you know > > what you do and what is the impact." > > In any context, default modular streams are not allowed. > > This Change proposal does not propose to change that and hence I still don't > understand why the policy contains guidelines for default modular streams at > all :/ > You asked him to make a Change and build general guidelines for modules and module defaults for Fedora that could be applied to ELN. He did that. Thus, here we are. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 24. 07. 20 16:19, Vít Ondruch wrote: In this context, I'd be more than happy if the documentation discouraged use of the default streams. Something along these lines: "Modularity have default stream feature, but use it with caution only if you know what you do and what is the impact." In any context, default modular streams are not allowed. This Change proposal does not propose to change that and hence I still don't understand why the policy contains guidelines for default modular streams at all :/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
Just FTR, I don't think I am going to reveal too much saying that for RHEL9, the sentiment is (at least in the context of Ruby, Node.js and Python) that we are very likely not going to use default streams. Plain old RPMs do mostly the same job. In this context, I'd be more than happy if the documentation discouraged use of the default streams. Something along these lines: "Modularity have default stream feature, but use it with caution only if you know what you do and what is the impact." Vít Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/ModularPolicy > > == Summary == > Establish a set of rules for Modular content in Fedora to ensure an > optimal user and packager experience. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgall...@redhat.com > > == Detailed Description == > Over the last several months, members of the Modularity WG and FESCo > have been working to establish a policy for module inclusion in > Fedora. We now have a proposal that FESCo requested be taken to the > Fedora community via the Change Proposal. > > There is a preview of the new policy available at > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > == Benefit to Fedora == > This policy makes explicit what packagers can and cannot do with > Modules in Fedora, which should avoid future issues like those that > were seen during the Fedora 31 and Fedora 32 cycles. > > == Scope == > * Proposal owners: > The proposal is written, so minimal work remains. We may need to make > revisions or clarifications based on public feedback. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > N/A this is not a user-facing change. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 11:01 AM Neal Gompa wrote: > > On Thu, Jul 23, 2020 at 10:56 AM Miro Hrončok wrote: > > > > On 23. 07. 20 16:53, Miro Hrončok wrote: > > > On 23. 07. 20 16:26, Stephen Gallagher wrote: > > >> I like Neal's proposal of "Fedora ELN may use default streams at this > > >> time, and default streams for ELN [...] are delegated to the ELN SIG > > >> with a report for review by FESCo on the progress of using modularity > > >> technology in this manner" in the FESCo approval ticket. > > > > > > My stand here is consistent with what I've said easier: The wider > > > community > > > needs to be part of this discussion, please don't just ask FESCo for this > > > approval, either make it an esecntial part of this change proposal, submit > > > another one or discuss this in a dedicated thread on devel. > > > > Sorry, I've meant "what I've said earlier", "essential". > > I think Stephen has done the right thing here so far. At this point, I > don't want to keep sending him around in circles for this. I've been > there, and that's not a fun place to be. The reason I turned this into a Change Proposal was to get more eyes on it, but it has already effectively been approved by FESCo. I'm incorporating any clarifications that people come up with, but I don't see the need to move the goalposts yet again. > The reason I asked for regular reports about the progress for the > usage of modularity technology in this manner is because at this point > I feel like we need to have visibility on how stuff is improving as > they experiment and develop through ELN. We have an opportunity to > provide our expertise to help guide the development of modularity > technology on the right path to make it suitable for wider use in > Fedora. I think this is perfectly reasonable. I'll keep FESCo in the loop as we move ahead. > And frankly, ordinarily we trust SIGs to do the right thing with their > projects. I do not see this as any different. I do think it makes > sense to have a general policy, and then note that it cannot be used > for Fedora at this time, because it gives a framework in which modules > can be developed to be used in Fedora later by default if we ever > decide to allow them again. > > My only real complaint about ELN is that they don't want to make > install media for people to regularly try out this Fedora variant. I > think that does a disservice to the efforts and makes it harder for > broader testing. Uh, we're making the media, we're just not putting it on getfedora.org. You can get it from https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/Everything/x86_64/iso/ (Note that right now it's not actually installing ELN, it's installing regular Rawhide, but that's a bug I'm working on.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 10:56 AM Miro Hrončok wrote: > > On 23. 07. 20 16:53, Miro Hrončok wrote: > > On 23. 07. 20 16:26, Stephen Gallagher wrote: > >> I like Neal's proposal of "Fedora ELN may use default streams at this > >> time, and default streams for ELN [...] are delegated to the ELN SIG > >> with a report for review by FESCo on the progress of using modularity > >> technology in this manner" in the FESCo approval ticket. > > > > My stand here is consistent with what I've said easier: The wider community > > needs to be part of this discussion, please don't just ask FESCo for this > > approval, either make it an esecntial part of this change proposal, submit > > another one or discuss this in a dedicated thread on devel. > > Sorry, I've meant "what I've said earlier", "essential". I think Stephen has done the right thing here so far. At this point, I don't want to keep sending him around in circles for this. I've been there, and that's not a fun place to be. The reason I asked for regular reports about the progress for the usage of modularity technology in this manner is because at this point I feel like we need to have visibility on how stuff is improving as they experiment and develop through ELN. We have an opportunity to provide our expertise to help guide the development of modularity technology on the right path to make it suitable for wider use in Fedora. And frankly, ordinarily we trust SIGs to do the right thing with their projects. I do not see this as any different. I do think it makes sense to have a general policy, and then note that it cannot be used for Fedora at this time, because it gives a framework in which modules can be developed to be used in Fedora later by default if we ever decide to allow them again. My only real complaint about ELN is that they don't want to make install media for people to regularly try out this Fedora variant. I think that does a disservice to the efforts and makes it harder for broader testing. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 23. 07. 20 16:53, Miro Hrončok wrote: On 23. 07. 20 16:26, Stephen Gallagher wrote: I like Neal's proposal of "Fedora ELN may use default streams at this time, and default streams for ELN [...] are delegated to the ELN SIG with a report for review by FESCo on the progress of using modularity technology in this manner" in the FESCo approval ticket. My stand here is consistent with what I've said easier: The wider community needs to be part of this discussion, please don't just ask FESCo for this approval, either make it an esecntial part of this change proposal, submit another one or discuss this in a dedicated thread on devel. Sorry, I've meant "what I've said earlier", "essential". -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 23. 07. 20 16:26, Stephen Gallagher wrote: I like Neal's proposal of "Fedora ELN may use default streams at this time, and default streams for ELN [...] are delegated to the ELN SIG with a report for review by FESCo on the progress of using modularity technology in this manner" in the FESCo approval ticket. My stand here is consistent with what I've said easier: The wider community needs to be part of this discussion, please don't just ask FESCo for this approval, either make it an esecntial part of this change proposal, submit another one or discuss this in a dedicated thread on devel. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 5:26 AM Miro Hrončok wrote: > > On 22. 07. 20 14:53, Stephen Gallagher wrote: > > On Fri, Jul 10, 2020 at 7:28 AM Miro Hrončok wrote: > > ... > >> As said in the modularity docs PR (but I cannot find it now, because > >> pagure.io > >> is down), I am not sure what is the outcome wrt default streams. Default > >> streams > >> are not allowed now. If this change proposal and the policy is approved, > >> does it > >> mean that: > >> > >> 1) default streams are still not allowed (and hence the default streams > >> section > >> of the policy is moot) > >> > >> 2) default streams are allowed (and hence it should be spelled out > >> explicitly > >> and this should be a system wide change proposal) > >> > >> 3) default streams are allowed in ELN, but not in non-ELN Fedora (and > >> hence it > >> should at least be said somewhere - in the policy or in the proposal) > >> > >> 4) something different? > > ... > > > > I was on PTO last week, sorry for the late reply. > > > > I phrased this policy in such a way that it can apply to any of those > > cases. Use of *any* default in Fedora or ELN must be approved by FESCo > > (with the option for FESCo to delegate that decision to the ELN SIG if > > desired). Right now, FESCo's position on modular defaults in non-ELN > > Fedora is "any such requests will be denied". The policy leaves it > > open for FESCo to make an exception if they deem it appropriate. Does > > that clear things up? > > I am not sure this makes much sense. My comment in > https://pagure.io/fedora-docs/modularity/pull-request/83#comment-124761 > stands. > The default module streams policy should either say (just) "Default modular > streams are not allowed in Fedora and EPEL" or at least it should have a > warning > box at the beginning that says "Default modular streams are not allowed in > Fedora and EPEL, the following rules are provided just for completeness". > > To me it makes no sense to have a list of rules for something that is not > allowed. It's like having a section with comprehensive rules and > recommendations > about shipping proprietary software in the package guidelines while at the > same > time we say it is not allowed. > > Alternatively, since the intention was from the beginning to allow modular > streams in ELN [0], the change proposal should IMHO acknowledge this and the > default modular streams policy should apply to ELN only. IIRC the ask to > "create > a change proposal" [1] was to allow modular streams in ELN, yet this change > proposal actually leaves that out. Okay, I'm fine with adding a note at the top that mentions that default streams are currently forbidden in Fedora. (In EPEL, they *may* be permitted in the buildroot, but not the runtime.) > So I have to ask: What is the plan wrt default streams in ELN? Is the plan to > approach FESCo with the same ask once this policy is approved? Or are default > modular streams in ELN no longer needed? > I like Neal's proposal of "Fedora ELN may use default streams at this time, and default streams for ELN [...] are delegated to the ELN SIG with a report for review by FESCo on the progress of using modularity technology in this manner" in the FESCo approval ticket. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 5:30 AM Remi Collet wrote: > > Le 09/07/2020 à 20:00, Ben Cotton a écrit : > > https://fedoraproject.org/wiki/Changes/ModularPolicy > > > There is a preview of the new policy available at > > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > I think this part may be confusing > > Packages provided at runtime by the default stream of a module MUST > depend only on packages provided by packages from default module > streams or the non-modular package set. By extension, default streams > of a module MUST NOT have a dependency on any non-default stream.[3] > > I think if should be possible, and modularity have been designed for > such usage, to depend on "all" versions of a dependant stream > > Example, > > LANG as a module with version 1, 2, 3 > > APP using LANG build using each version > > So in metadata > > data > name: APP > dependencies: > - buildrequires: > LANG: [] > - requires > LANG: [] > > And documentation seems to forbid this usage. > You are correct, this was an oversight. Would this improve the phrasing? ``` Packages provided at runtime by the default stream of a module MUST depend only on packages provided by packages from default module streams or the non-modular package set. By extension, default streams of a module that have modular dependencies MUST be satisfied by the default streams of those dependencies. ``` ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 5:15 AM Miro Hrončok wrote: > > But I think it should be voted at FESCo after a week? The change process is > vague here, because it only says "no sooner than a week". Ben? > Huh. I have no idea how this slipped through the several places I should have noticed it, but I will submit it to FESCo now. This is a human error, not a process problem. (In other words, I could choose to delay submitting to FESCo if there is still significant *productive* discussion happening on the proposal, but that's not the case here). https://pagure.io/fesco/issue/2452 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 23, 2020 at 11:29:17AM +0200, Remi Collet wrote: > Le 09/07/2020 à 20:00, Ben Cotton a écrit : > > https://fedoraproject.org/wiki/Changes/ModularPolicy > > > There is a preview of the new policy available at > > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > I think this part may be confusing > > Packages provided at runtime by the default stream of a module MUST > depend only on packages provided by packages from default module > streams or the non-modular package set. By extension, default streams > of a module MUST NOT have a dependency on any non-default stream.[3] > > I think if should be possible, and modularity have been designed for > such usage, to depend on "all" versions of a dependant stream > > Example, > > LANG as a module with version 1, 2, 3 > > APP using LANG build using each version > > So in metadata > > data > name: APP > dependencies: > - buildrequires: > LANG: [] > - requires > LANG: [] > > And documentation seems to forbid this usage. > I believe that an intention of the documentation is that if APP is a default stream, then exactly one of LANG streams must be default. That assures that when installing a package (non-modular, or from a default stream), no non-default stream becomes enabled. I agree that the documentation could be understood in the other way, you pointed, and that is that every package of a default stream _regardless of a context_ must not depend on a non-default stream. The documentation could be clarified like this: Packages provided at runtime by at least one context of a default stream of a module MUST depend only on packages provided by packages from default module streams or the non-modular package set. By extension, at least one context of the default streams of a module MUST NOT have a dependency on any non-default stream on each platfrom. But it becomes less comprehensive. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
Le 09/07/2020 à 20:00, Ben Cotton a écrit : > https://fedoraproject.org/wiki/Changes/ModularPolicy > There is a preview of the new policy available at > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ I think this part may be confusing Packages provided at runtime by the default stream of a module MUST depend only on packages provided by packages from default module streams or the non-modular package set. By extension, default streams of a module MUST NOT have a dependency on any non-default stream.[3] I think if should be possible, and modularity have been designed for such usage, to depend on "all" versions of a dependant stream Example, LANG as a module with version 1, 2, 3 APP using LANG build using each version So in metadata data name: APP dependencies: - buildrequires: LANG: [] - requires LANG: [] And documentation seems to forbid this usage. Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 22. 07. 20 14:53, Stephen Gallagher wrote: On Fri, Jul 10, 2020 at 7:28 AM Miro Hrončok wrote: ... As said in the modularity docs PR (but I cannot find it now, because pagure.io is down), I am not sure what is the outcome wrt default streams. Default streams are not allowed now. If this change proposal and the policy is approved, does it mean that: 1) default streams are still not allowed (and hence the default streams section of the policy is moot) 2) default streams are allowed (and hence it should be spelled out explicitly and this should be a system wide change proposal) 3) default streams are allowed in ELN, but not in non-ELN Fedora (and hence it should at least be said somewhere - in the policy or in the proposal) 4) something different? ... I was on PTO last week, sorry for the late reply. I phrased this policy in such a way that it can apply to any of those cases. Use of *any* default in Fedora or ELN must be approved by FESCo (with the option for FESCo to delegate that decision to the ELN SIG if desired). Right now, FESCo's position on modular defaults in non-ELN Fedora is "any such requests will be denied". The policy leaves it open for FESCo to make an exception if they deem it appropriate. Does that clear things up? I am not sure this makes much sense. My comment in https://pagure.io/fedora-docs/modularity/pull-request/83#comment-124761 stands. The default module streams policy should either say (just) "Default modular streams are not allowed in Fedora and EPEL" or at least it should have a warning box at the beginning that says "Default modular streams are not allowed in Fedora and EPEL, the following rules are provided just for completeness". To me it makes no sense to have a list of rules for something that is not allowed. It's like having a section with comprehensive rules and recommendations about shipping proprietary software in the package guidelines while at the same time we say it is not allowed. Alternatively, since the intention was from the beginning to allow modular streams in ELN [0], the change proposal should IMHO acknowledge this and the default modular streams policy should apply to ELN only. IIRC the ask to "create a change proposal" [1] was to allow modular streams in ELN, yet this change proposal actually leaves that out. So I have to ask: What is the plan wrt default streams in ELN? Is the plan to approach FESCo with the same ask once this policy is approved? Or are default modular streams in ELN no longer needed? [0] https://pagure.io/fesco/issue/2390 [1] https://pagure.io/fesco/issue/2390#comment-660813 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 23. 07. 20 10:10, Fabio Valentini wrote: Is this supposed to be voted on by FESCo? The Wiki page was moved into the "ChangeAnnounced" category but I don't seem to find either a FESCo ticket, and I don't remember voting on it, or an announcement. ChangeAnnounced is for the mailing list announcement. But I think it should be voted at FESCo after a week? The change process is vague here, because it only says "no sooner than a week". Ben? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Thu, Jul 9, 2020 at 8:01 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/ModularPolicy > > == Summary == > Establish a set of rules for Modular content in Fedora to ensure an > optimal user and packager experience. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgall...@redhat.com > > == Detailed Description == > Over the last several months, members of the Modularity WG and FESCo > have been working to establish a policy for module inclusion in > Fedora. We now have a proposal that FESCo requested be taken to the > Fedora community via the Change Proposal. > > There is a preview of the new policy available at > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > == Benefit to Fedora == > This policy makes explicit what packagers can and cannot do with > Modules in Fedora, which should avoid future issues like those that > were seen during the Fedora 31 and Fedora 32 cycles. > > == Scope == > * Proposal owners: > The proposal is written, so minimal work remains. We may need to make > revisions or clarifications based on public feedback. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > N/A this is not a user-facing change. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) Is this supposed to be voted on by FESCo? The Wiki page was moved into the "ChangeAnnounced" category but I don't seem to find either a FESCo ticket, and I don't remember voting on it, or an announcement. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
Dne 22. 07. 20 v 14:55 Stephen Gallagher napsal(a): > On Mon, Jul 13, 2020 at 1:06 PM Vít Ondruch wrote: >> Is this just about the specific URL or also about the "Naming Policy"? > The Naming Policy is not currently under discussion in this proposal. > Only the URL provided in the Change Proposal is applicable right now. > > If you want to submit a suggested improvement for the Naming Policy, > please file an issue or send a PR to > https://pagure.io/fedora-docs/modularity/ Done: https://pagure.io/fedora-docs/modularity/pull-request/88 Vít ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Mon, Jul 13, 2020 at 1:06 PM Vít Ondruch wrote: > > Is this just about the specific URL or also about the "Naming Policy"? The Naming Policy is not currently under discussion in this proposal. Only the URL provided in the Change Proposal is applicable right now. If you want to submit a suggested improvement for the Naming Policy, please file an issue or send a PR to https://pagure.io/fedora-docs/modularity/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On Fri, Jul 10, 2020 at 7:28 AM Miro Hrončok wrote: ... > As said in the modularity docs PR (but I cannot find it now, because pagure.io > is down), I am not sure what is the outcome wrt default streams. Default > streams > are not allowed now. If this change proposal and the policy is approved, does > it > mean that: > > 1) default streams are still not allowed (and hence the default streams > section > of the policy is moot) > > 2) default streams are allowed (and hence it should be spelled out explicitly > and this should be a system wide change proposal) > > 3) default streams are allowed in ELN, but not in non-ELN Fedora (and hence it > should at least be said somewhere - in the policy or in the proposal) > > 4) something different? ... I was on PTO last week, sorry for the late reply. I phrased this policy in such a way that it can apply to any of those cases. Use of *any* default in Fedora or ELN must be approved by FESCo (with the option for FESCo to delegate that decision to the ELN SIG if desired). Right now, FESCo's position on modular defaults in non-ELN Fedora is "any such requests will be denied". The policy leaves it open for FESCo to make an exception if they deem it appropriate. Does that clear things up? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
Is this just about the specific URL or also about the "Naming Policy"? I am asking, because I already had a lot of arguments about the branching on this list and various different places but this guideline still insist that "using upstream major versions as branches is recommended". This is not acceptable, because this works just for simplest cases, such as there is module "nodejs" shipping single package "nodejs". It does not work for even slightly more complex cases when module "nodejs" includes not just "nodejs" package, but also lets say "npm" package. Having Node.js versioned brachnes in "npm" is wrong. Not mentioning that if I'll have "mynodejs" module, using both "nodejs" and "npm" and probably also other packages, the versions will be already occupied by "nodejs" module. IOW, the modular packages must live in "module-version" branches by default. This avoids conflicts and provides more understanding why "npm" package has some branches. Vít Dne 09. 07. 20 v 20:00 Ben Cotton napsal(a): > https://fedoraproject.org/wiki/Changes/ModularPolicy > > == Summary == > Establish a set of rules for Modular content in Fedora to ensure an > optimal user and packager experience. > > == Owner == > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgall...@redhat.com > > == Detailed Description == > Over the last several months, members of the Modularity WG and FESCo > have been working to establish a policy for module inclusion in > Fedora. We now have a proposal that FESCo requested be taken to the > Fedora community via the Change Proposal. > > There is a preview of the new policy available at > https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ > > > == Benefit to Fedora == > This policy makes explicit what packagers can and cannot do with > Modules in Fedora, which should avoid future issues like those that > were seen during the Fedora 31 and Fedora 32 cycles. > > == Scope == > * Proposal owners: > The proposal is written, so minimal work remains. We may need to make > revisions or clarifications based on public feedback. > > * Other developers: N/A (not a System Wide Change) > * Release engineering: N/A > N/A (not a System Wide Change) > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > N/A this is not a user-facing change. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: (What to do? Who will do it?) N/A (not a > System Wide Change) > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? N/A (not a System Wide Change) > > == Documentation == > N/A (not a System Wide Change) > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal
On 09. 07. 20 20:00, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/ModularPolicy == Summary == Establish a set of rules for Modular content in Fedora to ensure an optimal user and packager experience. == Owner == * Name: [[User:Sgallagh| Stephen Gallagher]] * Email:sgall...@redhat.com == Detailed Description == Over the last several months, members of the Modularity WG and FESCo have been working to establish a policy for module inclusion in Fedora. We now have a proposal that FESCo requested be taken to the Fedora community via the Change Proposal. There is a preview of the new policy available at https://sgallagh.fedorapeople.org/docs/modularity/modularity/policies/ As said in the modularity docs PR (but I cannot find it now, because pagure.io is down), I am not sure what is the outcome wrt default streams. Default streams are not allowed now. If this change proposal and the policy is approved, does it mean that: 1) default streams are still not allowed (and hence the default streams section of the policy is moot) 2) default streams are allowed (and hence it should be spelled out explicitly and this should be a system wide change proposal) 3) default streams are allowed in ELN, but not in non-ELN Fedora (and hence it should at least be said somewhere - in the policy or in the proposal) 4) something different? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
