Request for classic confinement for gradle

store-requests
21

Hi,

It’s been more than 2 weeks. I cannot progress without classic confinement. Can someone please review this request?

22

I have reached out to the upstream to see if they are okay with this. If this is in coordination with gradle, if you can point us to the person upstream, this can speed things up. Thanks.

23

Hi @Igor,

I’ve already contacted with upstream developers in a github issue: https://github.com/gradle/gradle/issues/13615

I’m granted “gradle” name in the Snap Store as my purpose was to join snapcrafters and help upstream developers to adopt snap packages. As part of this effort, I created this github issue and asked their opinion.

As far as I understood they were approached previously but couldn’t get much traction. The developer whom I talked with proposed an idea of creating a repo which contains automated builds of snaps, flatpaks etc.

I volunteered to create a running package to demonstrate and am planning to contribute this work into the repo he mentioned.

24

Hi @Igor,

Are there any updates? Can we proceed?

25

I’ve not received any update. I’ll chase them.

26

Did you get the chance to see the thread I shared in my previous post?

27

Hi @Igor,

Another week has passed. Are there any updates? Can we proceed?

28

Hi @tunix, I’ve not forgotten you. So, as our process currently works, we need upstream to approve this, as classic confinement has security implications. This isn’t specific to your request in any way, just the process. Please bear with me, I’ll try to sort this as quickly as possible. I’ll have a discussion with the security team to see what’s the best way we can handle this provided we can’t get an official reply from gradle.

1 Like
29

OK, thank you for the detailed response.

I’ve a question though. Is it possible for people outside Canonical to join to snapcrafters team? Does that have an impact on this process (in terms of reliability of snap author)?

I’m willing to package more packages I find useful and I’ll always try to contribute to upstream first. I know I should always create a new thread for classic confinement but I wonder whether the process will take as long as this one?

30

Hey there. So we did some thinking on the best way forward. What would you say about: you transfer gradle to snapcrafters, and then submit PRs against the repo. We can then publish the snap as classic, and you will be able to continue contributing (asbefore)?

1 Like
31

I want to be part of snapcrafters team. This would be a good start. I’d be more than happy to transfer the ownership. Do you need an action on my part?

33

I can import the repo to the snapcrafters account on github, and @roadmr (or someone else) can action the transfer of the snap in the store. Is https://github.com/tunix/gradle-snap the repo I should import? If so, I’ll do it today.

1 Like
34

Yes, the repo is correct. Thank you!

35

It’s imported to https://github.com/snapcrafters/gradle now - once the transfer is done, I’ll tell the build bots to start the build and publish.

1 Like
36

I’ve transferred gradle to snapcrafters.

  • Daniel
2 Likes
37

Thanks @roadmr

@alexmurray the snap has been transferred to snapcrafters successfully, so now we’re just waiting on the classic store approval. Thank you!

38

@popey thanks, this is now live! - note the Contact info still lists mailto:me@alperkan.at so perhaps that should be updated to snapcrafters or similar?

39

Hi everyone! I’m glad it’s published on the store now. Now that it’s up in the store, I’d like to ask some questions:

  • How will the updates go through from now on? (let’s say 6.6.2 or 6.7.0 is published?)
  • Who will manage channels and according to what?

I believe I can now send patches to snapcrafters github repo and send updates which may be the answer to my first question. How about the 2nd one?

40

I think the simple answer is “it depends”. If it’s needed that there are 6.6.x and 6.7.x tracks, then we can request them here. But it depends on whether that’s required, or the snap should just contain whatever the latest upstream stable release is. To maintain multiple tracks is more work, obviously. I’d also move the repo to launchpad if that was desired. Launchpad gives us more flexibility in choosing which track to build, having multiple repos in parallel to build each track.

41

Hi @popey,

I didn’t mean to create new tracks. Gradle considers 6.6.1 as the latest stable version. As this is a new snap, one can expect 6.6.1 to be in edge channel (maybe?). I think the snap is mature enough and we can actually move edge into stable channel.

Is this possible to manage through github PR’s? Or is this also something we need to discuss here?