[Dbix-class] IMPORTANT: A discussion of DBIC governance and future development

[Hartmaier Alexander]

Sorry for replying  that late but I was away for two month and didn't
find the right words in the short peroids of time I had.

castaway let me quote her answer in the mail conversation between David
Golden and the current PAUSE maintainers of DBIC that preceded this one:

> Having read the last few days messages, consider this me joining in..
>
> Admittedly I haven't been following the DBIC ML / commits lately, for
> at least a year.. This is mostly because its felt like
>
> a) Nothing is allowed to be added/tweaked until specifically approved
> by Riba, or until some other piece of work is finished which can only
> be done by Riba.
>
> b) I didn't want to add to all the more things that Riba had to do,
> thus keeping quiet until some point became available that others could
> join in, was reached.
>
> This has been the case for what seems like waaay too long (years),
> such that its easy to think "nobody else cares", various of us who've
> cared and attempted to help out, have been shoved away, or ignored.
>
> Personally, I'd like to have DBIC be more of a community project
> again, with various people having ideas, implementing additions,
> checking each others work, patching issues, testing etcetc.. While I
> get that its depended on a fair bit, I don't think that means being
> *perfect* to the exclusion of all experimentation. I don't think I've
> come across other bits of CPAN, apart from maybe the ones in core,
> that attempt to be as rigorous in their perfection. Really, if people
> upgrade, and encounter an issue .. they can either downgrade and wait,
> or pitch in and help (or pay someone to).. this is open source after all.
>
> As for the issue at hand: Who owns the first-come isnt terribly
> relevant, as long as they work with those of us who'd like to see DBIC
> continue to evolve/improve, ideally several folks will have co-maint,
> and some sort of minor org of releases happens. As yet it hasn't been
> mentioned whether transfer of the first-come from Riba, would also
> involve cancelling all the co-maints? (or did that happen and I missed
> it?)
>
> TL:DR - more community involvement, less micromanagement please
>
> Jess Robinson / JROBINSON / castaway

That's almost exactly what I felt the last few years (wow, time really
flies lately..., didn't felt that long).

Especially a) hit me several times and prevented branches
(people/abraxxa in the git repo) from getting merged to master and released.

I was able to work on the datetime featues in frew's
DBIx::Class::Helper::ResultSet::DateMethods1 but other things that
belong into core, also agreed by ribasushi, didn't make it.

A big part was also his and mst's plan to use Data::Query in DBIx::Class
which they seen to have abandoned without communicating it.

The third and final reason for me to stop trying to contribute was the,
imho silly, dispute about versioning where I was arguing for finally
releasing a 1.0 version to make the stability of DBIx::Class clear.
Ribasushi wanted to delay that until his large refactoring was complete,
including the one to use Data::Query. If I remember correctly mst sided
which him, at least as far as not releasing a 1.0 version immediately
without any further work. My argument that this can become version 1.1,
1.5 or 2.0 as well when it's done was ignored. After a while I just gave
up as it seemed that ribasushis word has to be accepted without objection.

For most parts I'm perfectly happy with DBIC and don't *need* new or
changed features.

Some API methods would be nicer to get renamed which wasn't accepted
either for backcompat, despite the fact that it still wasn't 1.0 and
that ribasushi used API stability as a 1.0 release delay argument.

I'd also like more flexibility in regards to joins, e.g. to not have to
add a second relationship with join_type => 'left' but being able to do
that by use case in the search method call.

We also use RecursiveUpdate heavily though
HTML::FormHandler::Model::DBIC in one app and making its feature core
was and still is a long-time goal for me.

I wasn't able to help ribasushi in his quest for perfect DBIC internals
either as I didn't know any of the parts he was working on and he didn't
want to take the time to educate me on it.

Regarding the first-come situation: I guess the PAUSE admins will do the
right thing if they feel that the person ribasushi hands over his
first-come rights to abuses it.

One also very important detail wasn't discussed at all so far: git
repository rights!

As this mail is already long enough I'll stop here and write another one
if more comes to my mind.

Best regards, Alex

On 2016-10-06 10:50, Jess Robinson wrote:
> On Tue, 04 Oct 2016 19:20:51 +0100, Peter Mottram <peter at sysnix.com>
> wrote:
>
>> On 04/10/16 19:08, Matt S Trout wrote:
>>> On Tue, Oct 04, 2016 at 12:49:49PM -0400, Ashley Pond V wrote:
>>>> I did say MST RFC:MUST be respected. :P This is only here because of
>>>> you. I was an early CDBI user and was there for the fights over its
>>>> direction and saw you as the voice of reason, patience, and vision.
>>>> Regardless of work done since, I see you as the owner. I was unaware
>>>> there was as much of a schism as there apparently is.
>>>>
>>>> I don't know which approach is better. I feel the "permanent
>>>> development ban" you assert is misrepresenting the situation.
>>> Well, I'm not sure how else I can interpret riba's call for a 'project
>>> freeze', especially given that in
>>>
>>> http://lists.scsys.co.uk/pipermail/dbix-class/2016-October/012210.html
>>>
>>> he appears to feel that the previous contributors attempting to
>>> continue
>>> the project is "the worst possible direction, one I worked really
>>> hard to
>>> save this codebase from."
>> My reading is more that this:
>>
>> /> Really, if people upgrade, />/and encounter an issue .. they can
>> either downgrade and wait, or pitch in />/and help (or pay someone
>> to).. this is open source after all./
>>
>> is not a viable option if the breakage causes data loss. Problems at the
>> data layer are simply unacceptable and can result in major financial
>> damage and people being fired. Some projects can afford to be much more
>> bleeding edge but I feel that DBIx::Class needs to be paranoid about
>> what is accepted in core. After all there are other options to allow
>> features to be added without touching core.
>>
>
>
> The above quote from me is the case with all code from CPAN.. like any
> code from the internet, if you're using it for things mission
> critical, you should do a test cycle with updates to new versions, and
> thus give yourself room to say "eek, new changes dont work for me,
> better not upgrade production".
>
> I was not suggesting nor advocating that future changes might happen
> more randomly or without testing.. of course we'd like to keep a
> release cycle that releases test candidates to give people a chance to
> test etc. However nobody is perfect (not even Riba or MST), bugs will
> and do appear.
>
> Without the community/users pitching in and testing/pointing out
> bugs/helping to resolve as I suggested, we'd have waaay more issues
> than we do.
>
> A lot of the comments in this thread make me think its time for v9..
> then folks with v8 can happily stagnate...
>
> Jess
>
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*