[Dbix-class] A slightly more concrete proposal

[Darren Duncan]

Having just read the C4 spec, I generally find its proposals reasonable.

However, section 2.5 "Branches and Releases" seems too simplistic and I would 
recommend against adopting that part as is.

In particular, its third point:

"To make a stable release a Maintainer shall tag the repository. Stable releases 
SHALL always be released from the repository master."

While that would be fair for smaller projects, it would not work for any 
projects that want to maintain multiple concurrent release branches such as Perl 
itself or Postgres itself do.  This would also apply to projects like DBIC for 
whom the option of stability is paramount.

For that matter, I think the multiple release branch scenario is common and 
important enough that C4 should be updated to explicitly support that as an option.

-- Darren Duncan

On 2016-10-06 10:07 AM, fREW Schmidt wrote:
> Woops, didn't mean to refer to the old version of C4.  I don't know
> the differences between C4.1 and C4.2 are, but I suspect the newer one
> is probably better.  Corrected link is
> https://rfc.zeromq.org/spec:42/C4/.
>
> On Thu, Oct 06, 2016 at 09:57:38AM -0700, fREW Schmidt wrote:
>> Hello friends,
>>
>> TL;DR:
>>
>>   * Given that we want stability and community involvment, maybe we
>>     should try C4.1 which optimizes for these.
>>   * I really strongly think that all members of (AT LEAST) the core
>>     group need to act like adults when conversing with other people,
>>     especially realizing that things that may not be personal attacks
>>     often seem that way when plain text is the mode of discussion.
>>
>> Exposition below, feel free to skip if you are busy or don't care.
>>
>> I haven't kept super up to date with these threads, especially since a
>> lot of it has devolved into email, irc, and blog comment exegesis,
>> which I don't see as being particularly helpful or valuable.
>>
>> I wouldn't respond to this again but I am specifically named in
>> Matt's proposed core team so I felt like it would be warranted.  I
>> agree that the stability of DBIC is a huge asset.
>>
>> There are at least two stabilities here: The first is not losing data.
>> While DBIC has a good track record of this, I personally have
>> experienced a bug (fixed by ribasushi of course) where the WHERE
>> clause of a complex delete was lost.  (Yes, the whole table was
>> deleted.)  This is critical to maintain, and hard.
>>
>> The more subtle stability, the kind that doesn't get people fired but
>> instead leaches the time out of our brief lives, is pointless
>> breakages in backcompat, silly little bugs that have to be worked
>> around, etc.  This is also hard, and people are less willing to do it,
>> but if we care about our users (and I do!) we must continue to
>> maintain it.
>>
>> There is the hope that DBIC can be maintained by a disparate group.  I
>> have hope, especially having seen at my current place of employment
>> that sometimes, throwing conventional wisdom out the window and
>> deciding to do things a new and better way is a good option.
>>
>> I am sorta attracted to the model the late Pieter Hintjens came up
>> with for ∅MQ (C4.1, https://rfc.zeromq.org/spec:22/C4/, except the
>> specification of [LA]GPL) but am not going to push it hard.  I just
>> think a model for similarly trusted software might be worth
>> considering.
>>
>> I am ok with being part of a core group, although I must caution
>> everyone: I personally don't have the time nor desires I used to have.
>> DBIC and it's community have treated me well, and I respect that, but I
>> can only spill so much blood for Open Source software.
>>
>> What I am *not* interested in is being a member of a core group where
>> I have to be the adult in interpersonal conflicts.  Matt, if an idea
>> is stupid, you can express it constructively.  If it's wrong, say how.
>> You *must* stop assuming people can or will read your mind or treat
>> your words as sacred texts to be analyzed character by character.  I
>> don't expect anyone to be perfect, core group or external, and expect
>> everyone to make mistakes, but we should at least decide to set a tone
>> of professionalism, charity, cordiality, or whatever you want to call
>> it so that we don't end up pointlessly making our small part of the
>> Perl community more harmful than it needs to be.
>>
>> --
>> Station,
>> Arthur Axel fREW Schmidt
>> https://blog.afoolishmanifesto.com
>