Looks like we have general consensus on scope here. I've rechecked the changes merged to master and that those JIRA issues are properly tagged. Current scope stands at:
https://issues.apache.org/jira/issues/?jql=Project%20%3D%20GUACAMOLE%20AND%20fixVersion%20%3D%201.2.0%20ORDER%20BY%20Status%20ASC%2C%20Watchers%2C%20Votes%2C%20Priority I'll move forward with creating the "staging/1.2.0" branches and we'll be underway. - Mike On Tue, Feb 11, 2020 at 2:26 PM Nick Couchman <[email protected]> wrote: > Okay, I've tagged all of the issues for the 1.2.0 release, so we have a > good idea of what needs to be knocked out to get the 1.2.0 release done > :-). > > -Nick > > On Tue, Feb 11, 2020 at 9:43 AM Nick Couchman <[email protected]> wrote: > > > Thanks for fixing those issues up, Mike. > > > > I'm totally good being flexible with the 1.2.0 release and factoring in > > some of the bug fixes and minor tweaks coming off the 1.1.0 release. My > > biggest goal is to keep the momentum up and release 1.2.0 sometime prior > to > > January 2021 :-D. In all seriousness, though, I'd like to limit the > > feature creep on this release so that we don't end up with any huge > > blockers and can turn it around a little more quickly. > > > > -Nick > > > > On Mon, Feb 10, 2020 at 9:48 PM Mike Jumper <[email protected]> wrote: > > > >> This list looks good to me, and the scope is fairly minimal. I think we > >> should plan to be flexible and include bugs that can demonstrated to be > >> regressions from 1.1.0, even if those bugs are not yet currently known > and > >> even if scope is otherwise settled, unless we're so far down the release > >> or > >> the bug is so minor that the disruption to the scope outweighs the > benefit > >> of a next-release fix. > >> > >> In general, from my perspective, a 1.2.0 release should include (at a > >> minimum): > >> > >> * Issues for which code has already been merged (naturally). > >> * Issues which are known regressions from 1.1.0. > >> * Issues which are not yet known, are discovered after 1.2.0 is already > >> underway, but are determined to be regressions from 1.1.0. > >> > >> I'm mainly concerned that we'll find something down the line where a > flag > >> like freerdp->dont_be_broken became freerdp->DoBeBroken in a later > >> release, > >> we didn't notice during the 2.0.0 migration, and things are still being > >> set > >> to TRUE. There may well be little surprises in the internal behavior of > >> FreeRDP that we just won't discover until enough users have pummeled > 1.1.0 > >> that they happen to pull the right book or lift the right candle and a > >> secret passageway opens. > >> > >> I'm happy to see the issues that Nick listed included, as well. I only > >> found the following problems: > >> > >> * Changes for GUACAMOLE-300 have been merged to master for 1.2.0 but the > >> issue was not tagged for 1.2.0. I've updated the issue. > >> * Changes for GUACAMOLE-846 have been merged to master for 1.2.0 but the > >> issue was not tagged for 1.2.0. I've updated the issue. > >> * GUACAMOLE-915 was implicitly fixed for 1.1.0 by GUACAMOLE-930 when it > >> was > >> identified as a regression. I've updated the issue. > >> > >> So, with 300 and 846 being necessarily included, with 915 being removed, > >> and with a nod toward regression flexibility, I'm good with the list as > it > >> stands. > >> > >> - Mike > >> > >> > >> On Mon, Feb 3, 2020 at 5:03 PM Nick Couchman <[email protected]> wrote: > >> > >> > Thanks for the input, Sean - I definitely agree on trying to maintain > >> > smaller scopes in general going forward. I would like to see us be > >> able to > >> > actually use the patch version and do some bug fixes or minor > >> > improvements. It feels like we've spent the past couple of years > >> catching > >> > up on a backlog that includes some pretty big feature enhancements, > and > >> it > >> > has made it difficult to build a momentum for releases. If we could > >> get a > >> > 1.2.0 release done in a small handful of weeks, perhaps we could start > >> > tightening those scopes down a little more and get a good cadence. > >> > > >> > Anyway, if anyone else has input on scope for 1.2.0, please throw that > >> out > >> > there, and we can assign remaining issues to 1.2.0 and start work > >> towards > >> > closing it out. > >> > > >> > -Nick > >> > > >> > On Mon, Feb 3, 2020 at 19:27 Sean Reid <[email protected]> wrote: > >> > > >> > > I don't want to speak much to the scope of this potential release (I > >> > don't > >> > > see any issues with the scope you've outlined, especially since most > >> of > >> > the > >> > > issues are done or have PRs already), but I do agree with your final > >> > > sentiments: to limit the scope so that we can release it quickly and > >> move > >> > > into the next release phase. I tend to prefer a quicker release > >> cadence > >> > > because it can reduce the changes that changes get unwieldy pretty > >> > > naturally and it can help avoid too many big changes that can have > >> > > unintended consequences to stability. I think it can also help > >> minimize > >> > the > >> > > time that a user has to wait from the time a bug is discovered to > when > >> > they > >> > > potentially have a release with a fix. > >> > > > >> > > Sean > >> > > > >> > > On Sun, Feb 2, 2020 at 4:37 PM Nick Couchman < > >> [email protected]> > >> > > wrote: > >> > > > >> > > > Hey, everyone, > >> > > > I know I'm always the one pushing things, but I'd like to start > >> > focusing > >> > > in > >> > > > on scope for the 1.2.0 release. We already have 37 items tagged > for > >> > it, > >> > > > two of them open, and probably a few more that we could throw into > >> the > >> > > mix > >> > > > before we release 1.2.0. > >> > > > > >> > > > First, I want to make sure that 1.2.0 is the correct version for > >> this. > >> > > It > >> > > > seems appropriate to me - it's more than a minor bug fix release, > >> but > >> > I'm > >> > > > not sure there's anything at this point that would push it into a > >> major > >> > > > release candidate. But, if anyone has thoughts on that, feel free > >> to > >> > > > share. > >> > > > > >> > > > As far as scope goes, here are the issues currently tagged in that > >> > > version > >> > > > in JIRA ( > >> > > > > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12345046 > >> > > > ): > >> > > > 296 (RDP audio input disconnect) > >> > > > 764 (RDPDR file read/write truncated to 32 bits) > >> > > > 822 (Balancing group missing client identifier) > >> > > > 870 (Connection history query fails against SQL Server) > >> > > > 302 (Refocus relevant in-progress login fields after auth failure) > >> > > > 381 (Allow clipboard access to be disabled) > >> > > > 414 (VNC server TLS disconnect) > >> > > > 514 (Additional VNC authentication methods) > >> > > > 625 (RDP Spanish LATAM Keyboard support) > >> > > > 684 (Insufficient credentials take precedence over Invalid > >> credentials) > >> > > > 723 (Support display of multiple connections in same tab) > >> > > > 732 (navigator.mediaDevices.getUserMedia() returns promise) > >> > > > 736 (CAS module fails against JDK 11) > >> > > > 740 (Spanish translation hard-coded version number) > >> > > > 749 (Filter affects only first level of connection permissions > >> editor) > >> > > > 769 (Parse RADIUS Challenge message correctly) > >> > > > 774 (RADIUS support for MS-CHAPv1/2) > >> > > > 781 (Czech translation) > >> > > > 783 (REST API responses cached in IE11) > >> > > > 784 (Tolerate port number in X-Forwarded-For header) > >> > > > 805 (OpenID authentication redirect loop) > >> > > > 817 (Enter key may repeat following login in FF) > >> > > > 821 (Japanese translation) > >> > > > 837 (RDP keymap for Hungarian keyboard) > >> > > > 859 (Caps Lock keysym via RDP) > >> > > > 861 (Correct Windows Time in drive redirection) > >> > > > 871 (Cursor visibility flag support in terminal) > >> > > > 884 (Avoid Image where possible without performance penalty) > >> > > > 889 (Mismatching attribute names in LDAP schema) > >> > > > 897 (Docker support for restricting authentication to DB) > >> > > > 901 (RDP Belgian French keyboard layout) - Server-side complete, > >> needs > >> > > > client-side changes > >> > > > 905 (Chrome audio input broken) > >> > > > 678 (UriGuacamoleProperty) > >> > > > 734 (Update logback-classic version) > >> > > > 741 (Spanish translation duplicates APP.NAME string) > >> > > > 742 (Display feedback while waiting for login) > >> > > > 772 (Reduce guacd Docker image size) > >> > > > 852 (MariaDB JDBC Support) > >> > > > > >> > > > In addition to these, I'd propose adding the following issues to > the > >> > > scope > >> > > > and then finalizing and working toward that over the coming weeks: > >> > > > 942 (Possible MySQL regression) > >> > > > 917 (Fix tilde mapping in German keyboard) > >> > > > 915 (Move $apply to $applyAsync to fix international selector) > >> > > > 728 (MySQL SSL issue) > >> > > > 883 (iOS 13 touch screen regression) > >> > > > 903 (Chinese internationalization improvements) > >> > > > 474 (Allow file upload and download to be disabled) - PR in > progress > >> > > > 793 (CAS Group Support) - PR is out there > >> > > > 818 (Missing files in SFTP) - Change has been suggested on the > JIRA > >> > > issue, > >> > > > but no PR. > >> > > > 820 (IP address filtering) - Looks like cause has been identified, > >> just > >> > > > needs a fix) > >> > > > 823 (Empty balancing group regression) - This has been bisected > >> down to > >> > > > cause, just needs fix > >> > > > 759 (French translation fixed) - PR needs review > >> > > > 708 (Auto-create JDBC users) - PR needs work and review > >> > > > 513 (Wake On LAN extension) - PR being worked > >> > > > 103 (SAML Authentication) - PR is out there, needs rebase, review > >> and > >> > > > testing > >> > > > 583 (SQL Server instance config) - Code is done, waiting on > testing > >> and > >> > > > need to submit PR > >> > > > 465 (guacenc codec support) - PR is being worked > >> > > > > >> > > > There are several other issues out there getting a lot of > attention > >> and > >> > > > work - like Single Log Out for the SSO modules, but I'm > >> intentionally > >> > > > trying to limit scope to stuff that is already pretty well in > >> progress > >> > > and > >> > > > can be reviewed, merged, and worked toward the next release. If > >> there > >> > > are > >> > > > others that someone thinks we should add on, please feel free to > >> > suggest > >> > > > them, but my suggestion at this point is to avoid letting the > scope > >> get > >> > > too > >> > > > big for the next release so that we can get it out there pretty > >> > quickly, > >> > > > and then we can work toward 1.2.1 or 1.3.0 or whatever we decide > >> comes > >> > > > after that. If anyone thinks we should be more restrictive in > scope > >> > and > >> > > > take some of the others I suggested above off the list, that's > fine, > >> > too > >> > > - > >> > > > let's discuss! > >> > > > > >> > > > -Nick > >> > > > > >> > > > >> > > >> > > >
