On Wed, May 18, 2016 at 04:49:31PM -0400, Martin Owens wrote:
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.
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
I'd also like to draw your attention to the new request to donate after
(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
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
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
- 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/
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
- 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