Re: [DISCUSS] Beyond 1.0.0

[Mike Jumper]

On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman  wrote:

> On Fri, Jan 11, 2019 at 8:11 AM carl harris  wrote:
> ...
> >
> > Many products have skirted this question by dropping the semantic
> > versioning in favor of some sort of version scheme based on a time-boxed
> > release cycle. Would something like that be more appropriate here? What
> > would that mean with respect to versioning for the API that Guacamole
> > exposes for extensions and such?
> >
>
> I'm not opposed to such a versioning scheme.  My only question would be how
> to deal with the API-level changes that you mentioned before, and that
> we've currently identified for the "major release" changes?  Is there a way
> that these sort of time-boxed releases handle that in the versioning?
>

Another option might be to provide some sort of API compatibility layer
within the webapp, allowing the extensions of prior releases to continue to
function. If compatibility doesn't break as a result of API changes,
there's no need for a full major version bump, and downstream migration for
future releases is much easier.

- Mike

[GitHub] guacamole-website pull request #68: GUACAMOLE-693: Update copyright year to ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/guacamole-website/pull/68


---

[GitHub] guacamole-website pull request #68: GUACAMOLE-693: Update copyright year to ...

[ohmar]

GitHub user ohmar opened a pull request:

https://github.com/apache/guacamole-website/pull/68

GUACAMOLE-693: Update copyright year to 2019



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ohmar/guacamole-website master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/guacamole-website/pull/68.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #68






---

[GitHub] guacamole-client pull request #355: GUACAMOLE-271: Duo in docker image

[scottpas]

GitHub user scottpas opened a pull request:

https://github.com/apache/guacamole-client/pull/355

GUACAMOLE-271: Duo in docker image

Added Duo to the docker build and start scripts.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/scottpas/guacamole-client 
feature_duo_auth_plugin

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/guacamole-client/pull/355.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #355


commit cd0d95394a5f0f54fa3c4d26863300b6b4962869
Author: Scott Paschke 
Date:   2019-01-11T18:33:15Z

add Duo to Docker build




---

Build failed in Jenkins: guacamole-server-coverity #58

[Apache Jenkins Server]

See 


--
Started by user mjumper
[EnvInject] - Loading node environment variables.
Building remotely on H25 (ubuntu xenial) in workspace 

[WS-CLEANUP] Deleting project workspace...
[WS-CLEANUP] Deferred wipeout is used...
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/guacamole-server.git
 > git init 
 > 
 >  # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/guacamole-server.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/guacamole-server.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/guacamole-server.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/guacamole-server.git # timeout=10
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/guacamole-server.git
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/guacamole-server.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 768b2ba0f5fbf3517541e1038c2c02dcad47023e (origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 768b2ba0f5fbf3517541e1038c2c02dcad47023e
Commit message: "GUACAMOLE-661: Merge mark "nest" instruction and socket as 
deprecated."
 > git rev-list --no-walk 768b2ba0f5fbf3517541e1038c2c02dcad47023e # timeout=10
[EnvInject] - Mask passwords that will be passed as build parameters.
[guacamole-server-coverity] $ /bin/bash -xe /tmp/jenkins8709997880396189579.sh
+ cat
[guacamole-server-coverity] $ /bin/bash -xe /tmp/jenkins387919154909797046.sh
+ cat
[guacamole-server-coverity] $ /bin/bash -xe /tmp/jenkins8205228707727350394.sh
+ cat
[guacamole-server-coverity] $ /bin/bash -xe /tmp/jenkins3404243782569499554.sh
+ export TAG=guac-jenkins-guacamole-server-coverity-58
+ TAG=guac-jenkins-guacamole-server-coverity-58
+ trap 'docker rmi --force guac-jenkins-guacamole-server-coverity-58 || true' 
EXIT
+ docker build --no-cache=true --rm --tag 
guac-jenkins-guacamole-server-coverity-58 --build-arg COVERITY_TOKEN=[***] 
--build-arg COVERITY_EMAIL=[***] .
Sending build context to Docker daemon  10.21MB
Step 1/8 : FROM centos:centos7
centos7: Pulling from library/centos
Digest: sha256:184e5f35598e333bfa7de10d8fb1cebb5ee4df5bc0f970bf2b1e7c7345136426
Status: Downloaded newer image for centos:centos7
 ---> 1e1148e4cc2c
Step 2/8 : ARG COVERITY_TOKEN=local
 ---> Running in 15d84573b973
 ---> bf8aabd94e1e
Removing intermediate container 15d84573b973
Step 3/8 : ENV COVERITY_TOKEN [***]
 ---> Running in d279323bab51
 ---> 1f0c653cdae0
Removing intermediate container d279323bab51
Step 4/8 : ARG COVERITY_EMAIL=local
 ---> Running in d9601dc49835
 ---> 7bea05ce5d9f
Removing intermediate container d9601dc49835
Step 5/8 : ENV COVERITY_EMAIL [***]
 ---> Running in 154c4cea9205
 ---> 614d111c9b2e
Removing intermediate container 154c4cea9205
Step 6/8 : COPY . /build/
 ---> 5fb65e8fc901
Removing intermediate container aff0ddc7e437
Step 7/8 : RUN /bin/bash -e -x /build/install-deps.sh
 ---> Running in d3ed8e3fb11e
+ mkdir -p /opt
+ cd /opt
+ curl --data-urlencode token=[***] --data-urlencode 
project=guacamole-server https://scan.coverity.com/download/linux64
+ tar -xz
  % Total% Received % Xferd  Average Speed   TimeTime Time 
 Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0100530 0  10053  0 95 --:--:-- 
--:--:-- --:--:--95

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
The command '/bin/sh -c /bin/bash -e -x /build/install-deps.sh' returned a 
non-zero code: 1
+ docker rmi --force guac-jenkins-guacamole-server-coverity-58
Error response from daemon: No such image: 
guac-jenkins-guacamole-server-coverity-58:latest
+ true
Build step 'Execute shell' marked build as failure

Re: [DISCUSS] Beyond 1.0.0

[Nick Couchman]

On Fri, Jan 11, 2019 at 8:11 AM carl harris  wrote:

> Just a thought, but perhaps we should start by considering how the
> evolution of the product should be reflected in the versioning.
>

Agreed.


>
> Are we committed to semantic versioning? For API, semantic versioning
> generally has very specific set of conventions. However, in my experience,
> for a software product, the relationship between features and version
> numbers is much less clear cut. What kinds of new features should
> constitute a major or minor version increment?
>

I don't know if I would say "committed" to it, but we decided back
post-0.9.14 and pre-1.0.0 that we would move forward with semantic
versioning, where API-related changes are major versions (1.0.0 -> 2.0.0),
feature changes are minor versions (1.0.0 -> 1.1.0), and then bug fixes are
release versions (1.0.0 -> 1.0.1).  I don't have the exact link at my
fingertips, but the proposed/accepted proposal at the time was:
- Changes which impact the overall API and thus change or break
compatibility between components within the product would be major version
changes.  This would be most changes to guacamole-ext and guacamole-common
components.
- Changes which introduce new features or significant code changes to
extensions, but which do not break compatibility, would be minor version
changes.
- Changes which are very simple, bug fixes, etc., would be release versions.

I think I have accurately represented it - I'm having trouble digging up
the link.


>
> Many products have skirted this question by dropping the semantic
> versioning in favor of some sort of version scheme based on a time-boxed
> release cycle. Would something like that be more appropriate here? What
> would that mean with respect to versioning for the API that Guacamole
> exposes for extensions and such?
>

I'm not opposed to such a versioning scheme.  My only question would be how
to deal with the API-level changes that you mentioned before, and that
we've currently identified for the "major release" changes?  Is there a way
that these sort of time-boxed releases handle that in the versioning?


>
> Again, just trying to stimulate some discussion here.
>
>
Definitely appreciated!

-Nick

Re: [DISCUSS] Beyond 1.0.0

[carl harris]

Just a thought, but perhaps we should start by considering how the evolution of 
the product should be reflected in the versioning. 

Are we committed to semantic versioning? For API, semantic versioning generally 
has very specific set of conventions. However, in my experience, for a software 
product, the relationship between features and version numbers is much less 
clear cut. What kinds of new features should constitute a major or minor 
version increment?

Many products have skirted this question by dropping the semantic versioning in 
favor of some sort of version scheme based on a time-boxed release cycle. Would 
something like that be more appropriate here? What would that mean with respect 
to versioning for the API that Guacamole exposes for extensions and such?

Again, just trying to stimulate some discussion here.

carl


> On Jan 11, 2019, at 5:16 AM, Nick Couchman  wrote:
> 
> At the risk of raining on the parade of having just released one of the
> biggest sets of changes in Guacamole's history, I'd like to kick off the
> discussion on where we go from here.
> 
> We have our new versioning scheme, inaugurated here in the 1.0.0 release,
> which should allow us to release more often and provide incremental bug
> fixes and feature releases.  However, we already have several changes in
> the git master branch that represent another major release - 2.0.0.
> Furthermore, as you'd expect with any major release like 1.0.0, we've had a
> few bugs pop up that probably need to be squashed quickly.  So, as I see
> it, we have a couple of options...
> 
> 1) Work toward a 2.0.0 release here in the near-future (weeks?), with the
> current list of items in JIRA plus whatever bugs come up over the next
> couple of weeks.  According to JIRA we already have 32 issues tagged for
> 2.0.0 - 27 of them completed.  I would imagine a handful of the recent
> identified bugs could also get added to that list.  From 2.0.0 we could
> move toward maintaining a couple of different branches that would allow for
> a little more flexibility in controlling releases.
> 
> 2) Try to do a 1.0.1 release made up of mostly bug fixes.  We'd have to
> create a branch from the 1.0.0 tag and then work to merge in any of the
> commits from the current master head that are deemed minor enough to
> qualify for a bug fix release.  We can also incorporate in some of the
> issues that are popping up right now as people are finding them on the
> 1.0.0 release.  I'm going to guess that this will require quite a bit more
> effort to accomplish - extracting out the changes from master and sort of
> "back-porting" them to where the 1.0.0 code is will probably require some
> massaging of the code in certain places, and I wonder if it's really worth
> all of that work and how quickly we could get that done?
> 
> Those are my two ideas - maybe there are others?  I think I'm more in favor
> of pushing forward with a 2.0.0 release quickly and then beginning to
> maintain other branches from that point that would allow us to better
> leverage our new versioning scheme.
> 
> Anyone else have ideas/thoughts about this?  I've not been actively
> involved in many other software development projects, so not sure how this
> is generally handled, either in Open Source projects or in the commercial
> software world?
> 
> -Nick

[DISCUSS] Beyond 1.0.0

[Nick Couchman]

At the risk of raining on the parade of having just released one of the
biggest sets of changes in Guacamole's history, I'd like to kick off the
discussion on where we go from here.

We have our new versioning scheme, inaugurated here in the 1.0.0 release,
which should allow us to release more often and provide incremental bug
fixes and feature releases.  However, we already have several changes in
the git master branch that represent another major release - 2.0.0.
Furthermore, as you'd expect with any major release like 1.0.0, we've had a
few bugs pop up that probably need to be squashed quickly.  So, as I see
it, we have a couple of options...

1) Work toward a 2.0.0 release here in the near-future (weeks?), with the
current list of items in JIRA plus whatever bugs come up over the next
couple of weeks.  According to JIRA we already have 32 issues tagged for
2.0.0 - 27 of them completed.  I would imagine a handful of the recent
identified bugs could also get added to that list.  From 2.0.0 we could
move toward maintaining a couple of different branches that would allow for
a little more flexibility in controlling releases.

2) Try to do a 1.0.1 release made up of mostly bug fixes.  We'd have to
create a branch from the 1.0.0 tag and then work to merge in any of the
commits from the current master head that are deemed minor enough to
qualify for a bug fix release.  We can also incorporate in some of the
issues that are popping up right now as people are finding them on the
1.0.0 release.  I'm going to guess that this will require quite a bit more
effort to accomplish - extracting out the changes from master and sort of
"back-porting" them to where the 1.0.0 code is will probably require some
massaging of the code in certain places, and I wonder if it's really worth
all of that work and how quickly we could get that done?

Those are my two ideas - maybe there are others?  I think I'm more in favor
of pushing forward with a 2.0.0 release quickly and then beginning to
maintain other branches from that point that would allow us to better
leverage our new versioning scheme.

Anyone else have ideas/thoughts about this?  I've not been actively
involved in many other software development projects, so not sure how this
is generally handled, either in Open Source projects or in the commercial
software world?

-Nick

[GitHub] guacamole-website pull request #67: Archive releases older than 1.0.0.

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/guacamole-website/pull/67


---

[GitHub] guacamole-client pull request #351: GUACAMOLE-683: Add OpenID support in Doc...

[mike-jumper]

Github user mike-jumper commented on a diff in the pull request:

https://github.com/apache/guacamole-client/pull/351#discussion_r247040348
  
--- Diff: guacamole-docker/bin/start.sh ---
@@ -404,6 +404,42 @@ END
 ln -s /opt/guacamole/radius/guacamole-auth-*.jar "$GUACAMOLE_EXT"
 }
 
+## Adds properties to guacamole.properties which select the OPENID
+## authentication provider, and configure it to connect to the specified 
OPENID
+## provider.
+##
+associate_openid() {
+
+# Verify required parameters are present
+if [ -z "$OPENID_AUTHORIZATION_ENDPOINT" ] || \
+   [ -z "$OPENID_JWKS_ENDPOINT" ]  || \
+   [ -z "$OPENID_ISSUER" ] || \
+   [ -z "$OPENID_CLIENT_ID" ]  || \  
+   [ -z "$OPENID_REDIRECT_URI" ]
+then
+cat