On Tue, Jun 01, 2021 at 01:03:11PM +0200, Steffen Möller wrote:
The biggest tasks would be to package the SDK of AWS [0] (which would also
benefit igv) and of Microsoft Azure [1]. We would also need to package
Apache Ignite [2].
After the freeze I shall discuss this on the ML of the Debian Java team. I
cannot really figure out how hard packaging those whole SDK would be. I also
have a poor idea of the maintenance burden over time.
[0] https://github.com/aws/aws-sdk-java
[1] https://github.com/Azure/azure-sdk-for-java
[2] https://github.com/apache/ignite/
These sound a bit scary for a single person (just guessing from the
names that it might be huge) but in the end it will probably be used by
lots of other software which in turn might mean that there are more
people who might join the effort to package these.
Yip. Both for packaging and for maintenance. I CCed our cloud team which
may have some extra opinion/direction for us.
I don't think a lot of the cloud team members have much experience
packaging Java stuff. However, we are involved in packaging tools and
SDKs published by various cloud vendors in other languages. In my
experience maintaining and working with maintenance of the AWS Python
and Go SDKs, here are the issues you'll likely need to contend with:
1. Bundled dependencies
2. Fast upstream release cadence
#1 applies to a lot of code published by a number of cloud services.
Rather than cope with different versions of their dependencies shipped
with the various operating systems they target, the upstream maintainers
of many of these projects find it easier to embed copies of their build
dependencies. Per Debian policies, packages cannot use these policies
and must instead rely on packaged versions of these dependencies. So in
that case, you may need to do some amount of work to avoid using these
bundled dependencies, possibly including packaging the dependencies
themselves for Debian. Fortunately, as far as I can tell, neither the
AWS SDK for Java nor the Azure SDK for Java seem to bundle their
dependencies.
For #2, cloud services release new features at a very high rate, and
consequently publish new SDK releases often. If you look at the AWS SDK
for Java, for example, you'll see multiple tagged releases *per week*:
https://github.com/aws/aws-sdk-java/tags
Fortunately, the vast majority of these releases contain only
machine-generated code changes based on API definitions (e.g.
Swagger/OpenAPI), and backward compatibility is maintained.
Additionally, the upstreams are generally good about sticking to
Semantic Versioning, so any breaking change will be reflected in the
version numbers. With this in mind, once you have packaging
configuration in place, you should be able to (nearly) fully automate
the packaging of new releases.
As I said, I don't think we in the cloud team have any meaningful
experience with Java, so I don't think we can be much help with the
actual packaging work. I'm sure others on the team can correct me if
I'm wrong about that. But I think we can help with guidance, reviews,
etc, if that's useful.