Hi, I am totally with you. We should automate the release-related tooling, the creation of the related notes as well as the download pages.
However, we should keep in mind, that we had some Antorra-based website rework. I do not remember the current status but I guess it is also .adoc based - so I guess, it would be no show stopper. Might also a good starting point for some contributors out where :-) Gruss Richard Am Mittwoch, den 24.03.2021, 15:14 -0700 schrieb David Blevins: > > On Mar 24, 2021, at 12:40 AM, Richard Zowalla <[email protected]> > > wrote: > > > > I have merged the "manual" changes to add the missing links to the > > .asc > > files of the release download page. > > > > In this process, I discovered, that we are not using the Downloads > > generator class [2] anymore. My questions is: > > > > Did we switch on purpose from Maven repository links (for the > > binaries) > > towards mirror links? (just want to catch up on this) > > We definitely should reinstate the automation, but we probably want > to redo the Downloads generator class. > > Someday, hopefully in the near future, we'll be some form of Jakarta > EE certified. When that happens we'll need to create a "public test > results page" for each release. It needs to contain the following > information[1]: > > - Product Name, Version and download URL > - Specification Name, Version and download URL > - TCK Version, digital SHA-256 fingerprint and download URL > - Java runtime used to run the implementation > - Summary of the information for the certification environment, > operating system, cloud, … > - List of tests passed (can be a link to another page, say the xml > output from running the TCK) > > I drafted those requirements that were eventually approved and > adopted. What was in my head is that smart implementations would > simply use their actual download page for these details. Our current > table format isn't that great in the first place (kind of noisy and > cluttered), so not really a good starting point for adding more. > > In the distant past we used to create a page for each release, even > including generated release notes from JIRA. > > - http://tomee.apache.org/tomee-1.0.0-beta-1.html > - http://tomee.apache.org/tomee-1.5.0.html > - http://tomee.apache.org/tomee-1.6.0.1.html > - http://tomee.apache.org/tomee-1.7.0.html > > - http://tomee.apache.org/tomee-1.5.0-release-notes.html > - http://tomee.apache.org/tomee-1.5.1-release-notes.html > - http://tomee.apache.org/tomee-1.7.0-release-notes.html > > The code that generated the release notes (and most the release tasks > even including vote threads) is here: > > - > http://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/java/org/apache/openejb/tools/release/cmd/ > > This just decayed over time. I'd be blissfully happy with a single > generated page for each release that contained just the download > links for now. In the future we can add certification information > below the download links. In the future future, we can add generated > release notes in list format below that. > > There's just so much automation we could be doing around releases, > especially now that we could potentially setup Jenkins to do the > work. We could have parameterized jobs to do nearly everything that > was going on in the `asf/tomee/sandbox/release-tools/` repo. > > Tasks like adding the new release to the mirror and removing the old > one could be automated. As could generating a release page and > pushing it to the website, while also updating the page for the just- > removed-from-the-mirror release to now point at archive.apache.org. > > At tomee.apache.org/download we could either point to the latest > release page and have no direct zip, tar links or have some sort of > short version of the download links. I'd probably be in favor of > just pointing so it's easier to maintain. > > On the release notes, what killed that is all the JIRA APIs changed > from RPC, to some xml format to now REST. The library I wrote in the > 2006-range (swizzle-jira) eventually got too outdated and stopped > working around 2012. There are now Atlassian maintained java clients > for JIRA as far as I understand, so we'd could potentially make > something new with that. > > Of course we can just fix the current Downloads.java for now, but if > you get inspired it'd be a thing of beauty to see the project become > what it once was :) > > That said, we have a brief window from now till end of April before > Jakarta EE 9.1 is scheduled to be released. I don't know if we can > get completely certified in that time, but we're down to 400-500 > failing tests on EE 9.1 and at least a hundred or two of them are > tied to changes we'd need to make in the TCK which are only possible > between now and end of April. After that we'd need to file TCK > challenges to have tests removed, but can't actually fix them. I'll > be doing what I can in the time I can get to push on that and help is > always welcome! > > So many things to do, so little time! :) > > > -David > > > [1] https://jakarta.ee/committees/specification/tckprocess/ -- Richard Zowalla, M.Sc. Research Associate, PhD Student | Medical Informatics Hochschule Heilbronn – University of Applied Sciences Max-Planck-Str. 39 D-74081 Heilbronn phone: +49 7131 504 6791 mail: [email protected] web: https://www.mi.hs-heilbronn.de/
smime.p7s
Description: S/MIME cryptographic signature
