Classic confinement request: netbeans-dev


#1

Dear Snapcraft,

The netbeans-dev package is actually the Apache NetBeans IDE built on Apache Infrastructure from Apache NetBeans master branch (right now the branch of the upcoming PR source).
It is created as a separate Snap package as Apache requires not to promote unreleased development code, so right now it is private, but probably can be public but not listed in the store (nice new feature BTW).

So as netbeans package, this one needs to be classic as well.

Thank you!


#2

I was prepared to grant this request since you were granted classic access for ‘netbeans’, but I’m a bit concerned by this statement: “It is created as a separate Snap package as Apache requires not to promote unreleased development code, so right now it is private, but probably can be public but not listed in the store (nice new feature BTW).”

Since part of classic vetting is pursuing upstream involvement, this seems counter to that. I’m going to ask the @advocacy to step in and perform the vetting.


#3

Dear @jdstrand,

I might be not clear on the meaning “pursuing upstream involvement”.

Our plan is have an easy install-able version of our latest codebase in form of a weekly build. Snap is really ideal for that with the built-in auto update feature.
Initially we thought that using a different track like “edge” would work. Unfortunately/fortunately Apache requires that non-released versions shall not be pushed to the public and clearly state that they are for development/testing purpose only. So I was guided to create a different package which would be private and I could invite community members to access that package.

Since then the “hidden in store” publication level was introduced, and that actually would fulfill the Apache need and also do not require some signup from our community members we thought to give it a go for this.

So this package would be actively maintained, updated by the Apache NetBeans community, though we consider to have a much smaller user base.


#4

Thank you for your clarifying remarks. I’m not familiar with this model for using private builds to distribute widely to opt in developers and would like others to comment.

Ping @advocacy - can you comment?


#5

Some additional info:
Well, I’ve made the package hidden. That’s what our intentions are. The package is not private at all, it is being built and published from the Apache infrastructure build job: https://builds.apache.org/job/netbeans-snap-weekly-master/,
The PR which is required for this build hit the master branch: https://github.com/apache/netbeans/pull/1225
So the job is tracking our main development branch, master from now.


#6

@advocacy - ping again,can you weigh in on this topic?


#7

This seems a reasonable request to me. One of the selling points of private snaps is to enable a small team of people with correct expectations to install early-access builds of software for testing / QA. We’ve certainly seen other software developers do this either with tracks or separate snaps. They’re mostly (AFAIAA) public though because they don’t have the somewhat onerous requirements the Apache Foundation specify.

While strange, I think this is a great use of the private feature, so long as ultimately, it results in delivering a public package at some point.

Note though that if you add people as collaborators, you are allowing them to manage your snap, not just install it, but upload to it too. That could be a blocker for you, depending on who the people testing are. You wouldn’t want internet rando’s having publish rights to your code, I would imagine.


#8

@popey We actually have a public package for Apache NetBeans which is public and gained some space in our Linux distribution.

Also having the hidden feature the netbeans-dev package can be public as well, the only Apache requirement is make non-released, development builds, to be pushed in the “background”. Having separate package instead of track actually helps to run the development and the release version next to each other which is really useful in testing.

So @jdstrand, @advocacy can we have a green light on this?


#9

The publisher was previously vetted for netbeans and the requirements are understood. Granting use of classic. This is now live.