Re: [DISCUSS] update centre and plugin portal for dev (master) builds

[Matthias Bläsing <mb...@doppel-helix.eu>]

Hi,

Am Samstag, den 30.05.2020, 14:32 +0100 schrieb Neil C Smith:
> 
> # Stage 1
> 
> Change the dev redirects in the .htaccess to -
> 
> Redirect 302 /nb/updates/dev/ https://netbeans-vm.apache.org/uc/dev/
> Redirect 302 /nb/plugins/dev/ 
> https://plugins.netbeans.apache.org/data/dev/
> 
> This will require setting up /dev endpoints for the UC on the VM and
> on the plugin portal.  Initially as symlinks for 12.0?

I agree, that this might be something to be managed in the plugin
portal. I would associate dev with the highest version in the plugin
portal. So we could add 12.1 to plugin portal now and that would be
dev. From a plugin authors perspective, 12.1 and dev would be the
"next" netbeans release.

I would not use an extra "dev" version, as that will most probably just
rot.

> # Stage 2
> 
> Once the above is working, we can remove a lot of the redirects and
> move everything up a level - then we have no need to update the
> .htaccess for each release -
> 
> Redirect 302 /nb/updates/ https://netbeans-vm.apache.org/uc/
> Redirect 302 /nb/plugins/ https://plugins.netbeans.apache.org/data/

I assume, that we'd retain the proxy for the 8.2 update center unless
oracle decommissions the old server?

> We could also just proxy those links from those places without
> redirect?  Might help with issue of being blocked when processing a
> lot of updates?

This I don't understand.

> # Stage 3
> 
> We can then make a decision on what update centre and plugin portal
> catalogues make sense for dev builds.
> 
> IMO, and the bit that really caused discussion, we adjust the latest
> master build on Jenkins to serve the NBMs and point at that (via the
> VM).  I think this is what happened before the Apache transition?
> 
> https://builds.apache.org/view/M-R/view/NetBeans/job/netbeans-TLP/job/netbeans/job/master/lastSuccessfulBuild/artifact/
> 
> Antonio raised concerns on the PR that infra might not appreciate
> that
> - obviously we don't have to do it, but considering we've been
> distributing beta builds direct from Jenkins, it's probably a very
> minor increase in bandwidth.  Would it actually be useful?

This might be something we could use the ousol mirrors for. These are
explicit mirrors, so bandwidth is either allocated to them or spare
bandwith is used.


> We could also consider a dev / next specific section on the plugin
> portal to allow plugin authors to test with master?  Or to try new
> plugin portal features?
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: [DISCUSS] update centre and plugin portal for dev (master) builds

[Neil C Smith <ne...@apache.org>]

On Wed, 17 Jun 2020, 21:21 Matthias Bläsing, <mb...@doppel-helix.eu>
wrote:

> I would not use an extra "dev" version, as that will most probably just
> rot.
>

Yes, dev as synonym for next for plugins (not updates) always pointing to
the next release would be great. Having /dev for plugins handled at the
plugin portal end simplifies the redirects.

I assume, that we'd retain the proxy for the 8.2 update center unless
> oracle decommissions the old server?
>

I guess. Removing it for 12.0 was -1'd. It's separate from the standard
templated UC and plugin links anyway.


> > We could also just proxy those links from those places without
> > redirect?  Might help with issue of being blocked when processing a
> > lot of updates?
>
> This I don't understand.
>

Sorry! If you try to use the Ant build support, say, for downloading the
platform (via nbms), you'll get blocked by ASF infrastructure before it
completes. This works fine if using the VM link or downloads.a.o directly.

Trying to install a whole cluster via IDE may also be problematic -
something to test.

This might be something we could use the ousol mirrors for. These are
> explicit mirrors, so bandwidth is either allocated to them or spare
> bandwith is used.
>

Maybe. The bandwidth usage will be minimal - probably more to mirror the
nightly build in the first place, given the catalog is almost the only
thing that will be downloaded. Is it worth the effort / complexity to
implement?

Best wishes,

Neil