Grokbase Groups Perl qa March 2016
FAQ
RJBS and I have spoken, and feel it is time to set a release date for
Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a
good time. The plan is to release Test2 and the new Test::Builder as stable
either at the end of the first day, or the start of the second day (so the
21st or 22nd of april). This gives a full day for people to grab me in
person to talk about it, and address any issues. It also gives 2 full days
after the release where my attention can be fully devoted if any issues are
discovered post-release.

I expect little if any changes to occur in the code between now and then.
Possibly some small bug fixes, documentation updates, etc. nothing big. I
will continue to listen to any feedback that is provided, and take any
necessary action. In the meantime RJBS is going to be pinging stakeholders
from the punch-list (
https://github.com/Test-More/test-more/wiki/Test-Builder-v1.3-Punchlist) to
make sure all requirements have been met.

What exactly is going stable?

* Test2 (experimental notices will be removed)

* Test::Builder that uses Test2 under the hood (as seen here:
https://metacpan.org/release/EXODIST/Test-Simple-1.302013_014)

* Test2-Suite (experimental notices will be removed)

* Final Test2/Test-Simple patch for perl blead (Test-Suite is not going
into blead)

I look forward to seeing you all in Rugby!

-Chad

Search Discussions

  • Ricardo Signes at Mar 26, 2016 at 2:03 am
    * Chad Granum [2016-03-19T13:03:34]
    RJBS and I have spoken, and feel it is time to set a release date for
    Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a
    good time. The plan is to release Test2 and the new Test::Builder as stable
    either at the end of the first day, or the start of the second day (so the
    21st or 22nd of april).
    There has been basically no public reply to this. I would love to get some
    "sounds good!" or even some "hey, but!" For my part, I'm pleased with the
    state of things, and looking forward to converting more of my code to using
    Test2 directly.

    Of course, those of us who are at the QAH can discuss things there, but I think
    it'd be good to get some context on the books, especially from people who won't
    make it.

    --
    rjbs
  • Randy Stauner at Mar 26, 2016 at 2:57 am
    As a maintainer of one of the problem modules (Test::Aggregate) i should
    have something to say, but I haven't been able to spend more than an hour
    with Perl in the last year so i don't know when I'll be able to work on
    making it work with the changes. I see no reason to hold up progress on
    this any longer, so "sounds good" to me.
    On Fri, Mar 25, 2016, 19:03 Ricardo Signes wrote:

    * Chad Granum [2016-03-19T13:03:34]
    RJBS and I have spoken, and feel it is time to set a release date for
    Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a
    good time. The plan is to release Test2 and the new Test::Builder as stable
    either at the end of the first day, or the start of the second day (so the
    21st or 22nd of april).
    There has been basically no public reply to this. I would love to get some
    "sounds good!" or even some "hey, but!" For my part, I'm pleased with the
    state of things, and looking forward to converting more of my code to using
    Test2 directly.

    Of course, those of us who are at the QAH can discuss things there, but I
    think
    it'd be good to get some context on the books, especially from people who
    won't
    make it.

    --
    rjbs
  • Shlomi Fish at Mar 26, 2016 at 8:44 am
    Hi all,

    On Sat, 26 Mar 2016 02:57:38 +0000
    Randy Stauner wrote:
    As a maintainer of one of the problem modules (Test::Aggregate) i should
    have something to say, but I haven't been able to spend more than an hour
    with Perl in the last year so i don't know when I'll be able to work on
    making it work with the changes. I see no reason to hold up progress on
    this any longer, so "sounds good" to me.
    I may be willing to do some work on Test-Aggregate for that. Otherwise, my use
    of Test::More and Test::Builder is probably contained only to the very
    high-level API , so I don't expect anything major to break, so "sounds good" to
    me as well.

    Regards,

      Shlomi Fish

    --
    -----------------------------------------------------------------
    Shlomi Fish http://www.shlomifish.org/
    List of Portability Libraries - http://shlom.in/port-libs

    The C Preprocessor - There’s not supposed to be a way to do it.
         — http://www.shlomifish.org/humour/ways_to_do_it.html

    Please reply to list if it's a mailing list post - http://shlom.in/reply .
  • Randy Stauner at Apr 4, 2016 at 4:10 am
    Thanks. Any help is appreciated.
    Here are some relevant urls:

    https://github.com/rwstauner/test-aggregate/issues/2
    https://rt.cpan.org/Ticket/Display.html?id=100035
    https://metacpan.org/pod/distribution/Test2/lib/Test2/Transition.pod
    On Sat, Mar 26, 2016 at 1:44 AM Shlomi Fish wrote:

    Hi all,

    On Sat, 26 Mar 2016 02:57:38 +0000
    Randy Stauner wrote:
    As a maintainer of one of the problem modules (Test::Aggregate) i should
    have something to say, but I haven't been able to spend more than an hour
    with Perl in the last year so i don't know when I'll be able to work on
    making it work with the changes. I see no reason to hold up progress on
    this any longer, so "sounds good" to me.
    I may be willing to do some work on Test-Aggregate for that. Otherwise, my
    use
    of Test::More and Test::Builder is probably contained only to the very
    high-level API , so I don't expect anything major to break, so "sounds
    good" to
    me as well.

    Regards,

    Shlomi Fish

    --
    -----------------------------------------------------------------
    Shlomi Fish http://www.shlomifish.org/
    List of Portability Libraries - http://shlom.in/port-libs

    The C Preprocessor - There’s not supposed to be a way to do it.
    http://www.shlomifish.org/humour/ways_to_do_it.html

    Please reply to list if it's a mailing list post - http://shlom.in/reply .
  • Chad Granum at Apr 4, 2016 at 4:28 am
    I am also happy to help out with information if you get hung up on anything.
    On Sun, Apr 3, 2016 at 9:09 PM, Randy Stauner wrote:

    Thanks. Any help is appreciated.
    Here are some relevant urls:

    https://github.com/rwstauner/test-aggregate/issues/2
    https://rt.cpan.org/Ticket/Display.html?id=100035
    https://metacpan.org/pod/distribution/Test2/lib/Test2/Transition.pod
    On Sat, Mar 26, 2016 at 1:44 AM Shlomi Fish wrote:

    Hi all,

    On Sat, 26 Mar 2016 02:57:38 +0000
    Randy Stauner wrote:
    As a maintainer of one of the problem modules (Test::Aggregate) i should
    have something to say, but I haven't been able to spend more than an hour
    with Perl in the last year so i don't know when I'll be able to work on
    making it work with the changes. I see no reason to hold up progress on
    this any longer, so "sounds good" to me.
    I may be willing to do some work on Test-Aggregate for that. Otherwise,
    my use
    of Test::More and Test::Builder is probably contained only to the very
    high-level API , so I don't expect anything major to break, so "sounds
    good" to
    me as well.

    Regards,

    Shlomi Fish

    --
    -----------------------------------------------------------------
    Shlomi Fish http://www.shlomifish.org/
    List of Portability Libraries - http://shlom.in/port-libs

    The C Preprocessor - There’s not supposed to be a way to do it.
    http://www.shlomifish.org/humour/ways_to_do_it.html

    Please reply to list if it's a mailing list post - http://shlom.in/reply
    .
  • Leon Timmermans at Apr 7, 2016 at 4:59 pm

    On Sat, Mar 19, 2016 at 6:03 PM, Chad Granum wrote:
    RJBS and I have spoken, and feel it is time to set a release date for
    Test2/Test-Builder. We have agreed that doing it at the QAH in Rugby is a
    good time. The plan is to release Test2 and the new Test::Builder as stable
    either at the end of the first day, or the start of the second day (so the
    21st or 22nd of april). This gives a full day for people to grab me in
    person to talk about it, and address any issues. It also gives 2 full days
    after the release where my attention can be fully devoted if any issues are
    discovered post-release.

    I expect little if any changes to occur in the code between now and then.
    Possibly some small bug fixes, documentation updates, etc. nothing big. I
    will continue to listen to any feedback that is provided, and take any
    necessary action. In the meantime RJBS is going to be pinging stakeholders
    from the punch-list (
    https://github.com/Test-More/test-more/wiki/Test-Builder-v1.3-Punchlist)
    to make sure all requirements have been met.

    What exactly is going stable?

    * Test2 (experimental notices will be removed)

    * Test::Builder that uses Test2 under the hood (as seen here:
    https://metacpan.org/release/EXODIST/Test-Simple-1.302013_014)

    * Test2-Suite (experimental notices will be removed)

    * Final Test2/Test-Simple patch for perl blead (Test-Suite is not going
    into blead)

    I look forward to seeing you all in Rugby!

    I think 1 is a good idea, but I have some reservations about the 2 (and
    thus 4). Is it really advantageous to switch over everyone to Test2 today?

    I think Test2 has major benefits for some people (it makes new things
    possible), but it also has major disadvantages for others (it breaks
    stuff); both have unknown upper bounds. And to be honest, for the vast
    majority I don't feel like it will matter; they don't need (much) more than
    Test::More.

    Wouldn't it make more sense to make this opt-in?

    Leon
  • Chad Granum at Apr 7, 2016 at 7:06 pm


    I think 1 is a good idea, but I have some reservations about the 2 (and
    thus 4). Is it really advantageous to switch over everyone to Test2 today?

    I think Test2 has major benefits for some people (it makes new things
    possible), but it also has major disadvantages for others (it breaks
    stuff); both have unknown upper bounds. And to be honest, for the vast
    majority I don't feel like it will matter; they don't need (much) more than
    Test::More.

    Wouldn't it make more sense to make this opt-in?

    Leon
    The main benefits of switch as opposed to opt-in are these:

      * Only maintaining one system. Yes we still need to maintain Test::Builder
    and Test2, but when combined it reduces the cognitive overhead, and the
    disconnect between the 2.
      * The code to switch includes bugfixes that cannot be easily/sanely
    backported to old test builder
         - Threads + Subtests
         - Forking + Subtests
         - False pass if parent finishes before child thread/process where child
    then has a failure
         - Probably more
      * People will not have to be worried about something downstream switching
    and thus forcing them to switch unknowingly (cause the switch happens once,
    for everyone)

    The problems of making it opt-in are the same problems you always get when
    you maintain 2 separate but similar things. Things become desynchronized
    between them. People have to write their stuff to support both, or simply
    make their code die with a message telling you not to use one or the other.
    If we do not combine these then we put the burden of supporting both on
    everyone else. If however the next Test::Builder used Test2 then the burden
    is on me and any other Test2/Test::Builder maintainer. Yes there is still
    the toolchain burden of making sure stuff works on new and old
    Test::Builder, but toolchain is already its own beast.


    I think Test2 has major benefits for some people (it makes new things
    possible), but it also has major disadvantages for others (it breaks
    stuff); both have unknown upper bounds. And to be honest, for the vast
    majority I don't feel like it will matter; they don't need (much) more than
    Test::More.

    The main disadvantage is that it "breaks stuff". I do not want to
    trivialize this, it is a huge concern. And you are correct, we do not know
    the upper bound. What we do know though is that cpan shows us. Currently
    the breakage on cpan is very small, limited to only a handful of modules,
    many of which already have pending patches, or people willing to pick them
    up. And most, if not all of what breaks is people bypassing Test::Builders
    public API's and mucking about directly with internals. Even in these cases
    hoops have been jumped though to support as many of these bad practices as
    technically possible.

    I do not want to dismiss or trivialize the disadvantages, I want to be
    clear on that. However I consider the advantages to have significantly more
    weight here. I think the burden on cpan of supporting a split system here
    is a much higher risk. If the author of Test::Moose for instance decides to
    switch to Test2, then any test that consumes it switches automatically. If
    there is a conflict in any of the used tools then people have breakage, and
    it is not as predictable. If we switch all at once though, then a module
    author deciding to switch simply needs to bump up the minimum Test::Builder
    version required, anything that works on that higher version *should* be
    set.

    -Chad

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupqa @
categoriesperl
postedMar 19, '16 at 5:03p
activeApr 7, '16 at 7:06p
posts8
users5
websiteqa.perl.org

People

Translate

site design / logo © 2019 Grokbase