Re: Bug filing/triage/ownership policy for modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux