Le dim. 5 janv. 2025 à 15:49, Elliotte Rusty Harold <elh...@ibiblio.org> a écrit : > > 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.
I think the problem is scale. I also "generally" delete branches after merge. But sometimes I forget. If all developers sometimes forget to delete the branches, after a year, we'll end up with dozens of branches. After a few years, we'll have to schedule a house-keeping session... > 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. What kind of security issues are you talking about ? Whether the coode / commits / changes are reviewed before entering the repo or after does not change much afaik. > 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. What I think would be lost time is to have to go through all branches in a repo to do some cleanup... ;-) > 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 > -- ------------------------ Guillaume Nodet --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
