On Monday 25 June 2018 08:31:08 Ricardo Signes wrote: > * p...@cpan.org [2018-06-25T05:08:32] > > So what is status of Email::* modules? Does silence now mean that > > modules are abandoned / unmaintained? I guess so. > > You are mistaken. > > The answer is the same as every other time you have asked: I am here, I am > alive, I am interested, and I am extremely busy, so these don't often make it > to the top of my list. > > We don't have any sort of sense of community here or a practice of shared code > review, so everything comes down to "when does Rik have the time to consider > each change." That is "not all that often." > > If we had three or four people who committed to create a better sense of group > responsibility, maybe we'd see more progress.
On list are still more people interested in Email:: modules. Either as direct users or developers of other Email:: modules. So... is there somebody interested in doing some code review or maintenance of Email:: modules? > The last thing you wrung your hands about "we have no maintainer!" was > something for which we didn't even have a clear and isolated fix, so the task > here wasn't "nobody will review and apply this commit," but "nobody is willing > to write a fix." So, in that sense, yes, nobody is doing active maintenance > on > Email::Address much of the time, but somebody is alive. This just means that Email::Address is not going to be fixed... > With Email::MIME, keep in mind that part of maintenance is not just applying > any old patch, because people rely on this software to not change too > radically. So, there has to be not only patches, but also review and > consideration, so "we aren't adding new features" isn't always a sign of > disrepair, but can also indicate "we don't have the time to predict the impact > of these changes on existing users." I understand and I'm asking for reviewing my pull requests for longer time. Not for "blind merge". > So: you can wait for me to have more time, or people with some vested > interest can agree to step up to do more in general. > > I'm not going to be shamed into doing a release that might break things and > cause me ten times as much work as leaving things be. But doing some testing of users outside of pep mailing list would need some CPAN trial release. Yes things which could break things are problem and this needs to be done when doing review of patches.
