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 > > > > > >
