On Wed, May 18, 2016 at 04:49:31PM -0400, Martin Owens wrote: My guess is the less text the better here. Or even icons or screen thumbnails? Thanks for working on making all of this more presentable to our users, it'll help a ton I bet. Bryce

On Thu, 2016-05-19 at 13:26 +0200, Sebastian Zartner wrote: Patch accepted! thanks :-)

On 19 May 2016 at 14:30, Brynn <brynn@...3133...> wrote: Note that this only applies to the 64-bit version. The 32-bit version provides an EXE version. Sebastian

On Wed, May 18, 2016 at 04:49:31PM -0400, Martin Owens wrote: 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

Am 26.05.2016 um 16:37 schrieb Martin Owens: - Everything but the instructions for OS X. We should take care to not accidentally delete those ;) As the page also contains some images, a simple text description won't do as a replacement. Maren