Re: Policy for Modules in Fedora and Fedora ELN - Fedora 33 Self-Contained Change proposal

2020-07-24 Thread Miro Hrončok

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

2020-07-24 Thread Neal Gompa
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

2020-07-24 Thread Miro Hrončok

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

2020-07-24 Thread Vít Ondruch
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

2020-07-23 Thread Stephen Gallagher
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

2020-07-23 Thread Neal Gompa
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

2020-07-23 Thread Miro Hrončok

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

2020-07-23 Thread Miro Hrončok

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

2020-07-23 Thread Stephen Gallagher
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

2020-07-23 Thread Stephen Gallagher
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

2020-07-23 Thread Ben Cotton
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

2020-07-23 Thread Petr Pisar
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

2020-07-23 Thread Remi Collet
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

2020-07-23 Thread Miro Hrončok

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

2020-07-23 Thread Miro Hrončok

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

2020-07-23 Thread Fabio Valentini
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

2020-07-22 Thread Vít Ondruch

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

2020-07-22 Thread Stephen Gallagher
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

2020-07-22 Thread Stephen Gallagher
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

2020-07-13 Thread Vít Ondruch
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

2020-07-10 Thread Miro Hrončok

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