I do think the mailing list is severely misconfigured if it's paying any attention to dev branches. There's no reason it should be picking these commits up. If it is, let's fix it, not contort people's development processes and put still more restrictions and constraints on the already very limited time of a very small number of active developers. The only commits that should show up on the list are commits to master and perhaps a 3.9x branch if that's separate from master. I don't see how that doesn't fully address your issue.
I do generally delete my merged branches, and will occasionally delete some stale branches if I notice them. If you really feel like it, go through the repos and close out any stale branches without open PRs. However addressing open PRs is likely far more important than this, and time would be better spent on that. Stale branches simply don't cost very much at all: not CPU, not network bandwidth, not storage space, and not developer attention. The biggest problem I ever see from a stale branch is when I try to reuse a branch name I've already used in the past, and that's a pretty minor problem. There are far more important things to worry about with repo health than whether we use branches or forks. By far the most important is protecting the master branch and requiring all commits to go through PR and code review. That's essential for security. So far that's been blocked because the release tooling doesn't work with that. Once again the tail is wagging the dog. The release tooling should be fixed to support a secure repository. The repo should not be insecure to support old release tooling. But branches vs forks? That just seems like a complete non-issue to me not worth spending any time on. On Sat, Jan 4, 2025 at 7:06 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > Eliotte, > > don't get me wrong, but i have hard time to follow your reasoning: > - i posted how we all are _swamped_ by commit mails as canonical repo > is used for development > - you came back as "ML is misconfigured" > - then I asked you who will clean up these vaguely named branches you > create in canonical repo > - you came back with "branches as cheap" and "eventually project will > move off git" and "branches are how git works"? > > WAT? > > Thanks > T > > > On Sat, Jan 4, 2025 at 7:02 PM Elliotte Rusty Harold <elh...@ibiblio.org> > wrote: > > > > On Sat, Jan 4, 2025 at 4:20 PM Tamás Cservenák <ta...@cservenak.net> wrote: > > > > > > > > But to continue: what will happen to branches named like "mdo", > > > "apidoc", "copy", "null" etc in _cnonical maven repo_ if you go > > > missing? > > > > Branches are cheap, but the way these things work if these aren't > > cleaned up manually, eventually the project will move off git and > > github and throw away its history. All this has happened before, and > > all this will happen again . > > > > I've worked on enough Github hosted projects where all committers use > > branches and only branches to be reasonably confident that the problem > > is not the use of branches. Branches are how git works, and they work > > just fine. Maven does seem to have a lot of old tooling that needs > > work, though I'm not sure who has the knowledge or permissions to do > > that. But meanwhile adding more layers of rules for developers to > > follow instead of fixing broken tooling — like apparently whatever is > > sending commit messages to the mailing list — is not the way to go. > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
