Hi again, On Monday, October 14th, 2024 at 05:47, Bruno Haible <br...@clisp.org> wrote: > > > Michael Pratt wrote: > > > I believe many of you have read this already. > > > > https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html > > ... > > So hopefully we all agree that in general this should be done, > > > No, not everyone agrees with Simon's "de-vendoring". In particular, I disagree > with the "Pre-generated files (e.g., ./configure) should be re-generated" > part, Sorry, let me clarify... When I said "we all agree that in general this should be done", "this" refers to the topic of this thread and the goal of my (bad) patch, in that local modules file should be distributed, and not referring to all of the points made in the letter that I linked, but maybe some of them. I was just pointing out the similarity to some of the ideas there. Specifically, not that any re-generation "should" be done, but that users of the tarball should have the "ability" to. And like I said, I think we still agree on that... > because it invalidates the pre-release testing done on the tarball. not sure what you mean... doesn't it just increase the amount of operations tested? > > I'm glad that you are realizing the big mistake you were doing: Based on > discussions (only discussions, not even a committed patch!) with 1 single > package that uses gnulib, you wanted to modify the way gnulib works for > everyone. And that without even CCing the gnulib people!! > Big mistake? really? what happened? Nobody "accidentally" merged anything, everyone rightfully brought up a concern or questions... The mistake is that the patch itself is bad, not that I used a patch to start a discussion. And that's all this is so far, a discussion. So we are now just deciding whether making it automatic is appropriate, and if so, which tool should handle making it automatic. If an idea is simple, good, and universal enough, it absolutely can just apply to everyone. It's still up to you to decide, sending a patch doesn't make that decision for you. I assumed that I can trust the maintainers here to CC whoever they feel the need to CC (including those in the same organization) in order to gather the comments they need to make the right decisions... and yes, they did rightfully CC you... so is it a bad assumption? If there were any instructions on who I should CC, and when, I never saw them. > > Really the way to do such a thing in a socially acceptable way is to > 1. discuss with 1 package, > 2. get a patch committed for that 1 package, > 3. get in touch with the gnulib people to see whether it generalizes > maybe to some other packages, > 4. only if it turns out that it generalizes to all packages, come to > Automake and ask for an Automake change. It's really just a coincidence that I started experimenting with automake first. I don't intend to circumvent any channels of communication or procedures. I just happen to think of it before considering modifying gnulib-tool. This is before I knew whether sending a manual patch to coreutils would be helpful, or just a waste of time just in case someone else is already writing a patch at the same time I would be. I got "something" to work, and I wanted comments on what I had so far. Maybe I have some advice for myself... should I have added WIP (work in progress) to the subject? like "[WIP PATCH] ..."? Maybe if I had the vast knowledge and experience that you do, I would already know the appropriate process of which scope to attempt a change and follow the order every time, but I don't. I also cannot read your mind, so in order to find out whether I'm on the right track, you would have to see what I have... It would be nice if I can tell myself what's wrong with it, but that's not my job in a review process, it's yours. Please simply reject the patch and tell me why and what to try next plainly, and if I'm in the wrong place, where to go, after I had a chance to make my own arguments, whether they're good or bad. There's no need to relish in pointing out that I'm an amateur. -- MCP
[bug#73769] [PATCH] automake: distribute local gnulib directory modules
Michael Pratt via Patches for Automake Tue, 15 Oct 2024 07:45:00 -0700
- [bug#73769] [PATCH] automake: distr... Michael Pratt via Patches for Automake
- [bug#73769] [PATCH] automake: ... Karl Berry
- [bug#73769] [PATCH] automa... Collin Funk
- [bug#73769] [PATCH] automa... Bruno Haible via Patches for Automake
- [bug#73769] [PATCH] au... Michael Pratt via Patches for Automake
- [bug#73769] [PATCH... Bruno Haible via Patches for Automake
- [bug#73769] [... Michael Pratt via Patches for Automake
- [bug#7376... Bruno Haible via Patches for Automake
- [bug#73769] [PATCH... Karl Berry
- [bug#73769] [... Bruno Haible via Patches for Automake
- [bug#73769] [PATCH] automake: ... Nick Bowler
- [bug#73769] [PATCH] automake: ... Karl Berry