Time to figure out what we need to do to get moving again.
Note that I'm going to list a bunch of things below, with brief notes on each
one - as you reply, please adjust the subject line to indicate which one you're
responding to, and separate replies for each response. Hopefully that'll give
us a reasonable balance between keeping things clear and not ending up in
* Getting master released
riba said that he believed that what's currently there is releasable as-is, but
given the rest of us aren't as familiar with the changes he's made and in a
spirit of "belt and braces" I think we should ship a dev release first.
Plus it's probably a good idea for at least a couple of the VMs to go through
the log and familiarise ourselves with the shape of the changes before we put
out a PAUSE indexed released with these commits.
* Moderation policy
Previously, DBIx::Class spaces - here, the mailing list, bug trackers - have
basically been moderated by a principle of "everybody is expected to be an
adult and if you don't manage that expect mst to mallet you".
I've no particular objection to keeping it that way, it's not like we've
needed it very often anyway - but given different definitions of civility
were touched upon in the governance discussions, it seems worth considering
doing things a little more formally.
Roughly, the question comes down to - do we want to formalize moderation now,
or do we want to leave things informal for the moment under the assumption
that we can always formalize via proposal later if informal becomes an issue?
* Branches and PRs and tickets, oh my
We're going to need a triage pass on all three of these to figure out what's
active, what's ancient, and what's "we think this is a riba work in progress
but it's above our pay level right now". There's likely quite a bit of effort
involved here so I think we'll want to crowdsource at least the first pass;
who'd be interested in helping out, and does anybody have any flashes of
inspiration as to how best to co-ordinate this?
(in case anybody's wondering, I'm intending to attic the dq2 branches since
I don't believe they'll ever end up merge-worthy in their current form)
* Feature planning
I have the odd idea for things that might potentially be of interest to people
as features once we've got current master shipped, but that's definitely a
'might' and I regard everybody to have a stake in the direction at this point.
I suspect it's probably worth having a 'request for feature requests' thread,
and maybe also mirroring that somewhere else (a github issue? a blog post?
all of the above plus a bat signal?).
* Stability protection
I also suspect that given people are/were significantly interested in
stability/performance of the existing API, often more so than getting any
particular extension thereof, I'd like to here people's thoughts as to how we
measure that - stability is probably mostly covered by the ridiculous number
of tests that riba added plus a little common sense, but I wouldn't object to
Performance, on the other hand, requires benchmarks that we believe reflect
real world use and allow us to guide where we try and optimise and where we
worry about pessimisations. I have a few ideas of my own, but I'd love to
hear from people who're concerned about perl-side performance as to what they
think would constitute a solid set of benchmarks. I'm fairly convinced that
crowdsourcing this is going to be the best way to approximate a representative
set of benchmarks to monitor, though meta-crowdsourcing where you suggest other
approaches is completely welcome.
* Conflicts of interest
DBIx::Class has had a number of features over its history sponsored by various
companies, whether directly by their staff being paid to build them or
indirectly via Shadowcat and others; such things have always, so far as I've
been involved, been merged or not merged on the merits and neither the sponsors
nor the userbase have ever had an issue.
On the other hand, we're trying to formalise things a little bit, and it's
been clear from prior discussions that riba at least isn't entirely comfortable
with such things being any less than explicit - so again the question becomes
"do we leave it informal and assume people will behave sensibly knowing that
it can be formalised by proposal any time people want to, or do we formalise
it pre-emptively to ensure expectations are clear and explicit?"
* Any other business?
If there's anything organisational/immediate that you think is worth
discussing, including possible amendments/refinements of the governance
system, please do whack a note in under this subheading.
Also this gives me a get out clause if I realise tomorrow I missed out one of
the categories I'd intended to include, or if my original set of intentions
was missing an entry outright.
(and, finally, thank you for bearing with me - had to get back up to speed
with other things after the ructions of late last year before I could give
DBIC a useful amount of attention)
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue
Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN
commercial support, training and consultancy packages could help your team.
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
So I'm now opening up a generic "feature planning" thread ostensibly in the
manner that Matt requested.
On 2017-01-24 4:06 PM, Matt S Trout wrote:
> Time to figure out what we need to do to get moving again.
> Note that I'm going to list a bunch of things below, with brief notes on each
> one - as you reply, please adjust the subject line to indicate which one you're
> responding to, and separate replies for each response. Hopefully that'll give
> us a reasonable balance between keeping things clear and not ending up in
> [1/27] territory.
> * Feature planning
> I have the odd idea for things that might potentially be of interest to people
> as features once we've got current master shipped, but that's definitely a
> 'might' and I regard everybody to have a stake in the direction at this point.
> I suspect it's probably worth having a 'request for feature requests' thread,
> and maybe also mirroring that somewhere else (a github issue? a blog post?
> all of the above plus a bat signal?).
As a matter of disclosure: I am an off-and-on user of DBIC. I have been aware
of this project nearly since its inception, when Matt invited me to join this
mailing list during OSCON in the summer of 2005, and have been primarily
following it due to my general interest in database technology. Years later I
also became an actual DBIC user when I worked with several different companies
that were heavily dependant on DBIC in their codebases, though I am not
presently with them. My own stake in the general case is to help improve the
experience of using databases in Perl applications. I consider helping to
improve DBIC to be a means to that end rather than and end of its own. AFAIK,
DBIC is the most popular interface for databases in Perl today besides its
dependency DBI, and so any serious effort I would make towards my goal would
also substantially involve helping DBIC specifically. But I don't have a stake
in DBIC maintaining a popularity lead over alternatives, only that the Perl
database technologies as a group continue to improve for users.
My main proposed DBIC feature is compatability with my alternative to the Perl 5
DBI which has the working name DBP for "DataBase Protocol". Initially this
means adding support for DBP alongside DBI but later on DBIC should only need to
support DBP directly.
DBP is intended to be a "Plack for databases". It occupies a similar level of
abstraction as DBI but it is designed more for 2017 best practices than 1995
best practices. Using DBP should bring as much advancement to the Perl
ecosystem as using PSGI/Plack did, if not more.
The single most important thing is that the DBP ecosystem is "shared-nothing".
That is, DBP would actually just be an API specification document for a
duck-typing/etc API that conforming libraries and applications would implement
for themselves. A conforming library would either provide the API or consume
the API. Example providers are updated versions of or wrappers of DBD::SQLite
or DBD::Pg and so on. Example consumers are either end-user applications or
some kinds of middleware such as updated versions of DBIx::Class or Rose::DB and
so on. Sometimes you can have libraries that are both providers
and consumers, such as a proxy layer or an emulation layer. There would
absolutely NOT be any code/module/class/role/etc named "DBC" which consumers
would need to "use" to mediate access to providers. There would absolutely not
be any mandatory shared dependency such as "DBC" to use the shared API. This
doesn't rule out the existence of libraries that provide implementation code
which API providers can choose to depend on in common, such as DBI is often used
for today, but this would strictly be an implementation detail of the providers,
and not mandatory for using "DBC".
Therefore, the main net user-visible result of migrating DBIC from DBI to DBP is
simply to remove DBI and any DBD::* modules from its hard dependency list, so
DBIC can be installed and run without having to also install that dependency chain.
Instead, any application or other middleware that has the hard dependency on
DBIC, it would also have explicit direct dependencies on 1 or more DBD::*
modules that it is actually using, either in its code with "use" or in its
config files for a runtime-defined DBD::* dependency.
Similarly, the DBIC test suite would be like such an application, the test suite
itself would name a DBD::* etc dependency or dependencies either in code or in a
config file so that the test suite can operate and test everything DBIC can do
which requires a DBMS external to itself.
Given the depth of internals changes to some parts of DBIC that this involves,
along with at least a small user interface change (anything that takes or emits
a user-supplied DBI object), I fully expect this work to be treated as a major
feature branch and not something that would be released like it were a mere bug
fix release. It is possible for DBIC to provide 100% backwards compatibility to
its users in the new version so they don't need to change anything, but the most
effective users would involve small application changes in some corners.
I am still in the process of building reference provider implementations of the
DBP spec, as well as writing the DBP spec itself, but they will hopefully be
ready to use soon. In the meantime, you can see part of the spec on GitHub here:
And its corresponding Perl 6 version:
I had previously discussed this effort here:
I will post on this again when I have something ready to execute.
-- Darren Duncan
Searchable Archive: http://www.grokbase.com/group/dbix-class@...
|Free forum by Nabble||Edit this page|