[wp-trac] [WordPress Trac] #45160: Suggest updating Trac "Create New Ticket" instructions for reporting Gutenberg-related bugs in V5.0+ releases

[WordPress Trac]

#45160: Suggest updating Trac "Create New Ticket" instructions for reporting
Gutenberg-related bugs in V5.0+ releases
--------------------------------+---------------------
 Reporter:  timhibberd          |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  5.0.1
Component:  WordPress.org site  |     Version:  5.0
 Severity:  normal              |  Resolution:
 Keywords:                      |     Focuses:
--------------------------------+---------------------

Comment (by timhibberd):

 Thanks @SergeyBiryukov / @matveb for your assistance. Much appreciated.

 I have a few questions that might help narrow down my general question
 w.r.t. bug tracking in the WP4.x/WP5.x/GBE/CE world (NOTE: CE = Classic
 Editor).

 Question1: Based on my understanding Gutenberg plug-in is a superset of
 the WP5.x GB core editor and will be the vehicle used to deliver new GB
 features for soak and adoption before the new features are moved into the
 WP5.x GB core editor. Is that correct?

 Question2: Is the WP5.x GB core editor a 100% cleanly extractable subset
 component of the GB plug-in that is simply disabled in the GB plug-in when
 the GB plug-in is installed and active on a WP5.x site?

 Question3: If so, does that mean new GB feature related bugs are reported
 in GitHub and current GB bugs are reported via Trac?

 Moving forward, there are six deployment options that will be operating &
 maintained in the field:

 {{{
 A) WP 4.x
 B) WP 4.x + GBE plug-in
 C) WP 5.x
 D) WP 5.x + CE plug-in
 E) WP 5.x + GBE plug-in
 F) WP 5.x + GBE plug-in + CE plug-in
 }}}


 As an example, I will be operating my sites and client sites using option
 (B) until March 2019 then operating using option(D) and slowly migrating
 my clients to option (C) over time. After March 2019 all our new sites
 will be on option (C). Option (E) is a "wait-and-see" deployment option
 for our sites at this point mainly based on my confusion w.r.t. Question2
 above. If GB Core is not a 100% cleanly extractable subset component of
 the GB plug-in then bug management on a WP5.x + GB plug-in deployment gets
 tricky due to an overlapping code-base.

 Question4: What is the best way to report bugs into Trac and / or GitHub
 capturing which of these 6 deployment options is in play?

 Tangent Question: Is there any reason GB plug-in is in Github and not
 GitLab? GitLab offers a full automated CI pipeline at no charge for open-
 source projects. I have used GitLab for my projects and client projects
 for years. Highly reliable and incredible feature set (not a plug...I am
 not an affiliate and don't do work for them).

 Thanks for your assistance and all the great work you and the GB team have
 been doing. Much appreciated :-)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45160#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform