-- Gwyn Ciesla she/her/hers ------------------------------------------------ in your fear, seek only peace in your fear, seek only love -d. bowie Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, January 27, 2021 4:04 PM, Otto Urpelainen <[email protected]> wrote: > Gwyn Ciesla via devel kirjoitti 27.1.2021 klo 19.40: > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Wednesday, January 27, 2021 11:33 AM, Vít Ondruch [email protected] > > wrote: > > > > > Dne 27. 01. 21 v 18:21 Gwyn Ciesla via devel napsal(a): > > > > > > > Question; What problem would be solved by removing fedpkg local that > > > > isn't addressed by documentation? > > > > > > It would ensure, that people are using stable and predictable > > > environment for Fedora development, keeping their system intact. > > > This proposal was triggered specifically by comment from this ticket [1]: > > > > > > I still have a workflow issue, because running `fedpkg > > > local`generates a > > > huge amount of files that, in most repositories, are not in > > > `.gitignore`, leading to mistakes like this. > > > > > > > > > This is simply not good user experience. > > > > If the user doesn't 'git add .', or has a correct .gitignore, this should > > be a non issue. > > Me being the quoted person with a workflow issue, I still think there is > a workflow issue. > > Setting .gitignore is possible of course, but rather annoying and > repetitive. Each package has its own repository, so there are a lot of > .gitignore files to configure. Also, the names that need to be ignored > depend on package version, so it is either messy globbing (or perhaps > regexing, if that is supported?) or updating every time version > increases. And 'fedpkg local' generates multiple files and directories > at repository root, yet another multiplier. Doing it manually every time > means spending time with ignore rules instead of packaging software. > > The other option of not using 'git add .' can also be described as > mentally filtering out all the irrelevant unstaged changes to find the > ones that should actually be added. That adds cognitive burden, slows > things down and leads to mistakes every now and then. It does not help > to say "do not make mistakes" if the task is inherently error-prone. > Such filtering is something a computer should do, which leads us back to > .gitignore. > > Perhaps a script could create the correct ignore globs for all > repositories in one go and that would be it, and have it in the template > for new repositories, too? Just an idea, perhaps not worth the effort > and complexity. > > It would help much if 'fedpkg local' would only generate anything in a > single directory with constant name - 'build' or whatever. > > (Oh, and for the original question about deprecating 'fedpkg local' - I > don't know. Before this discussion started, I was happily using 'fedpkg > local' and did not even know what mock was. I have to get in terms with > mock to form an opinion.) > The only times I use the git command in fedpkg is to merge between branches, or add/remove packages. If you're just doing changes to things already tracked, such as the spec, sources, patches, scripts, etc, fedpkg commit will add them for you. It also spits out a warning if you commit a spec with a Patch not tracked in git, which is nice. > Otto > > devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
