Revise content around downloads

[codefromthecrypt]

Our website hasn't been updated in a notable way content wise since ASF. We should do that.

Here's some advice from @nacx

• A download page in addition to the quickstart one with links to the official Apache release (which are the source archives) as the first option. To quote an example from LEGAL-270, All official Apache releases are in source form; Docker images can be built from our official source releases, but are derived distributions analogous to, say, Debian packages. So when we say official releases, we refer to the source archives the PMC votes upon.

That's it. The main project website should have pointers to the official Apache source releases. Currently it only has the Quickstart guide and newcomers coming to Zipkin reading the website to learn about the project will just see the Docker image, the built jar, and a link to Github (that host the source archives for the tag, wihch is not exactly the same as the ASF source release as voted and published to the ASF repos).

[nacx]

Take this into account when creating the download page:

• http://www.apache.org/legal/release-policy.html#publication
• https://www.apache.org/dev/release-distribution.html#download-links
• https://www.apache.org/dev/release-distribution.html#maven this one is also relevant to how current release announce emails are currently written.

[codefromthecrypt]

this changes the script to intentionally not use apache maven repo #13

[codefromthecrypt]

A rough look and I notice a huge variety in satisfying the download page rule.

For example, ZK only mentions their combined source+binary release from apache sites and doesn't mention anything else https://zookeeper.apache.org/releases.html This probably works as they are a monorepo project

Dubbo is a non-monorepo project and they break down their download page based for some of their repos https://dubbo.incubator.apache.org/en-us/blog/download.html Similarly, they do not mention maven at all. In this case they do not mention all of their projects. For example, they have several repos which have never had an ASF release, yet this seems to be non-blocker for graduation (news to me)

My 2p is that we so the least efforts required here. ZooKeeper's approach is maintenance free in so far as it doesn't imply duplicating information like version numbers. I think if we combine this with a caveated quick start which mentions this uses maven central and blah .. we could be good.

[codefromthecrypt]

chatting with @michaelsembwever I'm really uncertain the value of distracting folks with every minor repo on the main website. For example, https://github.com/apache/incubator-zipkin-layout-factory is not going to bring value to end users advertising.

I think the ASF rules were written in days of monorepos and it is really almost all apache projects are monorepos. Zipkin is the largest project in terms of repo count to ever go through incubation.. at least pages of scrolling tells me this..

I would strongly prefer if we can simply document the source of the main zipkin codebase and leave it at that. This means that in subordinate repositories people can refer to README which all list where the sources are.

[shakuzen]

I would strongly prefer if we can simply document the source of the main zipkin codebase and leave it at that. This means that in subordinate repositories people can refer to README which all list where the sources are.

This seems reasonable to me and what users would generally expect.

[dave2wave]

You may be correct that Zipkin has a large number of repositories. OpenWhisk has 51 repositories and 20 different releases. NetBeans had 676 different release artifacts.

If you wish to graduate from the Incubator you need to comply with policy and point to all of your current releases. You can certainly highlight what is most important to users first and reference the others.

This page http://zipkin.apache.org/pages/community.html needs to reflect the Apache Zipkin podling. Have you considered naming this Apache OpenZipkin

[codefromthecrypt]

totally right about OpenWhisk having more repositories. I missed that. Hopefully, they have a lot more people working on ASF related stuff. Seems they might, but good luck to them anyway!

We don't yet have an issue on this you mentioned.. I will post it

• Podling Suitable Name Search: https://incubator.apache.org/guides/names.html#conducting_a_suitable_name_search

To your question, we have no plans to double-brand zipkin with Apache and Open..

[codefromthecrypt]

aside to this topic, but added note about podling search to the main graduation issue also openzipkin/zipkin#2544

[codefromthecrypt]

for those curious, netbeans has only one download on their page, so not particularly relevant to this topic apart from workload comparisons..

OpenWhisk otoh is very relevant.. they have a categorized website to help steer people through it. https://openwhisk.apache.org/downloads.html

The below is about the legal feasibility about borrowing the code if it helps (both sites are jekyll)..

The website is mostly IBM staff, and includes an IBM-specific copyright note in their license. The ASF downloads page is also written by IBM, but it was contributed after incubation. This makes sense as this is an ASF requirement and not relevant pre-ASF.

If we borrowed code contributed after ASF, written by a vendor in a project with the same vendor in copyright notices.. would we require adding "Copyright 2015-2017 IBM Corporation" to our LICENSE file? ITOW is the LICENSE addendum forever, or only up to the dates mentioned about the vendor.

[codefromthecrypt]

Regardless, of implementation, let's go with what @dave2wave mentions and prioritize the download page in order of relevance, noting all the downloads. We've spent more time discussing this than probably desired, and probably adding internal downloads won't make the page much worse.

[codefromthecrypt]

there were some various things busted in our website, so I fixed them today. I will work on the downloads page tomorrow.

[codefromthecrypt]

very popular issue! I guess this is the most important issue in all of zipkin. We got yet another email about this, this time from craig, eventhough we noted this many times.

I will still do this today since clearly no one else will

Please note that this announcement does not meet requirements for release announcements.

For the next release, please create a downloads page for the release artifacts that includes https links to the mirror download site, the checksums and signatures. The download page also needs an https link to the KEYS file and instructions how to verify the release.

You might consider having a single download page that contains information about all of the components that you release separately.

http://www.apache.org/legal/release-policy.html#release-announcements

[codefromthecrypt]

done hopefully #17