- Sebb: The sooner you know something is broken, the better. For example: The new release of commons-net breaks commons-vfs (see my other email thread). It is purely coincidental that this happened at the time I wanted to release VFS. Still, now I don't really want to push through a VFS release until NET and VFS can work together again. I'd like help to figure out where the problem is: either it's a bug in NET or perhaps VFS never used NET properly since day 1. Please help figure it out if you are available. - Jochen: What you do with your inbox is your business ;-) What is the happy compromise here? Do you want a separate email list? Zero Dependabot emails anywhere? If you feel strongly about this, please create a [POLL] thread for what you propose. My view is that at minimum Dependabot should still be enabled; I don't really care about the emails one way or another.
Gary On Mon, Sep 14, 2020 at 7:12 AM sebb <seb...@gmail.com> wrote: > > I agree. > > It would be more useful if there was a report that people could > consult when preparing to release a new version. > > If someone is working on a component, then they may wish to update > dependencies as part of that, but these mass updates distract from the > day-to-day changes. > > What is the use case for updating dependencies between releases? > > AFAICT the reports don't take into account Java version dependencies, > nor do they distinguish which updates are necessary for security > reasons. > But even if they did, I don't think there is a strong use case for > updating software between releases. > > Sebb. > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann <jochen.wiedm...@gmail.com> > wrote: > > > > For the record: Mails from dependabot are now being deleted > > automatically from my inbox. > > > > I consider this to be a failed experiment, and would like us to terminate > > it. > > > > Jochen > > > > > > > > -- > > > > Look, that's why there's rules, understand? So that you think before > > you break 'em. > > > > -- (Terry Pratchett, Thief of Time) > > > > --------------------------------------------------------------------- > > 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
