Note that moving the dependabot PR emails to a different list (if it's even possible) is only part of the problem. Applying the PR generates a message to the commits list (which cannot safely be dropped) as well as a message closing the PR.
On Sat, 15 Jun 2024 at 21:03, Phil Steitz <phil.ste...@gmail.com> wrote: > > On Sat, Jun 15, 2024 at 12:27 PM Gary Gregory <garydgreg...@gmail.com> > wrote: > > > Hm, would using GitHub Issues instead of Jira make the trail following > > easier, harder, or the same? > > > > Harder, because then you would have to search yet another place to > reconstruct history. But that would be less of an issue over time. I > don't see how it would make it better. What bugs me is not so much having > to look in multiple places as the degraded discussion. We never had > "roadblocks" before - just a convention that we use the dev list to talk > about substantive issues. JIRA (or Bugzilla or Github Issues or > <next_cool_tracker>) is for users to report bugs, ask for enhancements, > organize work, mark things as done. etc. commits@, github PR review, > next_cool_review_board is to enable review of proposed or committed code. > The ML is for discussion. Trying to force all discussion into PR "threads" > has two big problems: 0) it lacks threading and unless we just drop dev@ it > fragments discussion 1) it causes things to be discussed late. It works > great for trivial changes but for things that significantly change > performance or behavior or where there are a lot of different ways they > could be done, it is way better to actually talk about them rather than > just hack a PR and try to collectively mutate it into something acceptable. > > Phil > > > > > Gary > > > > On Sat, Jun 15, 2024, 2:58 PM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > If we want to have everything recorded in one place, then we need to put > > > up some roadblocks to PRs, the Wiki, and Jira like ... what? Have a PR, > > > wiki, and Jira template/gate that says... you must discuss your > > > issue/bug/feature first on the mailing list? It does not feel workable. > > > > > > I don't think this is about people being dinosaurs, it's just the > > > technology and processes that are changing. I really like working with > > > GitHub PRs and GitHub CI builds. I don't want to go back to emails only > > > just like don't ever want to use an IRC thing. > > > > > > Some people don't want to create a GitHub account, so it's Jira and diff > > > files for them, but that's rare. BUT it gives us a LOT MORE work to > > > validate a patch compared to GitHub CI where it can use many OSs and Java > > > version while I'm sleeping :-) > > > > > > Gary > > > > > > > > > On Sat, Jun 15, 2024, 2:00 PM Phil Steitz <phil.ste...@gmail.com> wrote: > > > > > >> On Sat, Jun 15, 2024 at 10:19 AM Gary Gregory <garydgreg...@gmail.com> > > >> wrote: > > >> > > >> > Note that it is 1) awkward to say "Let's stop talking about this PR in > > >> > this PR" > > >> > > >> > > >> Funny we used to do that all the time in Jira comments. I guess times > > >> change. FWIW, I think it is a step backward in discussion and > > ultimately > > >> code and archive quality. To me it is "awkward" to have to be > > constantly > > >> @somebody and not have threads or definitive discussion anywhere. Works > > >> fine for trivial changes but does not really work for substantive > > >> discussion of bigger things. So we end up never actually having those > > >> discussions and there is no reasonably searchable archive of the thought > > >> process that led to the changes going in. We used to have that and it > > was > > >> a useful thing, especially for the more complex components. > > >> > > >> Phil > > >> > > >> > > >> > > >> > and 2) "You need to subscribe to a mailing to continue this > > >> > chat." It's just hard to find when to ask for a switch. Especially > > >> > when GH has a nice UI to make comments _about code_. Over at Log4j, we > > >> > now use GitHub issues instead of Jira, furthering the split... > > >> > > > >> > Gary > > >> > > > >> > On Sat, Jun 15, 2024 at 12:38 PM Phil Steitz <phil.ste...@gmail.com> > > >> > wrote: > > >> > > > > >> > > On Wed, Jun 12, 2024 at 10:58 AM Gary D. Gregory < > > ggreg...@apache.org > > >> > > > >> > > wrote: > > >> > > > > >> > > > On 2024/06/12 17:17:24 Phil Steitz wrote: > > >> > > > > On Wed, Jun 12, 2024 at 7:27 AM sebb <seb...@gmail.com> wrote: > > >> > > > > > > >> > > > > > On Wed, 12 Jun 2024 at 14:45, Gary D. Gregory < > > >> ggreg...@apache.org > > >> > > > > >> > > > wrote: > > >> > > > > > > > > >> > > > > > > Hello All, > > >> > > > > > > > > >> > > > > > > Here is the draft of our board report for June I plan on > > >> > submitting > > >> > > > in a > > >> > > > > > day or so, feedback is welcome. > > >> > > > > > > > > >> > > > > > > ## Description: > > >> > > > > > > The mission of Apache Commons is the creation and > > maintenance > > >> of > > >> > Java > > >> > > > > > focused > > >> > > > > > > reusable libraries and components > > >> > > > > > > > > >> > > > > > > ## Project Status: > > >> > > > > > > Current project status: Ongoing with moderate activity. > > >> > > > > > > Issues for the board: none. > > >> > > > > > > > > >> > > > > > > ## Membership Data: > > >> > > > > > > Apache Commons was founded 2007-06-19 (17 years ago) > > >> > > > > > > There are currently 149 committers and 44 PMC members in > > this > > >> > > > project. > > >> > > > > > > The Committer-to-PMC ratio is roughly 5:2. > > >> > > > > > > > >> > > > > > Missing from this paragraph is the fact that Commons has > > enabled > > >> > > > > > universal commit. > > >> > > > > > > > >> > > > > > > Community changes, past quarter: > > >> > > > > > > - Claude Warren was added to the PMC on 2024-03-22 > > >> > > > > > > - No new committers. Last addition was Claude Warren on > > >> > 2022-02-01. > > >> > > > > > > > > >> > > > > > > ## Project Activity: > > >> > > > > > > Many releases of our components: > > >> > > > > > > CONFIGUATION-2.11.0 was released on 2024-06-10. > > >> > > > > > > > >> > > > > > Is that a new component? > > >> > > > > > > > >> > > > > > > NET-3.11.1 was released on 2024-06-10. > > >> > > > > > > PARENT-71 was released on 2024-06-10. > > >> > > > > > > JEXL-3.4.0 was released on 2024-06-06. > > >> > > > > > > NET-3.11.0 was released on 2024-05-31. > > >> > > > > > > VALIDATOR-1.9.0 was released on 2024-05-28. > > >> > > > > > > JCS-3.2.1 was released on 2024-05-27. > > >> > > > > > > DAEMON-1.4.0 was released on 2024-05-24. > > >> > > > > > > CLI-1.8.0 was released on 2024-05-23. > > >> > > > > > > COMPRESS-1.26.2 was released on 2024-05-23. > > >> > > > > > > LOGGING-1.3.2 was released on 2024-05-15. > > >> > > > > > > PARENT-70 was released on 2024-05-15. > > >> > > > > > > CSV-1.11.0 was released on 2024-05-02. > > >> > > > > > > RELEASE-PLUGIN-1.8.2 was released on 2024-04-19. > > >> > > > > > > CLI-1.7.0 was released on 2024-04-18. > > >> > > > > > > IMAGING-1.0.0-alpha5 was released on 2024-04-18. > > >> > > > > > > TEXT-1.12.0 was released on 2024-04-16. > > >> > > > > > > BUILD-PLUGIN-1.14.0 was released on 2024-04-15. > > >> > > > > > > IO-2.16.1 was released on 2024-04-08. > > >> > > > > > > COLLECTIONS-4.5.0-M1 was released on 2024-04-02. > > >> > > > > > > IMAGING-1.0.0-alpha4 was released on 2024-04-02. > > >> > > > > > > PARENT-69 was released on 2024-04-01. > > >> > > > > > > IO-2.16.0 was released on 2024-03-28. > > >> > > > > > > LOGGING-1.3.1 was released on 2024-03-24. > > >> > > > > > > PARENT-68 was released on 2024-03-23. > > >> > > > > > > CONFIGURATION-2.10.1 was released on 2024-03-20. > > >> > > > > > > CONFIGURATION-2.10.0 was released on 2024-03-13. > > >> > > > > > > > >> > > > > > The above list should probably be sorted > > >> > > > > > > > >> > > > > > > ## Community Health: > > >> > > > > > > We welcomed Claude Warren as our latest PMC member. Mailing > > >> list > > >> > > > > > activity has > > >> > > > > > > increased. > > >> > > > > > > > >> > > > > > Much of the increased mailing list activity is driven by > > >> dependabot > > >> > > > > > PRs, many of which are useless, as it does not take Java > > >> > compatibility > > >> > > > > > into account. > > >> > > > > > > > >> > > > > > > >> > > > > +1 > > >> > > > > I have had to filter out most of the messages and once I do > > that, > > >> > there > > >> > > > is > > >> > > > > almost no actual discussion on-list. I am worried that when > > >> people > > >> > do > > >> > > > try > > >> > > > > to start discussion, the messages are being missed. I > > personally > > >> > see the > > >> > > > > lack of ml discussion as a problem. Lots of code changes are > > >> > happening > > >> > > > > with no discussion, other than maybe random nits on PRs ending > > up > > >> in > > >> > > > github > > >> > > > > threads that don't end up organized that well in list archives. > > >> This > > >> > > > > problem is not unique to Commons. > > >> > > > > > >> > > > Hi Phil, > > >> > > > > > >> > > > We had a discussion a while back about creating a "bot" email list > > >> but: > > >> > > > - no one actually proposed anything concrete and did any work > > >> > > > - we already have bot lists like "commit", "notifications", > > >> "issues", > > >> > > > can't we reuse those? > > >> > > > > > >> > > > > >> > > +1 for that. How about moving the dependabot things to > > >> "notifications"? > > >> > > What exactly do we use that list for now? I think it is important > > for > > >> > > committers to monitor commits but that is not really possible with > > >> all of > > >> > > the dependabot spam in there. I personally filter that to > > /dev/null. > > >> > > > > >> > > The problem with github PR comments basically replacing dev@ is a > > >> bigger > > >> > > one. It would be helpful if we could figure out a way to pipe > > (only) > > >> the > > >> > > code discussion messages to the dev list, but I think the better > > >> answer > > >> > > there would be to establish the discipline that any discussion > > beyond > > >> > nits > > >> > > gets moved to dev@. That may be a dinosaur view, but I think it is > > >> > worth > > >> > > considering. I agree with Gilles that fast processing of long-tail > > >> > > one-shot PRs is useful but misleading when it comes to community > > >> health. > > >> > > Steering people to dev@ and actually talking about the code might > > be > > >> > > annoying to some in the long tail, but it might net us some new > > >> > committers, > > >> > > which IMO is more valuable than a lot of the one shot PRs that we > > get. > > >> > > > > >> > > Phil > > >> > > > > >> > > > > >> > > > - I don't know if GitHub lets us configure target emails for "I > > >> > created a > > >> > > > PR" (or someone commented on a PR), vs. other types of messages. > > >> > > > > > >> > > > Gary > > >> > > > > > >> > > > > > > >> > > > > Phil > > >> > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > Most if not all of our increasing contributions are coming > > in > > >> > > > > > > through GitHub pull requests. This is working well for us: > > >> > GitHub PRs > > >> > > > > > with > > >> > > > > > > continuous integration builds providing great infrastructure > > >> and > > >> > > > > > validation of > > >> > > > > > > PRs and the existing code base. The flip side is that the > > >> > increase in > > >> > > > > > GitHub > > >> > > > > > > usage is matched by a decrease in Jira usage. > > >> > > > > > > > > >> > > > > > > Gary > > >> > > > > > > > > >> > > > > > > > > >> > --------------------------------------------------------------------- > > >> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > > > > > > For additional commands, e-mail: > > dev-h...@commons.apache.org > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > --------------------------------------------------------------------- > > >> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> --------------------------------------------------------------------- > > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > > > >> > > > > > >> > > > >> > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > >> > > > >> > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
