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