Add content for how-to/download-new-upstream-version #27
Conversation
| determine the name and the lastest upstream version of the source package. | ||
|
|
||
| .. note:: | ||
| If the upstream project has a signing key it should be stored in the source |
There was a problem hiding this comment.
it should be stored in the source
It may be me but to a beginner's eyes, this is a bit ambiguous. Is there an action for the user in there or is this just a convention for the upstream project and we asking the user to look for the signing key. I definitely think a brief explanation for the signing key could help, like Sally pointed out.
|
dviererbe
force-pushed
the
add-how-to-download-new-upstream-version
branch
from
82ca387
to
cf37871
Compare
|
I just rebased this branch on the overhaul branch to get the commit (58d13fb), so that the |
Mostly the same content, just restructured/enhanced: - incorporated wording/structure feedback from Sally and Keirthana - added subheadings - demoted notes to paragraph - added :term:, :file: sphinx roles - replaced code-block with `.. code:: bash` syntax - added reference to get-package-source to uscan forced download Co-authored-by: Sally <sally.makin@canonical.com> Co-authored-by: Keirthana T S <keirthana.ts@canonical.com>
The manpage link for uscan doesn't seem to be working. When I go via the manpages, all of the links work except for mantic - there doesn't seem to be a mantic page for uscan, the page keeps timing out. |
Same for the links to git manpage. It may be better for us to configure the manpages link to make them version agnostic by doing: |
|
|
||
| uscan --verbose | ||
|
|
||
| Check for new :term:`Upstream` version (no download) |
There was a problem hiding this comment.
I'd suggest we move this to be the first sub-heading. Any user may want to check their version before downloading, so I think that would be a more logical ordering.
There was a problem hiding this comment.
You don't have to run uscan --safe to run uscan. The --safe flag basically disables downloading anything. Both are for 2 different use cases.
You would run uscan, e.g.:
- as the package maintainer to download and package the new release
You would run uscan --safe, e.g.:
- during a Main Inclusion Review just to check if the
debian/watchfile works - while fixing a bug just to make sure that there is no newer version that may have fixed the bug already
There was a problem hiding this comment.
@s-makin With that said; do you still think that the order should be moved?
There was a problem hiding this comment.
My impression is that checking the debian/watch file works or fixing a bug might be easier or at least more common steps that a packager would need to know before they become a package maintainer (although I could be wrong there!). If that's correct, then I'd move the uscan --safe section. Otherwise I'd leave it as-is - I'll bow to your greater knowledge on this one!
There was a problem hiding this comment.
Actually I don't know which use case is more common. I will ask around in Foundations
|
|
||
| There are special cases where they do not work for technical reasons. | ||
|
|
||
| .. note:: |
There was a problem hiding this comment.
This note appears twice - is that intentional?
There was a problem hiding this comment.
Yes, this was intentional for readers that read the article only partially. I also don't think that it is elegant.
Do you have a more elegant solution?
There was a problem hiding this comment.
Hmmm...What if the header was something like "Downloading upstream versions", with the note contents underneath that heading, and then the two current headings become subheadings beneath that? I'm not sure that the note would make so much sense then, but at least it would remove the duplication. Might need an additional sentence or two to introduce the difference? (sadly, that's the best I have!)
Co-authored-by: Sally <sally.makin@canonical.com>
Co-authored-by: Sally <sally.makin@canonical.com>
That is weird, because the links work for me. I get redirected from How would |
The caution box in the article how-to/download-new-upstream-version that
instructs the user to avoid downloading Upstream Files manually gets
converted into its own section ("Best practices").
This pull requests adds the article for how to download a new upstream version.
Is related to #19
@s-makin and @keirthana you should be able to commit to this branch and merge it; feel free to make changes :)