While it's fresh on my mind from the pre1 upload, I'd like to share some random thoughts from a package uploader perspective.
Thanks Bryce, I'll try and answer everything...
- 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.
Everything under /download/ is scheduled for demolition, planning applications have been available in your local office in Alpha Centuri.
- 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.)
We turned them into html fields so release managers could take control of the formatting. Although parsing it through a text to html parser in a release script would be cool too.
- 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.
Really? ;-)
The process of having oauth bunch a hole in the security for scripting is a bit of work (that and jsonic/REST apis on top) but perhaps there's something we can do for admins since it's a very important part of our workflow. I'm going to add this to my todo list.
- 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://ihttps://inkscape.org/en/release/0. 92/nkscape.org/en/release/0.92/ won't exist until 0.92.0 is actually out the door.)
It exists now.
The process for a new release works like this:
* Create a release for 0.92, DO NOT SET THE RELEASE DATE * Create a release for 0.92pre0, set the parent to 0.92 and set the release date.
This means 0.92 appears in the 'Development' list and not in the releases list. I've just pushed a fix to a bug that would redirect users to a 0.92pre0 instead of 0.91 until the parent is released.
So you can think of the release as a release series and a set of sub- releases under it. The release-date field is the control for if the release is 'released' or not.
See the page here: https://inkscape.org/en/release/0.92/%C2%A0(same url you posted about)
- 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?)
Added to my todo list.
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.
Added to my todo list.
- 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? ...?)
Added to my todo.
- 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 agree with this.
- 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.
Added to my todo list.
- 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.)
This is a very interesting idea for bug information. I've added it to my list for investigation.
- 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.
Added to my todo list.
- 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.
Is this an extra field? What type of field makes it the most useful, or set of fields?
- 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.
As above, the trunk version listed there shows are 'in development' version and could have a ppa platform added to link it in. The 0.92 also appears there now I've added it, so adding all the pre-release tarballs and etc should be easy enough.
Thanks again for the work on this, sorry for the verbosity of the above
Thanks for the brain dump bryce. This is very handy since you're actually doing the release and I'm just guessing at the needed functionality until this email :-D
Best Regards, Martin Owens