2:57 p.m.
With regard to the recent protobuf package issue and the eclipse module, I
started wondering how bugs work with packages bundled in modules. That is,
packages that exist outside modules (e.g., protobuf) that end up bundled with
some module.
NOTE: It is very easy for module posts to quickly balloon out in to all sorts
of topics and stories. I would prefer that we keep this thread related to the
Subject above. Thanks.
The following are policy questions I came up with after the protobuf issue
happened:
1) Are modules allowed to bundle packages that are provided by and currently
maintained in the base system? Are there are restrictions to what a module
can bundle (e.g., can a module bundle glibc)?
2) Using protobuf as an example, if a bug is found by a user and they happen
to deduce that the error is in protobuf, how do they file a bug? Do they file
the bug against protobuf if the bundled one from the module has the issue?
What maintainer is on the hook for handling that bug report? My assumption
here is that the module maintainer is ultimately responsible for everything
they bundle. Another concern I see here is we are opening ourselves up for
N+1 different builds of protobuf where N is the number of modules installed on
a system and all of them could have protobuf bundled.
3) If a user files a bug against a module and the module maintainer triages
that to a bundled package, how is that handled? Who is maintaining the
bundled build of that package? Who is responsible for fixing it?
4) How can users determine what packages are installed from a module and how
can you see what, if any, module "owns" a package? I have been unable to
determine how to do this from dnf.
5) How are CVEs handled for packages that are also bundled with a module?
I have read as much as I can find about how things work right now with
modules, but that has been mostly the "how" and nothing around policy.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
4:21 p.m.
On 17. 12. 19 21:57, David Cantrell wrote:
1) Are modules allowed to bundle packages that are provided by and
currently
maintained in the base system? Are there are restrictions to what a module
can bundle (e.g., can a module bundle glibc)?
I am not aware of any policy against modularizing existing packages. Modular
maintainers can module-bundle glibc. OTOH I don't know all the policies.
There is a policy for making a default modular stream: if it overrides existing
non-modular packages, it requires FESCo approval. So far this has not been
retroactive and the ant and maven default modular streams do that.
See also https://pagure.io/modularity/issue/170
2) Using protobuf as an example, if a bug is found by a user and they
happen
to deduce that the error is in protobuf, how do they file a bug? Do they file
the bug against protobuf if the bundled one from the module has the issue?
What maintainer is on the hook for handling that bug report? My assumption
here is that the module maintainer is ultimately responsible for everything
they bundle. Another concern I see here is we are opening ourselves up for
N+1 different builds of protobuf where N is the number of modules installed on
a system and all of them could have protobuf bundled.
I would assume they file it in protobuf. They haven't opted for any module and
they don't know it's modular, really. The non-modular maintainer may deduce from
the NERVA that it is modular build and do some nontrivial digging to figure out
where is this package coming from - if they can, they will reassign the bug
report to that module component.
I agree that the modular maintainers are ultimately responsible for everything
they bundle.
I share your concerns.
3) If a user files a bug against a module and the module maintainer
triages
that to a bundled package, how is that handled? Who is maintaining the
bundled build of that package? Who is responsible for fixing it?
The modular maintainer or somebody else who he modular maintainer made a deal
with. As far as possible in a community supported distribution, I think the
modular maintainer should be responsible.
4) How can users determine what packages are installed from a module
and how
can you see what, if any, module "owns" a package? I have been unable to
determine how to do this from dnf.
They don't. If they are well informed about how Fedora is developed, they might
guess from the release tag and then do some detective work.
See also https://pagure.io/modularity/issue/171
5) How are CVEs handled for packages that are also bundled with a
module?
I don't think they are reported properly. Hence they are handled on the modular
maintainer's discretion.
See also https://pagure.io/modularity/issue/169
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:53 a.m.
On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote:
On 17. 12. 19 21:57, David Cantrell wrote:
>1) Are modules allowed to bundle packages that are provided by and currently
>maintained in the base system? Are there are restrictions to what a module
>can bundle (e.g., can a module bundle glibc)?
I am not aware of any policy against modularizing existing packages.
Modular maintainers can module-bundle glibc. OTOH I don't know all the
policies.
There is a policy for making a default modular stream: if it overrides
existing non-modular packages, it requires FESCo approval. So far this
has not been retroactive and the ant and maven default modular streams
do that.
See also https://pagure.io/modularity/issue/170
I feel there should be some restrictions around this bundling. glibc is a
good example, but I am also concerned about the ability for modules to bundle
security-libraries which could lead to a system with multiple different
versions of a shared library on a system.
With protobuf as the example again, we saw that the eclipse module's bundled
protobuf took the lead in depsolving and dnf upgraded systems to that
regardless of whether or not they had the module installed. So the multiple
shared library scenario is only a concern in a world where we do parallel
installability. Putting that aside for the moment, I'd like to refine the
above concern:
We should have some restrictions about packages that can and cannot be bundled
with modules. This may require defining some sort of criteria or a set of
core packages or some other test. Likewise, packages like openssl need some
thought because while we do not currently do parallel installability, even
having parallel availability still means we could have multiple different
builds of an openssl package. There should be a plan around that because
having that be unbounded sets us up for a lot of panic mode work should there
be something like Heartbleed happen again.
>2) Using protobuf as an example, if a bug is found by a user and
they happen
>to deduce that the error is in protobuf, how do they file a bug? Do they file
>the bug against protobuf if the bundled one from the module has the issue?
>What maintainer is on the hook for handling that bug report? My assumption
>here is that the module maintainer is ultimately responsible for everything
>they bundle. Another concern I see here is we are opening ourselves up for
>N+1 different builds of protobuf where N is the number of modules installed on
>a system and all of them could have protobuf bundled.
I would assume they file it in protobuf. They haven't opted for any
module and they don't know it's modular, really. The non-modular
maintainer may deduce from the NERVA that it is modular build and do
some nontrivial digging to figure out where is this package coming
from - if they can, they will reassign the bug report to that module
component.
I agree that the modular maintainers are ultimately responsible for
everything they bundle.
I share your concerns.
Filing against protobuf makes sense, but then we get to the maintainers. The
protobuf maintainer did not know eclipse bundled protobuf. Without being
involved in that decision, I think it's unfair to expect package maintainers
to be the triage point for all incoming bugs, either regular packages or
bundled packages. That's just not going to really scale very well and will
result in frustration among package maintainers and users.
Maybe if a module bundles a package, the module maintainer also becomes a
co-maintainer on the bundled package?
>3) If a user files a bug against a module and the module
maintainer triages
>that to a bundled package, how is that handled? Who is maintaining the
>bundled build of that package? Who is responsible for fixing it?
The modular maintainer or somebody else who he modular maintainer made
a deal with. As far as possible in a community supported distribution,
I think the modular maintainer should be responsible.
I agree. The reporting and ownership story needs some more work. The way we
have Bugzilla set up right now does not make it obvious to me how a bug could
be distinguished between the regular package and the bundled package in a module.
>4) How can users determine what packages are installed from a
module and how
>can you see what, if any, module "owns" a package? I have been unable to
>determine how to do this from dnf.
They don't. If they are well informed about how Fedora is developed,
they might guess from the release tag and then do some detective work.
See also https://pagure.io/modularity/issue/171
From a user experience standpoint, I feel this is unsufficient. Users should
be able to determine where packages came from. Whether or not that happens
through dnf does not matter to me, but we need some sort of tool that allows
for that information to be discovered.
>5) How are CVEs handled for packages that are also bundled with a
module?
I don't think they are reported properly. Hence they are handled on
the modular maintainer's discretion.
See also https://pagure.io/modularity/issue/169
I would like to see modules have a stronger policy around tracking and
handling CVEs. At the very least, what Fedora already does for regular
packages.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1:52 p.m.
David Cantrell <dcantrell(a)redhat.com> writes:
On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote:
> On 17. 12. 19 21:57, David Cantrell wrote:
>> 1) Are modules allowed to bundle packages that are provided by and
>> currently maintained in the base system? Are there are restrictions
>> to what a module can bundle (e.g., can a module bundle glibc)?
>
> I am not aware of any policy against modularizing existing packages.
> Modular maintainers can module-bundle glibc. OTOH I don't know all
> the policies.
>
> There is a policy for making a default modular stream: if it
> overrides existing non-modular packages, it requires FESCo
> approval. So far this has not been retroactive and the ant and maven
> default modular streams do that.
>
> See also https://pagure.io/modularity/issue/170
I feel there should be some restrictions around this bundling. glibc
is a good example, but I am also concerned about the ability for
modules to bundle security-libraries which could lead to a system with
multiple different versions of a shared library on a system.
With protobuf as the example again, we saw that the eclipse module's
bundled protobuf took the lead in depsolving and dnf upgraded systems
to that regardless of whether or not they had the module installed.
So the multiple shared library scenario is only a concern in a world
where we do parallel installability. Putting that aside for the
moment, I'd like to refine the above concern:
We should have some restrictions about packages that can and cannot be
bundled with modules. This may require defining some sort of criteria
or a set of core packages or some other test. Likewise, packages like
openssl need some thought because while we do not currently do
parallel installability, even having parallel availability still means
we could have multiple different builds of an openssl package. There
should be a plan around that because having that be unbounded sets us
up for a lot of panic mode work should there be something like
Heartbleed happen again.
Agreed. Especially with the work we do on crypto deprecations, I worry
that there will be strong temptation to create bundled crypto packages
that "make the old workflow work again" or so.
>> 2) Using protobuf as an example, if a bug is found by a user
and
>> they happen to deduce that the error is in protobuf, how do they
>> file a bug? Do they file the bug against protobuf if the bundled
>> one from the module has the issue? What maintainer is on the hook
>> for handling that bug report? My assumption here is that the module
>> maintainer is ultimately responsible for everything they bundle.
>> Another concern I see here is we are opening ourselves up for N+1
>> different builds of protobuf where N is the number of modules
>> installed on a system and all of them could have protobuf bundled.
>
> I would assume they file it in protobuf. They haven't opted for any
> module and they don't know it's modular, really. The non-modular
> maintainer may deduce from the NERVA that it is modular build and do
> some nontrivial digging to figure out where is this package coming
> from - if they can, they will reassign the bug report to that module
> component.
>
> I agree that the modular maintainers are ultimately responsible for
> everything they bundle.
>
> I share your concerns.
Filing against protobuf makes sense, but then we get to the
maintainers. The protobuf maintainer did not know eclipse bundled
protobuf. Without being involved in that decision, I think it's
unfair to expect package maintainers to be the triage point for all
incoming bugs, either regular packages or bundled packages. That's
just not going to really scale very well and will result in
frustration among package maintainers and users.
Maybe if a module bundles a package, the module maintainer also
becomes a co-maintainer on the bundled package?
This worries me because I don't think we have sufficiently fine-grained
commit controls since the pkgdb retirement. While I would love to be
incorrect about this, I don't see a way to restrict what branches can be
committed to by those with access to a package - and I don't think it's
at all reasonable for someone who makes a module version of a package to
gain commit bits to all branches. (Especially without consent of the
existing maintainer(s).)
>> 5) How are CVEs handled for packages that are also bundled
with a
>> module?
>
> I don't think they are reported properly. Hence they are handled on
> the modular maintainer's discretion.
>
> See also https://pagure.io/modularity/issue/169
I would like to see modules have a stronger policy around tracking and
handling CVEs. At the very least, what Fedora already does for
regular packages.
I would like this as well, but don't think "what Fedora already does for
regular packages" is sufficient here. To criticize process (and only
process, not people) for a moment here:
Right now, the impetus for CVEs to be fixed[1] comes solely from the
maintainer. Unless the CVE becomes a buzzword issue with a name and
logo (Heartbleed has already been mentioned upthread), there are
basically no consequences to not fixing CVEs in one's packages until
non-responsive maintainer bugs start getting filed. There doesn't seem
to be any monitoring of these, and unlike FTBFS bugs, they're not
grounds for removing packages from the distro.
I don't want to put blame on anyone for this, of course - if it were
easy to fix we would have done it already. My understanding is that a
lot of the problems I described above are due to lack of capacity to
perform the work associated. Asking the folks performing
security-related tasks in the distro - who are already overloaded - to
perform even more work does not strike me as a good idea. There needs
to be an easy way for them to query what versions of what packages are
present in Fedora - anywhere in Fedora - and file bugs against all of
them individually such that they reach the correct maintainers without
additional triage.
Thanks,
--Robbie
1: Often, even knowing that CVEs exist also requires the maintainer to
be paying attention to upstream development. This is because tracker
bugs are often missing, and usually late when they are created - in
many cases, after the issue in question has already been fixed.
2:19 p.m.
On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote:
David Cantrell <dcantrell(a)redhat.com> writes:
...snip...
> I would like to see modules have a stronger policy around
tracking and
> handling CVEs. At the very least, what Fedora already does for
> regular packages.
I would like this as well, but don't think "what Fedora already does for
regular packages" is sufficient here. To criticize process (and only
process, not people) for a moment here:
Just a note: Fedora doesn't do anything currently for regular packages.
Red Hat Product Security opens bugs for CVES that are public for Fedora.
I'd like to thank them for this tedious and very helpfull work.
Right now, the impetus for CVEs to be fixed[1] comes solely from the
maintainer. Unless the CVE becomes a buzzword issue with a name and
logo (Heartbleed has already been mentioned upthread), there are
basically no consequences to not fixing CVEs in one's packages until
non-responsive maintainer bugs start getting filed. There doesn't seem
to be any monitoring of these, and unlike FTBFS bugs, they're not
grounds for removing packages from the distro.
Actually they can be...
FESCo approved a policy around this:
https://pagure.io/fesco/issue/1935
https://pagure.io/fesco/issue/2090
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
We just don't currently have scripting to announce and do this.
I don't want to put blame on anyone for this, of course - if it
were
easy to fix we would have done it already. My understanding is that a
lot of the problems I described above are due to lack of capacity to
perform the work associated. Asking the folks performing
security-related tasks in the distro - who are already overloaded - to
perform even more work does not strike me as a good idea. There needs
to be an easy way for them to query what versions of what packages are
present in Fedora - anywhere in Fedora - and file bugs against all of
them individually such that they reach the correct maintainers without
additional triage.
Thanks,
--Robbie
1: Often, even knowing that CVEs exist also requires the maintainer to
be paying attention to upstream development. This is because tracker
bugs are often missing, and usually late when they are created - in
many cases, after the issue in question has already been fixed.
yeah, but keep in mind that this is done as a 'above and beyond' by Red
Hat Product security.
kevin
11:42 a.m.
On Thu, Dec 19, 2019 at 12:19:39PM -0800, Kevin Fenzi wrote:
On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote:
> David Cantrell <dcantrell(a)redhat.com> writes:
...snip...
> > I would like to see modules have a stronger policy around tracking and
> > handling CVEs. At the very least, what Fedora already does for
> > regular packages.
>
> I would like this as well, but don't think "what Fedora already does for
> regular packages" is sufficient here. To criticize process (and only
> process, not people) for a moment here:
Just a note: Fedora doesn't do anything currently for regular packages.
Red Hat Product Security opens bugs for CVES that are public for Fedora.
I'd like to thank them for this tedious and very helpfull work.
Noted. As stated in my reply to Robbie's post, I think defining more of a CVE
process is worth a separate discussion. I do appreciate the work of the Red
Hat Product Security team, but with modules we are exponentially increasing
the risk here and I feel Fedora needs a more defined policy for CVE handling.
> Right now, the impetus for CVEs to be fixed[1] comes solely from
the
> maintainer. Unless the CVE becomes a buzzword issue with a name and
> logo (Heartbleed has already been mentioned upthread), there are
> basically no consequences to not fixing CVEs in one's packages until
> non-responsive maintainer bugs start getting filed. There doesn't seem
> to be any monitoring of these, and unlike FTBFS bugs, they're not
> grounds for removing packages from the distro.
Actually they can be...
FESCo approved a policy around this:
https://pagure.io/fesco/issue/1935
https://pagure.io/fesco/issue/2090
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
We just don't currently have scripting to announce and do this.
> I don't want to put blame on anyone for this, of course - if it were
> easy to fix we would have done it already. My understanding is that a
> lot of the problems I described above are due to lack of capacity to
> perform the work associated. Asking the folks performing
> security-related tasks in the distro - who are already overloaded - to
> perform even more work does not strike me as a good idea. There needs
> to be an easy way for them to query what versions of what packages are
> present in Fedora - anywhere in Fedora - and file bugs against all of
> them individually such that they reach the correct maintainers without
> additional triage.
>
> Thanks,
> --Robbie
>
> 1: Often, even knowing that CVEs exist also requires the maintainer to
> be paying attention to upstream development. This is because tracker
> bugs are often missing, and usually late when they are created - in
> many cases, after the issue in question has already been fixed.
yeah, but keep in mind that this is done as a 'above and beyond' by Red
Hat Product security.
kevin
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
11:39 a.m.
On Wed, Dec 18, 2019 at 02:52:03PM -0500, Robbie Harwood wrote:
David Cantrell <dcantrell(a)redhat.com> writes:
> On Tue, Dec 17, 2019 at 11:21:45PM +0100, Miro Hrončok wrote:
>> On 17. 12. 19 21:57, David Cantrell wrote:
>>> 1) Are modules allowed to bundle packages that are provided by and
>>> currently maintained in the base system? Are there are restrictions
>>> to what a module can bundle (e.g., can a module bundle glibc)?
>>
>> I am not aware of any policy against modularizing existing packages.
>> Modular maintainers can module-bundle glibc. OTOH I don't know all
>> the policies.
>>
>> There is a policy for making a default modular stream: if it
>> overrides existing non-modular packages, it requires FESCo
>> approval. So far this has not been retroactive and the ant and maven
>> default modular streams do that.
>>
>> See also https://pagure.io/modularity/issue/170
>
> I feel there should be some restrictions around this bundling. glibc
> is a good example, but I am also concerned about the ability for
> modules to bundle security-libraries which could lead to a system with
> multiple different versions of a shared library on a system.
>
> With protobuf as the example again, we saw that the eclipse module's
> bundled protobuf took the lead in depsolving and dnf upgraded systems
> to that regardless of whether or not they had the module installed.
> So the multiple shared library scenario is only a concern in a world
> where we do parallel installability. Putting that aside for the
> moment, I'd like to refine the above concern:
>
> We should have some restrictions about packages that can and cannot be
> bundled with modules. This may require defining some sort of criteria
> or a set of core packages or some other test. Likewise, packages like
> openssl need some thought because while we do not currently do
> parallel installability, even having parallel availability still means
> we could have multiple different builds of an openssl package. There
> should be a plan around that because having that be unbounded sets us
> up for a lot of panic mode work should there be something like
> Heartbleed happen again.
Agreed. Especially with the work we do on crypto deprecations, I worry
that there will be strong temptation to create bundled crypto packages
that "make the old workflow work again" or so.
That's exactly my thought as well.
>>> 2) Using protobuf as an example, if a bug is found by a
user and
>>> they happen to deduce that the error is in protobuf, how do they
>>> file a bug? Do they file the bug against protobuf if the bundled
>>> one from the module has the issue? What maintainer is on the hook
>>> for handling that bug report? My assumption here is that the module
>>> maintainer is ultimately responsible for everything they bundle.
>>> Another concern I see here is we are opening ourselves up for N+1
>>> different builds of protobuf where N is the number of modules
>>> installed on a system and all of them could have protobuf bundled.
>>
>> I would assume they file it in protobuf. They haven't opted for any
>> module and they don't know it's modular, really. The non-modular
>> maintainer may deduce from the NERVA that it is modular build and do
>> some nontrivial digging to figure out where is this package coming
>> from - if they can, they will reassign the bug report to that module
>> component.
>>
>> I agree that the modular maintainers are ultimately responsible for
>> everything they bundle.
>>
>> I share your concerns.
>
> Filing against protobuf makes sense, but then we get to the
> maintainers. The protobuf maintainer did not know eclipse bundled
> protobuf. Without being involved in that decision, I think it's
> unfair to expect package maintainers to be the triage point for all
> incoming bugs, either regular packages or bundled packages. That's
> just not going to really scale very well and will result in
> frustration among package maintainers and users.
>
> Maybe if a module bundles a package, the module maintainer also
> becomes a co-maintainer on the bundled package?
This worries me because I don't think we have sufficiently fine-grained
commit controls since the pkgdb retirement. While I would love to be
incorrect about this, I don't see a way to restrict what branches can be
committed to by those with access to a package - and I don't think it's
at all reasonable for someone who makes a module version of a package to
gain commit bits to all branches. (Especially without consent of the
existing maintainer(s).)
All reasonable concerns. I don't think we have the necessary controls in
place for this either. In my mind I was thinking a discussion like this would
involve both "do we think this is a good idea to implement" as well as
"how
would our tools need to change to allow that".
An important part of this is communication so that module maintainers know who
the regular package maintainer is (e.g., for coordinating work, etc) and that
regular package maintainers know what modules are bundling the package at
different points. I'm still not convinced this is a good workflow for all
software we ship, but may be an ok mechanism for large things. That is, be
the exception rather than the norm.
>>> 5) How are CVEs handled for packages that are also
bundled with a
>>> module?
>>
>> I don't think they are reported properly. Hence they are handled on
>> the modular maintainer's discretion.
>>
>> See also https://pagure.io/modularity/issue/169
>
> I would like to see modules have a stronger policy around tracking and
> handling CVEs. At the very least, what Fedora already does for
> regular packages.
I would like this as well, but don't think "what Fedora already does for
regular packages" is sufficient here. To criticize process (and only
process, not people) for a moment here:
Right now, the impetus for CVEs to be fixed[1] comes solely from the
maintainer. Unless the CVE becomes a buzzword issue with a name and
logo (Heartbleed has already been mentioned upthread), there are
basically no consequences to not fixing CVEs in one's packages until
non-responsive maintainer bugs start getting filed. There doesn't seem
to be any monitoring of these, and unlike FTBFS bugs, they're not
grounds for removing packages from the distro.
I don't want to put blame on anyone for this, of course - if it were
easy to fix we would have done it already. My understanding is that a
lot of the problems I described above are due to lack of capacity to
perform the work associated. Asking the folks performing
security-related tasks in the distro - who are already overloaded - to
perform even more work does not strike me as a good idea. There needs
to be an easy way for them to query what versions of what packages are
present in Fedora - anywhere in Fedora - and file bugs against all of
them individually such that they reach the correct maintainers without
additional triage.
Thanks,
--Robbie
1: Often, even knowing that CVEs exist also requires the maintainer to
be paying attention to upstream development. This is because tracker
bugs are often missing, and usually late when they are created - in
many cases, after the issue in question has already been fixed.
Sorry, I over-simplified my comment. My main concern here is that modules
are opening up a risk for security vulnerabilities and we lack the tools to
know what packages are at risk and whether or not users know if they are
vulnerable or not. I personally don't like this and want Fedora to provide me
with the tools to know where my software came from and what the versions are.
When I suggested "what Fedora does for regular packages", I was referring to
the work that everyone already does above and beyond. I think this is worth a
separate discussion. While security updates in Fedora are handled well now
and I trust the builds, it's due to the above and beyond work of maintainers
and not by some process we have in place. It's the process I would like to
capture because modules make this situation worse in my mind.
Using Heartbleed as an example again, right now if something of that scale
happened again I can trust that updates will be available for Fedora. But
what if we have 392 modules each with a different bundled version of openssl?
And what if only some of them are vulnerable to the new problem? Without any
kind of policy in place, what does that look like for the end user? Will
module maintainers also be aware of CVEs for packages they bundle? Will they
handle those updates? Should we expect them too? Your comments above touch
on this as well.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
3:09 a.m.
On 18. 12. 19 15:53, David Cantrell wrote:
Maybe if a module bundles a package, the module maintainer also becomes a
co-maintainer on the bundled package?
How this appears to work now:
1. If one bundles a package in a module they need to create a stream branch
(unless they bundle form master/f31 etc. which is probably possible, but I
haven't seen that happen much).
2. If they intent to push to the stream branch, they need ACLs.
3. Either they need to become a co-maintainer or they need to be provenpackagers
(for example, sgallagh has commit rights for python-django to be able to
maintain the 1.6 branch*, but mbooth has no commit rights in protobuf but is a
provenpackager).
I think that if somebody wants a stream branch in a package they should become
co-maintainers first. Using the provenpackager rights for this without talking
to the non-modular maintainer(s) is wrong. It goes against:
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
But OTOH, I don't like of the modular maintainer just becomes a co-miantainer
automatically, they should talk to the non-modular maintainers first. See also
https://pagure.io/modularity/issue/115
(* Side note: I believe sgallagh is also a provenpackager and yet he explicitly
has the commit rights set - and that is what I think makes sense - it signalizes
explicit consent.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:21 p.m.
On Tuesday, December 17, 2019 1:57:09 PM MST David Cantrell wrote:
With regard to the recent protobuf package issue and the eclipse
module, I
started wondering how bugs work with packages bundled in modules. That is,
packages that exist outside modules (e.g., protobuf) that end up bundled
with some module.
NOTE: It is very easy for module posts to quickly balloon out in to all
sorts of topics and stories. I would prefer that we keep this thread
related to the Subject above. Thanks.
The following are policy questions I came up with after the protobuf issue
happened:
1) Are modules allowed to bundle packages that are provided by and
currently maintained in the base system? Are there are restrictions to
what a module can bundle (e.g., can a module bundle glibc)?
2) Using protobuf as an example, if a bug is found by a user and they
happen to deduce that the error is in protobuf, how do they file a bug?
Do they file the bug against protobuf if the bundled one from the module
has the issue? What maintainer is on the hook for handling that bug report?
My assumption here is that the module maintainer is ultimately responsible
for everything they bundle. Another concern I see here is we are opening
ourselves up for N+1 different builds of protobuf where N is the number of
modules installed on a system and all of them could have protobuf bundled.
3) If a user files a bug against a module and the module maintainer triages
that to a bundled package, how is that handled? Who is maintaining the
bundled build of that package? Who is responsible for fixing it?
4) How can users determine what packages are installed from a module and
how can you see what, if any, module "owns" a package? I have been unable
to determine how to do this from dnf.
5) How are CVEs handled for packages that are also bundled with a module?
I have read as much as I can find about how things work right now with
modules, but that has been mostly the "how" and nothing around policy.
I also have to wonder whether or not there should be a policy for modules
providing the same package names, or at least a policy such that two different
default default modules cannot provide the same package.
--
John M. Harris, Jr.
Splentity
8:55 a.m.
On Tue, Dec 17, 2019 at 05:21:36PM -0700, John M. Harris Jr wrote:
On Tuesday, December 17, 2019 1:57:09 PM MST David Cantrell wrote:
> With regard to the recent protobuf package issue and the eclipse module, I
> started wondering how bugs work with packages bundled in modules. That is,
> packages that exist outside modules (e.g., protobuf) that end up bundled
> with some module.
>
> NOTE: It is very easy for module posts to quickly balloon out in to all
> sorts of topics and stories. I would prefer that we keep this thread
> related to the Subject above. Thanks.
>
> The following are policy questions I came up with after the protobuf issue
> happened:
>
> 1) Are modules allowed to bundle packages that are provided by and
> currently maintained in the base system? Are there are restrictions to
> what a module can bundle (e.g., can a module bundle glibc)?
>
> 2) Using protobuf as an example, if a bug is found by a user and they
> happen to deduce that the error is in protobuf, how do they file a bug?
> Do they file the bug against protobuf if the bundled one from the module
> has the issue? What maintainer is on the hook for handling that bug report?
> My assumption here is that the module maintainer is ultimately responsible
> for everything they bundle. Another concern I see here is we are opening
> ourselves up for N+1 different builds of protobuf where N is the number of
> modules installed on a system and all of them could have protobuf bundled.
>
> 3) If a user files a bug against a module and the module maintainer triages
> that to a bundled package, how is that handled? Who is maintaining the
> bundled build of that package? Who is responsible for fixing it?
> 4) How can users determine what packages are installed from a module and
> how can you see what, if any, module "owns" a package? I have been unable
> to determine how to do this from dnf.
>
> 5) How are CVEs handled for packages that are also bundled with a module?
>
> I have read as much as I can find about how things work right now with
> modules, but that has been mostly the "how" and nothing around policy.
I also have to wonder whether or not there should be a policy for modules
providing the same package names, or at least a policy such that two different
default default modules cannot provide the same package.
That is a reasonable question. If modules ultimately provide a repo to dnf
for depsolving, then through the repodata and repo cost values, I would expect
dnf to be able to resolve that down to one package to install. But that
requires coordination among all the bundled packages, their version numbers,
and their release numbers.
I can see the current situation easily leading to a module deciding to bump
the Epoch value on a bundled package to ensure that's the one that gets
installed on the system. That's not a good solution or a solution at all.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
6 a.m.
Dne 17. 12. 19 v 21:57 David Cantrell napsal(a):
With regard to the recent protobuf package issue and the eclipse
module, I
started wondering how bugs work with packages bundled in modules.
That is,
packages that exist outside modules (e.g., protobuf) that end up
bundled with
some module.
NOTE: It is very easy for module posts to quickly balloon out in to
all sorts
of topics and stories. I would prefer that we keep this thread
related to the
Subject above. Thanks.
The following are policy questions I came up with after the protobuf
issue
happened:
1) Are modules allowed to bundle packages that are provided by and
currently
maintained in the base system? Are there are restrictions to what a
module
can bundle (e.g., can a module bundle glibc)?
2) Using protobuf as an example, if a bug is found by a user and they
happen
to deduce that the error is in protobuf, how do they file a bug? Do
they file
the bug against protobuf if the bundled one from the module has the
issue?
What maintainer is on the hook for handling that bug report? My
assumption
here is that the module maintainer is ultimately responsible for
everything
they bundle. Another concern I see here is we are opening ourselves
up for
N+1 different builds of protobuf where N is the number of modules
installed on
a system and all of them could have protobuf bundled.
3) If a user files a bug against a module and the module maintainer
triages
that to a bundled package, how is that handled? Who is maintaining the
bundled build of that package? Who is responsible for fixing it?
These are two very interesting points.
Just FTR, for Red Hat Software Collections, we are (ab)using "Version"
BZ field to track the SCL version (e.g. [1]), which in module
terminology resembles stream. Maybe we could reuse something similar for
modules in Fedora.
Also, it is interesting that AFAIK, we have not yet dealt with issue
like this (i.e. reporting issues against specific streams) for RHEL8 yet.
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1757842
4) How can users determine what packages are installed from a module
and how
can you see what, if any, module "owns" a package? I have been unable to
determine how to do this from dnf.
5) How are CVEs handled for packages that are also bundled with a module?
I have read as much as I can find about how things work right now with
modules, but that has been mostly the "how" and nothing around policy.
Thanks,
6:35 a.m.
Vít Ondruch wrote:
Also, it is interesting that AFAIK, we have not yet dealt with issue
like this (i.e. reporting issues against specific streams) for RHEL8 yet.
How can Modularity have been forced to production in both Fedora and RHEL
without something as basic as this figured out? Inability to report bugs
against the software you ship should be considered a showstopper, ESPECIALLY
for a distribution calling itself "Enterprise".
It is also no surprise that you are not seeing any complaints about
Modularity if you do not provide a place to report them to.
Kevin Kofler
7:29 a.m.
On ke, 18 joulu 2019, Kevin Kofler wrote:
Vít Ondruch wrote:
> Also, it is interesting that AFAIK, we have not yet dealt with issue
> like this (i.e. reporting issues against specific streams) for RHEL8 yet.
How can Modularity have been forced to production in both Fedora and RHEL
without something as basic as this figured out? Inability to report bugs
against the software you ship should be considered a showstopper, ESPECIALLY
for a distribution calling itself "Enterprise".
It is also no surprise that you are not seeing any complaints about
Modularity if you do not provide a place to report them to.
You still report against a particular package. Hopefully, also providing
the package version (rpm -q). Since that output for a modular package
uniquely identifies a module build, information about the exact stream can
be looked up from the MBS.
For example, if you have thunderbird-68.3.1-1.module_f31+7237+88bd0ff3
installed and want to report its issues, that would be module build
7237:
https://release-engineering.github.io/mbs-ui/module/7237
Which has NSVC thunderbird:master:3120191217131320:802922d1, e.g.
thunderbird:master stream of the thunderbird module.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
8:34 a.m.
On Wed, Dec 18, 2019, 14:29 Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
On ke, 18 joulu 2019, Kevin Kofler wrote:
>Vít Ondruch wrote:
>> Also, it is interesting that AFAIK, we have not yet dealt with issue
>> like this (i.e. reporting issues against specific streams) for RHEL8
yet.
>
>How can Modularity have been forced to production in both Fedora and RHEL
>without something as basic as this figured out? Inability to report bugs
>against the software you ship should be considered a showstopper,
ESPECIALLY
>for a distribution calling itself "Enterprise".
>
>It is also no surprise that you are not seeing any complaints about
>Modularity if you do not provide a place to report them to.
(snip)
You still report against a particular package. Hopefully, also
providing
the package version (rpm -q). Since that output for a modular package
uniquely identifies a module build, information about the exact stream can
be looked up from the MBS.
For example, if you have thunderbird-68.3.1-1.module_f31+7237+88bd0ff3
installed and want to report its issues, that would be module build
7237:
https://release-engineering.github.io/mbs-ui/module/7237
Which has NSVC thunderbird:master:3120191217131320:802922d1, e.g.
thunderbird:master stream of the thunderbird module.
And how should users know how to do that? Every UI and workflow and tool we
have in fedora defaults to reporting bugz against "Fedora" product with
"$SRCNAME" component. Which is for non-modular packages, and assigns to
non-modular maintainers.
Fabio
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
9:04 a.m.
On Wed, Dec 18, 2019 at 03:34:34PM +0100, Fabio Valentini wrote:
On Wed, Dec 18, 2019, 14:29 Alexander Bokovoy
<abokovoy(a)redhat.com> wrote:
> On ke, 18 joulu 2019, Kevin Kofler wrote:
> >Vít Ondruch wrote:
> >> Also, it is interesting that AFAIK, we have not yet dealt with issue
> >> like this (i.e. reporting issues against specific streams) for RHEL8
> yet.
> >
> >How can Modularity have been forced to production in both Fedora and RHEL
> >without something as basic as this figured out? Inability to report bugs
> >against the software you ship should be considered a showstopper,
> ESPECIALLY
> >for a distribution calling itself "Enterprise".
> >
> >It is also no surprise that you are not seeing any complaints about
> >Modularity if you do not provide a place to report them to.
>
(snip)
> You still report against a particular package. Hopefully, also providing
> the package version (rpm -q). Since that output for a modular package
> uniquely identifies a module build, information about the exact stream can
> be looked up from the MBS.
>
> For example, if you have thunderbird-68.3.1-1.module_f31+7237+88bd0ff3
> installed and want to report its issues, that would be module build
> 7237:
>
> https://release-engineering.github.io/mbs-ui/module/7237
>
> Which has NSVC thunderbird:master:3120191217131320:802922d1, e.g.
> thunderbird:master stream of the thunderbird module.
>
And how should users know how to do that? Every UI and workflow and tool we
have in fedora defaults to reporting bugz against "Fedora" product with
"$SRCNAME" component. Which is for non-modular packages, and assigns to
non-modular maintainers.
For non-technical users this process is not easily discoverable and too
complicated. For technical users it leaves too many open questions since the
reporting it mixed in with regular packages.
This does tie by to one of my original questions about how do users determine
what modules are installed and what packages are provided by those modules.
We lack tooling for that.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
9:32 a.m.
On ke, 18 joulu 2019, David Cantrell wrote:
On Wed, Dec 18, 2019 at 03:34:34PM +0100, Fabio Valentini wrote:
>On Wed, Dec 18, 2019, 14:29 Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
>
>>On ke, 18 joulu 2019, Kevin Kofler wrote:
>>>Vít Ondruch wrote:
>>>> Also, it is interesting that AFAIK, we have not yet dealt with issue
>>>> like this (i.e. reporting issues against specific streams) for RHEL8
>>yet.
>>>
>>>How can Modularity have been forced to production in both Fedora and RHEL
>>>without something as basic as this figured out? Inability to report bugs
>>>against the software you ship should be considered a showstopper,
>>ESPECIALLY
>>>for a distribution calling itself "Enterprise".
>>>
>>>It is also no surprise that you are not seeing any complaints about
>>>Modularity if you do not provide a place to report them to.
>>
>
>(snip)
>
>
>>You still report against a particular package. Hopefully, also providing
>>the package version (rpm -q). Since that output for a modular package
>>uniquely identifies a module build, information about the exact stream can
>>be looked up from the MBS.
>>
>>For example, if you have thunderbird-68.3.1-1.module_f31+7237+88bd0ff3
>>installed and want to report its issues, that would be module build
>>7237:
>>
>>https://release-engineering.github.io/mbs-ui/module/7237
>>
>>Which has NSVC thunderbird:master:3120191217131320:802922d1, e.g.
>>thunderbird:master stream of the thunderbird module.
>>
>
>And how should users know how to do that? Every UI and workflow and tool we
>have in fedora defaults to reporting bugz against "Fedora" product with
>"$SRCNAME" component. Which is for non-modular packages, and assigns to
>non-modular maintainers.
For non-technical users this process is not easily discoverable and too
complicated. For technical users it leaves too many open questions since the
reporting it mixed in with regular packages.
This does tie by to one of my original questions about how do users determine
what modules are installed and what packages are provided by those modules.
We lack tooling for that.
Right. Tools are missing. It would be good to have this integrated with
abrtd, for example. And may be have some way on a bugzilla side to pick
up data based on an rpm package name, pulling most of the metadata it
could from MBS systems.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
9:02 a.m.
On Wed, Dec 18, 2019 at 03:29:14PM +0200, Alexander Bokovoy wrote:
On ke, 18 joulu 2019, Kevin Kofler wrote:
>Vít Ondruch wrote:
>>Also, it is interesting that AFAIK, we have not yet dealt with issue
>>like this (i.e. reporting issues against specific streams) for RHEL8 yet.
>
>How can Modularity have been forced to production in both Fedora and RHEL
>without something as basic as this figured out? Inability to report bugs
>against the software you ship should be considered a showstopper, ESPECIALLY
>for a distribution calling itself "Enterprise".
>
>It is also no surprise that you are not seeing any complaints about
>Modularity if you do not provide a place to report them to.
You still report against a particular package. Hopefully, also providing
the package version (rpm -q). Since that output for a modular package
uniquely identifies a module build, information about the exact stream can
be looked up from the MBS.
For example, if you have thunderbird-68.3.1-1.module_f31+7237+88bd0ff3
installed and want to report its issues, that would be module build
7237:
https://release-engineering.github.io/mbs-ui/module/7237
Which has NSVC thunderbird:master:3120191217131320:802922d1, e.g.
thunderbird:master stream of the thunderbird module.
This example makes sense to me and I think it is appropriate that a bug in the
Thunderbird module would be reported against the thunderbird package. But I
am talking about bundled packages inside the module. If the thunderbird
module bundles zlib and there's a bug in that both correctly and to the
correct party.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
9 a.m.
On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
Dne 17. 12. 19 v 21:57 David Cantrell napsal(a):
> With regard to the recent protobuf package issue and the eclipse
> module, I
> started wondering how bugs work with packages bundled in modules.
> That is,
> packages that exist outside modules (e.g., protobuf) that end up
> bundled with
> some module.
>
> NOTE: It is very easy for module posts to quickly balloon out in to
> all sorts
> of topics and stories. I would prefer that we keep this thread
> related to the
> Subject above. Thanks.
>
> The following are policy questions I came up with after the protobuf
> issue
> happened:
>
> 1) Are modules allowed to bundle packages that are provided by and
> currently
> maintained in the base system? Are there are restrictions to what a
> module
> can bundle (e.g., can a module bundle glibc)?
>
> 2) Using protobuf as an example, if a bug is found by a user and they
> happen
> to deduce that the error is in protobuf, how do they file a bug? Do
> they file
> the bug against protobuf if the bundled one from the module has the
> issue?
> What maintainer is on the hook for handling that bug report? My
> assumption
> here is that the module maintainer is ultimately responsible for
> everything
> they bundle. Another concern I see here is we are opening ourselves
> up for
> N+1 different builds of protobuf where N is the number of modules
> installed on
> a system and all of them could have protobuf bundled.
>
> 3) If a user files a bug against a module and the module maintainer
> triages
> that to a bundled package, how is that handled? Who is maintaining the
> bundled build of that package? Who is responsible for fixing it?
These are two very interesting points.
Just FTR, for Red Hat Software Collections, we are (ab)using "Version"
BZ field to track the SCL version (e.g. [1]), which in module
terminology resembles stream. Maybe we could reuse something similar for
modules in Fedora.
I think Fedora would have to do something like that to indicate module
ownership in a bug. The Version field requires BZ maintenance for that list
which could mean that each module version would need a new entry in that
list. At least that's how I understand that BZ field the last time I looked
at it.
We could come up with syntax and place it in one of the Whiteboard fields.
Something like module=eclipse;ver=X.Y.Z
That would probably get ugly real fast.
Also, it is interesting that AFAIK, we have not yet dealt with issue
like this (i.e. reporting issues against specific streams) for RHEL8 yet.
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1757842
>
> 4) How can users determine what packages are installed from a module
> and how
> can you see what, if any, module "owns" a package? I have been unable to
> determine how to do this from dnf.
>
> 5) How are CVEs handled for packages that are also bundled with a module?
>
> I have read as much as I can find about how things work right now with
> modules, but that has been mostly the "how" and nothing around policy.
>
> Thanks,
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
5:29 p.m.
On 19/12/19 01:00, David Cantrell wrote:
On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
> Just FTR, for Red Hat Software Collections, we are (ab)using "Version"
> BZ field to track the SCL version (e.g. [1]), which in module
> terminology resembles stream. Maybe we could reuse something similar for
> modules in Fedora.
I think Fedora would have to do something like that to indicate module
ownership in a bug. The Version field requires BZ maintenance for that
list
which could mean that each module version would need a new entry in that
list. At least that's how I understand that BZ field the last time I
looked
at it.
We could come up with syntax and place it in one of the Whiteboard fields.
Something like module=eclipse;ver=X.Y.Z
That would probably get ugly real fast.
The version field is for the version of the product the bug is in, it
shouldn't be abused for things that aren't that.
A couple of alternative approaches:
1: A new custom field with the modules/streams in it. User opens bug
against component, maintainer sets the CF if required.
Pros: Easy to use. Could be a multi-select if it affects multiple streams.
Cons: Might not scale to a large number of module streams. Doesn't allow
automated change of assignee/etc. Not easy to limit CF values to
specific components.
2: Use sub-components for the modules/streams. User opens a bug against
the component and the maintainer can move the bug to a module sub
component if required.
Pros: easy to use, automated assignee/qe/etc, easy to limit modules and
streams to specific components. Unlikely to require significant change
to current workflows or tools.
Cons: Setting up the sub-components, this could probably be automated on
the Fedora Infra side. Not multi-select so you'd need to clone bugs if
you wanted to track progress for multiple-streams.
Cheers, Jeff.
2:31 a.m.
Dne 19. 12. 19 v 0:29 Jeff Fearn napsal(a):
On 19/12/19 01:00, David Cantrell wrote:
> On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
>> Just FTR, for Red Hat Software Collections, we are (ab)using "Version"
>> BZ field to track the SCL version (e.g. [1]), which in module
>> terminology resembles stream. Maybe we could reuse something similar for
>> modules in Fedora.
> I think Fedora would have to do something like that to indicate module
> ownership in a bug. The Version field requires BZ maintenance for that
> list
> which could mean that each module version would need a new entry in that
> list. At least that's how I understand that BZ field the last time I
> looked
> at it.
>
> We could come up with syntax and place it in one of the Whiteboard fields.
> Something like module=eclipse;ver=X.Y.Z
>
> That would probably get ugly real fast.
The version field is for the version of the product the bug is in, it
shouldn't be abused for things that aren't that.
A couple of alternative approaches:
1: A new custom field with the modules/streams in it. User opens bug
against component, maintainer sets the CF if required.
Pros: Easy to use. Could be a multi-select if it affects multiple streams.
Cons: Might not scale to a large number of module streams. Doesn't allow
automated change of assignee/etc. Not easy to limit CF values to
specific components.
2: Use sub-components for the modules/streams. User opens a bug against
the component and the maintainer can move the bug to a module sub
component if required.
Are sub-components used in our BZ already? Do you have some example?
Vít
Pros: easy to use, automated assignee/qe/etc, easy to limit modules and
streams to specific components. Unlikely to require significant change
to current workflows or tools.
Cons: Setting up the sub-components, this could probably be automated on
the Fedora Infra side. Not multi-select so you'd need to clone bugs if
you wanted to track progress for multiple-streams.
Cheers, Jeff.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
3:36 a.m.
On 19/12/2019 6:31 pm, Vít Ondruch wrote:
Dne 19. 12. 19 v 0:29 Jeff Fearn napsal(a):
> On 19/12/19 01:00, David Cantrell wrote:
>> On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
>>> Just FTR, for Red Hat Software Collections, we are (ab)using
"Version"
>>> BZ field to track the SCL version (e.g. [1]), which in module
>>> terminology resembles stream. Maybe we could reuse something similar for
>>> modules in Fedora.
>> I think Fedora would have to do something like that to indicate module
>> ownership in a bug. The Version field requires BZ maintenance for that
>> list
>> which could mean that each module version would need a new entry in that
>> list. At least that's how I understand that BZ field the last time I
>> looked
>> at it.
>>
>> We could come up with syntax and place it in one of the Whiteboard fields.
>> Something like module=eclipse;ver=X.Y.Z
>>
>> That would probably get ugly real fast.
> The version field is for the version of the product the bug is in, it
> shouldn't be abused for things that aren't that.
>
> A couple of alternative approaches:
>
> 1: A new custom field with the modules/streams in it. User opens bug
> against component, maintainer sets the CF if required.
>
> Pros: Easy to use. Could be a multi-select if it affects multiple streams.
>
> Cons: Might not scale to a large number of module streams. Doesn't allow
> automated change of assignee/etc. Not easy to limit CF values to
> specific components.
>
> 2: Use sub-components for the modules/streams. User opens a bug against
> the component and the maintainer can move the bug to a module sub
> component if required.
Are sub-components used in our BZ already? Do you have some example?
RHEL has been using them for a long time for the kernel, but a less
dramatic example is the Bugzilla product.
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
Cheers, Jeff.
6:46 a.m.
Dne 19. 12. 19 v 10:36 Jeff Fearn napsal(a):
On 19/12/2019 6:31 pm, Vít Ondruch wrote:
> Dne 19. 12. 19 v 0:29 Jeff Fearn napsal(a):
>> On 19/12/19 01:00, David Cantrell wrote:
>>> On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
>>>> Just FTR, for Red Hat Software Collections, we are (ab)using
"Version"
>>>> BZ field to track the SCL version (e.g. [1]), which in module
>>>> terminology resembles stream. Maybe we could reuse something similar for
>>>> modules in Fedora.
>>> I think Fedora would have to do something like that to indicate module
>>> ownership in a bug. The Version field requires BZ maintenance for that
>>> list
>>> which could mean that each module version would need a new entry in that
>>> list. At least that's how I understand that BZ field the last time I
>>> looked
>>> at it.
>>>
>>> We could come up with syntax and place it in one of the Whiteboard fields.
>>> Something like module=eclipse;ver=X.Y.Z
>>>
>>> That would probably get ugly real fast.
>> The version field is for the version of the product the bug is in, it
>> shouldn't be abused for things that aren't that.
>>
>> A couple of alternative approaches:
>>
>> 1: A new custom field with the modules/streams in it. User opens bug
>> against component, maintainer sets the CF if required.
>>
>> Pros: Easy to use. Could be a multi-select if it affects multiple streams.
>>
>> Cons: Might not scale to a large number of module streams. Doesn't allow
>> automated change of assignee/etc. Not easy to limit CF values to
>> specific components.
>>
>> 2: Use sub-components for the modules/streams. User opens a bug against
>> the component and the maintainer can move the bug to a module sub
>> component if required.
>
> Are sub-components used in our BZ already? Do you have some example?
RHEL has been using them for a long time for the kernel, but a less
dramatic example is the Bugzilla product.
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS...
Interesting. Thx for the example. Not that it makes the decision which
way would I prefer any easier ;)
Vít
Cheers, Jeff.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
2:22 p.m.
On Thu, Dec 19, 2019 at 09:29:36AM +1000, Jeff Fearn wrote:
On 19/12/19 01:00, David Cantrell wrote:
> On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
>> Just FTR, for Red Hat Software Collections, we are (ab)using
"Version"
>> BZ field to track the SCL version (e.g. [1]), which in module
>> terminology resembles stream. Maybe we could reuse something similar for
>> modules in Fedora.
>
> I think Fedora would have to do something like that to indicate module
> ownership in a bug. The Version field requires BZ maintenance for that
> list
> which could mean that each module version would need a new entry in that
> list. At least that's how I understand that BZ field the last time I
> looked
> at it.
>
> We could come up with syntax and place it in one of the Whiteboard fields.
> Something like module=eclipse;ver=X.Y.Z
>
> That would probably get ugly real fast.
The version field is for the version of the product the bug is in, it
shouldn't be abused for things that aren't that.
A couple of alternative approaches:
1: A new custom field with the modules/streams in it. User opens bug
against component, maintainer sets the CF if required.
Pros: Easy to use. Could be a multi-select if it affects multiple streams.
Cons: Might not scale to a large number of module streams. Doesn't allow
automated change of assignee/etc. Not easy to limit CF values to
specific components.
2: Use sub-components for the modules/streams. User opens a bug against
the component and the maintainer can move the bug to a module sub
component if required.
Pros: easy to use, automated assignee/qe/etc, easy to limit modules and
streams to specific components. Unlikely to require significant change
to current workflows or tools.
Cons: Setting up the sub-components, this could probably be automated on
the Fedora Infra side. Not multi-select so you'd need to clone bugs if
you wanted to track progress for multiple-streams.
Isn't this what the module component's are for?
Or do people think that it would be confusing to have a bug in say
protobuf filed against eclipse module?
kevin
4:12 p.m.
On 20/12/19 06:22, Kevin Fenzi wrote:
On Thu, Dec 19, 2019 at 09:29:36AM +1000, Jeff Fearn wrote:
> On 19/12/19 01:00, David Cantrell wrote:
>> On Wed, Dec 18, 2019 at 01:00:03PM +0100, Vít Ondruch wrote:
>>> Just FTR, for Red Hat Software Collections, we are (ab)using
"Version"
>>> BZ field to track the SCL version (e.g. [1]), which in module
>>> terminology resembles stream. Maybe we could reuse something similar for
>>> modules in Fedora.
>>
>> I think Fedora would have to do something like that to indicate module
>> ownership in a bug. The Version field requires BZ maintenance for that
>> list
>> which could mean that each module version would need a new entry in that
>> list. At least that's how I understand that BZ field the last time I
>> looked
>> at it.
>>
>> We could come up with syntax and place it in one of the Whiteboard fields.
>> Something like module=eclipse;ver=X.Y.Z
>>
>> That would probably get ugly real fast.
>
> The version field is for the version of the product the bug is in, it
> shouldn't be abused for things that aren't that.
>
> A couple of alternative approaches:
>
> 1: A new custom field with the modules/streams in it. User opens bug
> against component, maintainer sets the CF if required.
>
> Pros: Easy to use. Could be a multi-select if it affects multiple streams.
>
> Cons: Might not scale to a large number of module streams. Doesn't allow
> automated change of assignee/etc. Not easy to limit CF values to
> specific components.
>
> 2: Use sub-components for the modules/streams. User opens a bug against
> the component and the maintainer can move the bug to a module sub
> component if required.
>
> Pros: easy to use, automated assignee/qe/etc, easy to limit modules and
> streams to specific components. Unlikely to require significant change
> to current workflows or tools.
>
> Cons: Setting up the sub-components, this could probably be automated on
> the Fedora Infra side. Not multi-select so you'd need to clone bugs if
> you wanted to track progress for multiple-streams.
Isn't this what the module component's are for?
Or do people think that it would be confusing to have a bug in say
protobuf filed against eclipse module?
I think ATM the problem is there is one component for a module so if
that module has 50 packages in it how do you report a bug against a
specific package in it?
You could modify suggestion 2 so a module component has a sub-component
for each package in it, technically it's pretty much the same. It is a
little more work as you have to move bugs, but it may have some benefits
in reporting and perhaps some maintainers would feel better about
handing off bugs for modules.
It probably comes down to your mental model of how modules and packages
relate and how that is best represented in a tree structure. Technically
there is little difference, one way may be more user friendly.
e.g.
Fedora
--protobuf
----eclipse-module
------stream1
Vs
Fedora
--eclipse-module
----stream1
------protobuf
I added streams as it will probably be necessary.
I'd lean towards the second myself, because it fits better with my
mental map of how it all relates. YMMMV (Your Mental Map May Very ;))
Cheers, Jeff.
12:21 p.m.
On Fri, Dec 20, 2019 at 08:12:26AM +1000, Jeff Fearn wrote:
I think ATM the problem is there is one component for a module so if
that module has 50 packages in it how do you report a bug against a
specific package in it?
Well, since one person or group "owns" the module, I would just expect
anything reported against that module would be fine. Of course if
there's 50 bugs and people need more fine grained control that could be
a problem, but right now at least I don't think it would be.
You could modify suggestion 2 so a module component has a sub-component
for each package in it, technically it's pretty much the same. It is a
little more work as you have to move bugs, but it may have some benefits
in reporting and perhaps some maintainers would feel better about
handing off bugs for modules.
Yeah, it seems like a lot of work for not much gain right now, but
perhaps it will change when/if modules get more uptake.
It probably comes down to your mental model of how modules and packages
relate and how that is best represented in a tree structure. Technically
there is little difference, one way may be more user friendly.
e.g.
Fedora
--protobuf
----eclipse-module
------stream1
Vs
Fedora
--eclipse-module
----stream1
------protobuf
I added streams as it will probably be necessary.
I'd lean towards the second myself, because it fits better with my
mental map of how it all relates. YMMMV (Your Mental Map May Very ;))
Cheers, Jeff.
Yeah, likely it will come down to what module maintainers expect/want.
kevin
6:13 a.m.
On 2019-12-17, David Cantrell <dcantrell(a)redhat.com> wrote:
4) How can users determine what packages are installed from a module
and how
can you see what, if any, module "owns" a package? I have been unable to
determine how to do this from dnf.
By asking dnf. perl-libs-5.30.1-449.fc32.x86_64 is a non-modular package:
# dnf module provides perl-libs-5.30.1-449.fc32.x86_64
Last metadata expiration check: 0:00:54 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64 is a modular package:
# dnf module provides perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64
Last metadata expiration check: 0:01:01 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-4:5.30.1-449.module_f32+7155+1847c895.x86_64
Module : perl:5.30:3220191129151030:35f641a4:x86_64
Profiles :
Repo : rawhide-modular
Summary : Practical Extraction and Report Language
-- Petr
6:48 a.m.
On 19. 12. 19 13:13, Petr Pisar wrote:
On 2019-12-17, David Cantrell <dcantrell(a)redhat.com> wrote:
> 4) How can users determine what packages are installed from a module and how
> can you see what, if any, module "owns" a package? I have been unable to
> determine how to do this from dnf.
>
By asking dnf. perl-libs-5.30.1-449.fc32.x86_64 is a non-modular package:
# dnf module provides perl-libs-5.30.1-449.fc32.x86_64
Last metadata expiration check: 0:00:54 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64 is a modular package:
# dnf module provides perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64
Last metadata expiration check: 0:01:01 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-4:5.30.1-449.module_f32+7155+1847c895.x86_64
Module : perl:5.30:3220191129151030:35f641a4:x86_64
Profiles :
Repo : rawhide-modular
Summary : Practical Extraction and Report Language
Neat! This gives all such installed packages:
# dnf module provides $(rpm -qa)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:05 p.m.
On Thu, 2019-12-19 at 12:13 +0000, Petr Pisar wrote:
On 2019-12-17, David Cantrell <dcantrell(a)redhat.com> wrote:
> 4) How can users determine what packages are installed from a module and how
> can you see what, if any, module "owns" a package? I have been unable to
> determine how to do this from dnf.
>
By asking dnf. perl-libs-5.30.1-449.fc32.x86_64 is a non-modular package:
# dnf module provides perl-libs-5.30.1-449.fc32.x86_64
Last metadata expiration check: 0:00:54 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64 is a modular package:
# dnf module provides perl-libs-5.30.1-449.module_f32+7155+1847c895.x86_64
Last metadata expiration check: 0:01:01 ago on Thu 19 Dec 2019 01:06:07 PM CET.
perl-libs-4:5.30.1-449.module_f32+7155+1847c895.x86_64
Module : perl:5.30:3220191129151030:35f641a4:x86_64
Profiles :
Repo : rawhide-modular
Summary : Practical Extraction and Report Language
Hum, that's slightly odd syntax, isn't it? For rpm, `provides` means
"what does this RPM provide?" If you want to know "what provides this
capability?", you use `whatprovides`.
This seems like a `whatprovides` situation (the module provides the
package, the package doesn't provide the module) but we're using the
`provides` term :/
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1606
days inactive
1609
days old
27 comments
12 participants
participants (12)
-
Adam Williamson -
Alexander Bokovoy -
David Cantrell -
Fabio Valentini -
Jeff Fearn -
John M. Harris Jr -
Kevin Fenzi -
Kevin Kofler -
Miro Hrončok -
Petr Pisar -
Robbie Harwood -
Vít Ondruch