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.
signature.asc
Description: OpenPGP digital 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
