+1 On Wed, Oct 4, 2017 at 8:04 PM, Matt S Trout <m...@shadowcat.co.uk> wrote:
> (obviously, "fix any bugs we find while testing" should be taken as read) > > I have a few areas of concern wrt the changes made since last release: > > 1) The sanitychecker code is going to point out a lot of things that were > only ever accidentally working - but many of those things may continue to > accidentally work, and if it barfs valid-but-numerous warnings all over > people's log files that may discourage people upgrading who would, on the > whole, be better upgrading anyway (and while most of the changes to the > internals were in prior releases, people have this tendency not to upgrade > as often as I would ideally like). Note: this may be me being pointlessly > paranoid, but I'd like some experience reports from users to try and gauge > it by before I file it under "we should just tell them to stop worrying and > learn to love the sanity checker". > > 2) A different class of 'accidentally working' requires the addition of > attributes to methods, and I suspect that, for people who (a) are using > method modifiers (b) are using anything else that doesn't set attributes > normally (c) just hate attributes, we should provide an alternative > interface > that lets them do it a different way. This may be as simple as documenting > that you're allowed to call attributes::import instead, though since I've > got > at least one foot in category (c) above I think I'd prefer something that > isn't *dependent* on the attributes system and merely allows the use of > attributes as one possible interface to it. > > 3) Check through outstanding branches for things that are sufficiently > low impact and/or high value that didn't make it into master but should > probably do so by release time. > > 4) Check RT for bugs that have come up during our unfortunate hiatus that > are important enough we should consider rolling fixes for them into the > release. > > 5) Anything else the list membership can think of that I haven't. > > These all seem like things we can discuss while the devrel's soaking - > though > for (1) and (2) I guess people are going to want to actually play with the > devrel, and everybody's opinions being basically 'mu' until they start > doing > so is fine by me. > > But, roughly, what I'm thinking is our process should be: > > * another devrel that at least starts to cover 3/4 > * ask people who're adventurous to try that one and have opinions about 1/2 > * decide what if anything should be done about 1/2 > * roll a 'this might become an RC' devrel with the results of 1-4 > * see what everybody thinks of that one > * plan path towards a stable release > > Of course, category 5 could easily result in comments that make this > process need a complete redo. > > Thoughts from the list on the above would be very welcome, or if your > thought is "looks basically reasonable" then a +1 would be nice (once > there's > 3 or 4 such replies there's no need to add to them, but I'd at least like > to > know "some people think it looks basically reasonable" if that's the case). > > -- > Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a > clue > > http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_ > mst/ > > 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. > > _______________________________________________ > 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 >
_______________________________________________ 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