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 > >> > > >> > > >> > > >
