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/ (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