unattended-upgrades result for jena-vm.apache.org: SUCCESS
Unattended upgrade result: All upgrades installed Packages that were upgraded: libnetplan0 netplan.io openjdk-17-jdk openjdk-17-jdk-headless openjdk-17-jre openjdk-17-jre-headless openjdk-8-jre-headless Package installation log: Log started: 2023-11-30 06:22:02 apt-listchanges: Reading changelogs... apt-listchanges: Reading changelogs... Preparing to unpack .../openjdk-17-jdk_17.0.9+9-1~20.04_amd64.deb ... Unpacking openjdk-17-jdk:amd64 (17.0.9+9-1~20.04) over (17.0.8.1+1~us1-0ubuntu1~20.04) ... Preparing to unpack .../openjdk-17-jdk-headless_17.0.9+9-1~20.04_amd64.deb ... Unpacking openjdk-17-jdk-headless:amd64 (17.0.9+9-1~20.04) over (17.0.8.1+1~us1-0ubuntu1~20.04) ... Preparing to unpack .../openjdk-17-jre_17.0.9+9-1~20.04_amd64.deb ... Unpacking openjdk-17-jre:amd64 (17.0.9+9-1~20.04) over (17.0.8.1+1~us1-0ubuntu1~20.04) ... Preparing to unpack .../openjdk-17-jre-headless_17.0.9+9-1~20.04_amd64.deb ... Unpacking openjdk-17-jre-headless:amd64 (17.0.9+9-1~20.04) over (17.0.8.1+1~us1-0ubuntu1~20.04) ... Setting up openjdk-17-jre-headless:amd64 (17.0.9+9-1~20.04) ... Installing new version of config file /etc/java-17-openjdk/security/public_suffix_list.dat ... Setting up openjdk-17-jre:amd64 (17.0.9+9-1~20.04) ... Setting up openjdk-17-jdk-headless:amd64 (17.0.9+9-1~20.04) ... Setting up openjdk-17-jdk:amd64 (17.0.9+9-1~20.04) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for mime-support (3.64ubuntu1) ... Log ended: 2023-11-30 06:22:52 Log started: 2023-11-30 06:22:52 apt-listchanges: Reading changelogs... apt-listchanges: Reading changelogs... Preparing to unpack .../netplan.io_0.104-0ubuntu2~20.04.4_amd64.deb ... Unpacking netplan.io (0.104-0ubuntu2~20.04.4) over (0.104-0ubuntu2~20.04.2) ... Preparing to unpack .../libnetplan0_0.104-0ubuntu2~20.04.4_amd64.deb ... Unpacking libnetplan0:amd64 (0.104-0ubuntu2~20.04.4) over (0.104-0ubuntu2~20.04.2) ... Setting up libnetplan0:amd64 (0.104-0ubuntu2~20.04.4) ... Setting up netplan.io (0.104-0ubuntu2~20.04.4) ... Processing triggers for libc-bin (2.31-0ubuntu9.12) ... Processing triggers for man-db (2.9.1-1) ... Processing triggers for dbus (1.12.16-2ubuntu2.3) ... Log ended: 2023-11-30 06:22:57 Log started: 2023-11-30 06:22:58 apt-listchanges: Reading changelogs... apt-listchanges: Reading changelogs... Preparing to unpack .../openjdk-8-jre-headless_8u392-ga-1~20.04_amd64.deb ... Unpacking openjdk-8-jre-headless:amd64 (8u392-ga-1~20.04) over (8u382-ga-1~20.04.1) ... Setting up openjdk-8-jre-headless:amd64 (8u392-ga-1~20.04) ... Log ended: 2023-11-30 06:23:15 Unattended-upgrades log: Starting unattended upgrades script Allowed origins are: origin=Ubuntu,suite=focal, origin=Ubuntu,suite=focal-security, origin=Ubuntu,suite=focal-backports, origin=Ubuntu,suite=focal-updates Initial blacklist: Initial whitelist (not strict): Packages that will be upgraded: libnetplan0 netplan.io openjdk-17-jdk openjdk-17-jdk-headless openjdk-17-jre openjdk-17-jre-headless openjdk-8-jre-headless Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log All upgrades installed
Re: UI improvements Was: process question.
Hi Marco, For things like this an issue in GitHub (I think we have labels for fuseki and/or UI) would work IMO. And I think what you suggest is a good idea! Some time ago we migrated to this JavaScript web application for Fuseki and a slightly new UI. Slightly as we intentionally didn't change much of the old behavior. That's so we could give it some time and make sure we didn't break any existing features (I think we didn't). Now I think it is a good time to start planning changes like this one, or even bigger ones (have a UI configuration, allow other languages, dark mode, improve the Query panel with tabs or other features, etc.). If you have a small feature like this one I think it is easy to discuss over GitHub. But for bigger things (e.g. replace YASGUI with another component, completely change how we manage datasets, security in UI, etc.) then I'd say discussions in the dev@ as Andy pointed are better as not everyone watches the GitHub issues. Cheers, Bruno On Wed, 29 Nov 2023 at 15:30, Marco Neumann wrote: > So for example we sometimes work with hundreds of files for uploads via the > fuseki UI. > > While it is great that the users get feedback about the progress of the > upload for each file, one has to scroll down to the last item to confirm > that the process is actually finished. > > It would be great to have an indication at the top of the upload page about > the status of the "upload all" process as finished, failed or failed with > completion etc. > > Marco > > > On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne wrote: > > > Github issues for feature-scale things. > > Ideally with associated pull request. > > > > General discussions, dev@ > > > > Andy > > > > On 29/11/2023 09:18, Marco Neumann wrote: > > > Bruno, > > > how do you gather input/ideas for UI improvements? > > > > > > Best, > > > Marco > > > > > -- > > > --- > Marco Neumann >
Re: UI improvements Was: process question.
So for example we sometimes work with hundreds of files for uploads via the fuseki UI. While it is great that the users get feedback about the progress of the upload for each file, one has to scroll down to the last item to confirm that the process is actually finished. It would be great to have an indication at the top of the upload page about the status of the "upload all" process as finished, failed or failed with completion etc. Marco On Wed, Nov 29, 2023 at 10:55 AM Andy Seaborne wrote: > Github issues for feature-scale things. > Ideally with associated pull request. > > General discussions, dev@ > > Andy > > On 29/11/2023 09:18, Marco Neumann wrote: > > Bruno, > > how do you gather input/ideas for UI improvements? > > > > Best, > > Marco > -- --- Marco Neumann
Re: UI improvements Was: process question.
Github issues for feature-scale things. Ideally with associated pull request. General discussions, dev@ Andy On 29/11/2023 09:18, Marco Neumann wrote: Bruno, how do you gather input/ideas for UI improvements? Best, Marco
UI improvements Was: process question.
Bruno, how do you gather input/ideas for UI improvements? Best, Marco On Thu, Nov 23, 2023 at 3:22 PM Bruno Kinoshita wrote: > I think it depends. Sometimes I approve things that look good to me, but > you might still want to request an extra review from Andy or Rob as they > know the code base a lot better. > > In the same manner, if you modify the UI and Rob, Andy, or anybody else > reviews it, I am always happy to be added as a second reviewer for > UI/JavaScript if needed. > > For the documentation in jena-site, though, pull requests are held back > until we have the code they talk about released, so that the documentation > is not ahead of what users are able to use. > > On Thu, 23 Nov 2023 at 13:16, Claude Warren wrote: > > > I haven't been around for awhile so I have a process question. > > How many reviews are required before code can be merged? > > > > Claude > > > > -- > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > -- --- Marco Neumann
Re: process question.
Claude, For merging to main, we are moving towards "rebase and merge" away from "Create a merge commit". Squashing and tidy up is probably better done on the PR before the integration into main. This is for keeping the long term history for main cleaner. It may make sense to use a merge commit when history should preserve new functionality coming in - e.g. something large and significant we'd want to record. Choose which you feel is appropriate but "rebase and merge" does produce more noise in the log history. Andy On 23/11/2023 15:22, Bruno Kinoshita wrote: I think it depends. Sometimes I approve things that look good to me, but you might still want to request an extra review from Andy or Rob as they know the code base a lot better. And this seems to be working. A review has two aspects - are there any wider issues? (e.g. it has a new dependency)- "process" has been followed - review the code. If a PR is ready, and only changes a clearly restricted area of code with no changes outside some subtree or small maven module, and passes the build - it doesn't bring everything down! - then consider merging it. In the jargon "RTC", with modest "CTR" if it hangs around too long. Always RTC would be ideal but we do have to be practical given the people-resources available. There are github actions to run the build on a cloned repo or "mavn clean verify" locally. Anyone - no just committers - can comment on PRs. CTR = "Commit Then Review" RTC = "Review Then Commit" In the same manner, if you modify the UI and Rob, Andy, or anybody else reviews it, I am always happy to be added as a second reviewer for UI/JavaScript if needed. For the documentation in jena-site, though, pull requests are held back until we have the code they talk about released, so that the documentation is not ahead of what users are able to use. On Thu, 23 Nov 2023 at 13:16, Claude Warren wrote: I haven't been around for awhile so I have a process question. How many reviews are required before code can be merged? Claude -- LinkedIn: http://www.linkedin.com/in/claudewarren
