Hi Paul,
On 10.02.2024, Paul Wise wrote:
>
> I have been working on an enhancement[1] to reportbug that would allow
> interactive selection of port/arch usertags[2] and automatically set
> them in code paths that currently already ask for an architecture.
>
> I could use some design advice around the data for this.
>
> Currently the canonical definitions of the tags is the wiki page. The
> reportbug patchset has a function to convert the wiki page to Python
> objects. Then the reportbug code has a copy of the autogenerated Python
> objects. However, in keeping with the spirit of what I wrote on [3],
> I intend to switch that to storing a full copy of the raw source for
> the wiki page in the reportbug source and then doing the conversion
> at build time. There is similar data needed from [4] and [5].
>
> Since the copy of the data in reportbug would get outdated, I was
> thinking to download new copies when in online mode, cache them locally
> and then use them in preference to the copy in the reportbug package.
> This would happen only for code paths that do arch selection of course.
>
> Does this feature and approach to data caching sound reasonable?
Thank you for the suggestion.
Regarding the concept of downloading and caching external information
for use in some menu, there have also been thoughts to use something
similar for the release -> codename mapping that otherwise requires one
reportbug update for each stable release. However, it is not clear to me
that the benefits of the concept outweigh the costs.
Reportbug does not (yet) have any infrastructure for downloading
external content in online mode and caching it for use in later
reportbug invocations. Relying on something like this for certain
functionality requires trust that the corresponding online content will
be available reliably for a long time, without significant format
changes that will need code updates. Depending on the data there may be
a need for validation before use. The code needs to handle the cases
with and without cached data available. There are design questions on
where to store the data and who should be able to read and write there.
Nothing of this is insurmountable of course, but I do know that I do not
have time to help implement or even help maintain such new
functionality, and the same most likely also applies to Sandro. Are you
willing to take on maintainer responsibility for this?
Placing copies of the required content in the reportbug source as you
describe above seems like it would require less effort and sounds like a
reasonable solution to me. Maybe add some Makefile target to make it
easy to check if the content is still up to date?
Regards,
Nis
