Re: AnyData2/DBD::AnyData2 co-maint
On Wed, Apr 22, 2015 at 6:05 PM, Wendy G.A. van Dijk nl...@wendy.org wrote: Hi Jens, You interrupted me at every 5 words I tried to explain about what was discussed at the consensus meetings at the QA Hackathon in Berlin. We had a big argument, and you never ever did let me finish the explanation. You told me how bad the decision was, but you never let me explain the whole stuff. And now you are writing about this and not even waiting for the official stuff to be published. Please wait until the whole decision comes online, David Golden will write a proposal. Really, it will be balanced, and it will make sense. Just calm down and wait. Greetz, Wendy This is a relief. I was surprised to see implied that the DBI power mist has the power to change CPAN policy in the described way. Hopefully this upcoming sensible and balanced statement will include a facility for helping identify and designate co-maintainers included in the process of registering modules onto this positively branded list. I look forward to being able to brag that DBIx::bind_param_inline is Approved by the Berlin DBI Committee or equivalent. What will the list of process-conformant vetted modules be called? Will we get to claim includion in the Official Maintained DBI Module List or what? -- David St. Hubbins: It's such a fine line between stupid, and uh... Nigel Tufnel: Clever.
Re: AnyData2/DBD::AnyData2 co-maint
On Fri, 24 Apr 2015 09:19:03 -0500, David Nicol davidn...@cpan.org wrote: I look forward to being able to brag that DBIx::bind_param_inline is Approved by the Berlin DBI Committee or equivalent. As there is no, never was, nor will there be a Berlin DBI Committee feel free to brag as you wish :P What *will* be published is a document with advisories on how module authors are expected to behave once there modules are hot. The document will have three levels of advice * New modules should do/have/follow/... * Modules that are heavily depended on should do/have/follow/... * Core- and toolchain modules should do/have/follow/... The document is there to serve a list of Best Practices and make the module authors maintainers and co-maintainer be more aware of what their changes might/will cause downriver. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgp7fG9PjhtUe.pgp Description: OpenPGP digital signature
Re: AnyData2/DBD::AnyData2 co-maint
At 04:19 PM 4/24/2015, David Nicol wrote: This is a relief. I was surprised to see implied that the DBI power mist has the power to change CPAN policy in the described way. Hopefully this upcoming sensible and balanced statement will include a facility for helping identify and designate co-maintainers included in the process of registering modules onto this positively branded list. I look forward to being able to brag that DBIx::bind_param_inline is Approved by the Berlin DBI Committee or equivalent. What will the list of process-conformant vetted modules be called? Will we get to claim includion in the Official Maintained DBI Module List or what? I think: none of the above. As long as nothing is published by David Golden, there's nothing to discuss. We should not fall prey to fearmongering, wild guessing and walking ahead of the troops. Many things were discussed, and the first thing that has to be done is make a summary that makes sense, make a proposal that makes even more sense, and await the reactions from you and many others. This discussion is a discussion that should not happen now, because there is no use for you to discuss this on false premises, and without more knowlegde. And I am not providing any more info. Just be patient, and don't fear the worst, expect something balanced and very useful. Kind regards, Wendy van Dijk
Re: AnyData2/DBD::AnyData2 co-maint
On Fri, Apr 24, 2015 at 04:49:15PM +0200, H.Merijn Brand wrote: On Fri, 24 Apr 2015 09:19:03 -0500, David Nicol davidn...@cpan.org wrote: I look forward to being able to brag that DBIx::bind_param_inline is Approved by the Berlin DBI Committee or equivalent. As there is no, never was, nor will there be a Berlin DBI Committee feel free to brag as you wish :P What *will* be published is a document with advisories on how module authors are expected to behave once there modules are hot. The document will have three levels of advice * New modules should do/have/follow/... * Modules that are heavily depended on should do/have/follow/... * Core- and toolchain modules should do/have/follow/... The document is there to serve a list of Best Practices and make the module authors maintainers and co-maintainer be more aware of what their changes might/will cause downriver. And, hopefully, has no particular reference to the DBI beyond simply being an example of a heavily depdened on module, like many others. Tim.
Re: AnyData2/DBD::AnyData2 co-maint
Hi Jens, You interrupted me at every 5 words I tried to explain about what was discussed at the consensus meetings at the QA Hackathon in Berlin. We had a big argument, and you never ever did let me finish the explanation. You told me how bad the decision was, but you never let me explain the whole stuff. And now you are writing about this and not even waiting for the official stuff to be published. Please wait until the whole decision comes online, David Golden will write a proposal. Really, it will be balanced, and it will make sense. Just calm down and wait. Greetz, Wendy At 01:23 PM 4/22/2015, Jens Rehsack wrote: Am 22.04.2015 um 12:21 schrieb H.Merijn Brand h.m.br...@xs4all.nl: On Wed, 22 Apr 2015 12:01:46 +0200, Jens Rehsack rehs...@gmail.com wrote: Hi Merijn, since Wendy told me yesterday that every new module must (should) have a co-maint, It was decided upon to be *advisory* for upstream modules: those that have modules on CPAN that depend on it or where is known that DarkPAN users have publicly shown that they are using the module. The latter is not (yet) visible on any of the current CPAN clients. co-maint is not obligatory. certainly not for new modules. Than I misunderstood probably something. Anyway - it might be a good idea, either - for keeping an eye on it or whatsoever :) FWIW, I am in serious doubt if I want to have anyone co-maint Text::CSV_XS at all. Come on - I had commit bit for years on repo.or.cz and didn't misuse it in any way. could I count on you for upcoming AnyData2 / DBD::AnyData2? /me is in serious doubt, as the main purpose of these modules is way out of my focus area: I never use them. My primary reason to use DBD::CSV from time to time is to keep on track how the users problems look like ;) For the typical problems I solve using it, it's overkill ... You're familiar with the separation of storage / parsing engine, you're familiar with DBI::DBD::SqlEngine and you're more or less familiar with SQL::Statement ... Do you know of any CPAN author that is using them or has shown interest in these? That would IMHO be a better choice. Seriously: Nope. Only DarkPAN :( I don't want to start on dbi-dev@ a general discussion - so AD2: yes or no? Cheers -- Jens Rehsack rehs...@gmail.com
Re: AnyData2/DBD::AnyData2 co-maint
On Wed, 22 Apr 2015 12:01:46 +0200, Jens Rehsack rehs...@gmail.com wrote: Hi Merijn, since Wendy told me yesterday that every new module must (should) have a co-maint, It was decided upon to be *advisory* for upstream modules: those that have modules on CPAN that depend on it or where is known that DarkPAN users have publicly shown that they are using the module. The latter is not (yet) visible on any of the current CPAN clients. co-maint is not obligatory. certainly not for new modules. FWIW, I am in serious doubt if I want to have anyone co-maint Text::CSV_XS at all. could I count on you for upcoming AnyData2 / DBD::AnyData2? /me is in serious doubt, as the main purpose of these modules is way out of my focus area: I never use them. Do you know of any CPAN author that is using them or has shown interest in these? That would IMHO be a better choice. I don't want to start on dbi-dev@ a general discussion - so AD2: yes or no? -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgphIhgijb7sh.pgp Description: OpenPGP digital signature
Re: AnyData2/DBD::AnyData2 co-maint
Am 22.04.2015 um 12:21 schrieb H.Merijn Brand h.m.br...@xs4all.nl: On Wed, 22 Apr 2015 12:01:46 +0200, Jens Rehsack rehs...@gmail.com wrote: Hi Merijn, since Wendy told me yesterday that every new module must (should) have a co-maint, It was decided upon to be *advisory* for upstream modules: those that have modules on CPAN that depend on it or where is known that DarkPAN users have publicly shown that they are using the module. The latter is not (yet) visible on any of the current CPAN clients. co-maint is not obligatory. certainly not for new modules. Than I misunderstood probably something. Anyway - it might be a good idea, either - for keeping an eye on it or whatsoever :) FWIW, I am in serious doubt if I want to have anyone co-maint Text::CSV_XS at all. Come on - I had commit bit for years on repo.or.cz and didn't misuse it in any way. could I count on you for upcoming AnyData2 / DBD::AnyData2? /me is in serious doubt, as the main purpose of these modules is way out of my focus area: I never use them. My primary reason to use DBD::CSV from time to time is to keep on track how the users problems look like ;) For the typical problems I solve using it, it's overkill ... You're familiar with the separation of storage / parsing engine, you're familiar with DBI::DBD::SqlEngine and you're more or less familiar with SQL::Statement ... Do you know of any CPAN author that is using them or has shown interest in these? That would IMHO be a better choice. Seriously: Nope. Only DarkPAN :( I don't want to start on dbi-dev@ a general discussion - so AD2: yes or no? Cheers -- Jens Rehsack rehs...@gmail.com
