On Wed, May 18, 2016 at 04:49:31PM -0400, Martin Owens wrote:
Dear developers,
I've released the next iteration of the website's "releases" app, this is the app that delivers each of our releases for different platforms.
The releases app is still going through it's draft phase, but I hope to have the download pages replaced in time for 0.92. To do that I need your help to review the pages. If you can help with css patches, that would be great too.
Currently available: https://inkscape.org/en/release/
Note: The releases will auto detect your os and give you the right download, but it's unconfigured on live and needs a bit of administrative help to get that all set up since the matching fields changed.
I'd also like to draw your attention to the new request to donate after download:
https://inkscape.org/en/release/0.91/windows/32-bit/%C2%A0(click on one of the downloads to start)
The text for these should be reviewed as well as the layout if you want to have a crack at the presentation.
Thanks everyone for helping make 0.92 easier to deliver to our users. :-)
Best Regards, Martin Owens
Hi Martin,
While it's fresh on my mind from the pre1 upload, I'd like to share some random thoughts from a package uploader perspective.
Anyway, in no particular order:
- Currently we have info about source package downloads both at inkscape.org/en/download/ and inkscape.org/en/download/source/, and they're inconsistent. I'm hoping with the new design these either go away or are simplified.
- As part of the source package release, I paste in the text from the NEWS file. But this looks horrid. I see the new system has the release notes much more nicely formatted. I hope that means I can dispense with the text pastings. But I'm curious for pre-releases if we'll just have one common release notes page they all point to, or if there would be snapshots of the release notes for each separate release. (I'm not actually sure which way would be better.)
- I would really, really, really, really like a command line way to upload releases and enter the package details. I'm pretty much setting the same values in the form each time, just incrementing the version number and uploading the new file + .sig. If I could script some of this, then it would enable me to significantly simplify the release process.
- It would be nice to have a sort of stable landing page for a release while we're doing pre-releases. In other words, we want a link to point people to before 0.92 is out, that will make it easy for them to grab the latest pre-release without needing to know what pre-release we're on. And it should also make it very clear that the packages are not final releases, and not considered stable. (From the design, I'm gathering that the page https://inkscape.org/en/release/0.92/ won't exist until 0.92.0 is actually out the door.)
- I like that the new design points out responsible people. Often we've had a named person acting as translation coordinator. There probably should also be a separate contact point for escalating release critical bugs. (And/or a link to the submit-a-bug page for reporting "ordinary" issues found while testing the pre-releases?)
It might be helpful if there was a definition of what the roles are responsible for. Like maybe, hover over the word 'Reviewer' to see what types of things the reviewer reviews.
- In the new design, the download buttons don't look very 'button-ish', nor do they look like traditional download links (e.g. a raw filename with file size and release date), so I'm a little concerned users might not realize these are where they download packages. That said, this looks a lot nicer than our current download links.
- I like how there are separate listings of "Other Revisions" vs. "Versions". Since Other Revisions includes the current page, perhaps it would be more correct to simply title it "Revisions"? Also, while year is a pertinent bit of info for Versions, it's not for Revisions. (I'm not sure what I'd replace it with though... date? number of release-critical bugs? test results stats? ...?)
- Historically we've provided source packages in several different compression formats, but going forward I'm going to provide just the bzip. I figure these days anyone that actually needs the source can be expected to handle bzip+tar.
- I'm really looking forward to seeing how the new system can simplify the amount of web editing needed per package upload. Not that it's terrible now, but the less web editing the less time releasing will take, and (hopefully) the faster we can cycle releases. I would love having a single place to enter all the data, and it get automatically propagated to all the various places that need updated.
- Pre-releases are important during the release process, but not so much afterwards. So the site does need to make space to show them and provide them for download, but once the release is out they could be hidden away to avoid confusion.
- During the release process, arguably the most pertinent piece of data is the list of release-critical bugs and their status. A link to the bug tracker (or even better - an import of the release critical bug list) would be extremely handy on the release page. Post-release this is less important (there are already 'Known Issues' and 'Notable Bug Fixes' sections in the release notes that cover bug details for that release.)
- From a release coordination perspective, I'd like a single place to look and see all the binary packages generated from a given source tarball. Basically I want a quick way to check on packaging status. Especially for the final release, timing of when packages are downloadable on the site is critical.
- Once we switch to git, one thing I plan to include for each release is a listing of commits for that release compared with the previous (i.e. `git shortlog $R1..$R2`) This could be tucked away a bit, since most people won't care much. It could be appended to the release notes but as it'll be longish, having it on a separate page or collapsed/hidden or something might be sensible.
- On the release page bottom right is 'In Development'. Are you planning on slotting in links to thinks like PPA and other snapshot builds here? That could be quite handy; our downloads pages currently devote a fair bit of text to snapshot builds.
Thanks again for the work on this, sorry for the verbosity of the above braindumping.
Bryce