>>>>> "MM" == Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: MM> This might be an awful idea, but what if we have a proven packager MM> run a script to drop a README.md into each dist-git repo, with some MM> default template content (possibly including the %description)? Well, it's useful as a start, but I see some issues. If not maintained automatically: * The same data would now be kept in two places. * Extra work for package maintainers. * Would become outdated if maintainers don't feel like putting in extra work. * Would have to be set up by someone for new packages, or we're back to the same issue on a smaller scale. If maintained automatically: * we must take care that any updates provided by maintainers aren't overwritten. * Would have to run from cron and would not be particularly cheap (thousands of git pulls, re-substitutions and pushes) even though these rarely change. * Would be another task that infrastructure has to maintain, unless some provenpackager just does this occasionally from their own infrastructure, in which case we have to worry about how long that person is willing to perform the task. * The amount of scripting involved is almost certainly more than packaging python-markdown-macros(#) and hooking that up to pagure with a couple of custom functions to pull things from a database which already exists. # The markdown-macros thing I'm talking about is at https://github.com/wnielson/markdown-macros Of course I'm saying the latter with zero time now to actually do that, and maybe we'd want to use a different syntax or do something custom, but that module at least shows that it's relatively easy to do. I'm also assuming that the existing database containing package information is in some way accessible to the pagure instance. MM> This may be less work than special-casing something in Pagure. Probably slightly less work initially; I don't think pagure is so inflexible as to require some huge restructuring to permit this. Certainly quicker to get us to a state where we don't have blank landing pages. And even if we did the manual thing for a start, we can still talk about how we'd like it to work. - J< _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
