Re: [Inkscape-devel] inkscape-0.92.3pre0 source tarball now available
On Sun, 2018-03-04 at 11:32 -0800, Bryce Harrington wrote:
Yes, still upload the end-user downloadable content to the website. We have mirroring and caching set up there.
Feel free to also copy the source tarball to the website.
A bit unfair to ask Eduard to do this, if the website isn't letting you deploy files easily, then that's a tooling issue we can fix.
But I can't fix it if the social protocol is to not ask for help and instead figure out a technical workaround.
Regards, Martin, Website guy who can help
Am 05.03.2018 um 05:56 schrieb Martin Owens:
On Sun, 2018-03-04 at 11:32 -0800, Bryce Harrington wrote:
Yes, still upload the end-user downloadable content to the website. We have mirroring and caching set up there.
Feel free to also copy the source tarball to the website.
A bit unfair to ask Eduard to do this, if the website isn't letting you deploy files easily, then that's a tooling issue we can fix.
But I can't fix it if the social protocol is to not ask for help and instead figure out a technical workaround.
Regards, Martin, Website guy who can help
I uploaded the files to the gallery and created the release: https://inkscape.org/en/release/0.92.3pre0/
@Martin: What did you have in mind? The most time consuming part for me is always filling out all the fields for each upload (unfortunately we have a lot on Windows) - not sure if/how could automate that, though...
Regards, Eduard
Am 05.03.2018 um 11:47 schrieb Eduard Braun:
Am 05.03.2018 um 05:56 schrieb Martin Owens:
On Sun, 2018-03-04 at 11:32 -0800, Bryce Harrington wrote:
Yes, still upload the end-user downloadable content to the website. We have mirroring and caching set up there.
Feel free to also copy the source tarball to the website.
A bit unfair to ask Eduard to do this, if the website isn't letting you deploy files easily, then that's a tooling issue we can fix.
But I can't fix it if the social protocol is to not ask for help and instead figure out a technical workaround.
Regards, Martin, Website guy who can help
I uploaded the files to the gallery and created the release: https://inkscape.org/en/release/0.92.3pre0/
- Thanks :) I just added a picture, and a link to the release notes draft.
Maren
@Martin: What did you have in mind? The most time consuming part for me is always filling out all the fields for each upload (unfortunately we have a lot on Windows) - not sure if/how could automate that, though...
Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
I just added a picture, and a link to the release notes draft.
Great!
I noticed you removed the "codename" which I think we need for hiding pre-releases (or is there any other field to mark a release as pre-release which I overlooked?): https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L150 (that is unless you specifically wanted to make the pre-release more visible)
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard
Am 05.03.2018 um 17:56 schrieb Eduard Braun:
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
I just added a picture, and a link to the release notes draft.
Great!
I noticed you removed the "codename" which I think we need for hiding pre-releases (or is there any other field to mark a release as pre-release which I overlooked?): https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L150 (that is unless you specifically wanted to make the pre-release more visible)
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
- I tested after I changed it, and it didn't show up as primary download for me (but it did change, so I assumed it had worked). I found that duplicated name ugly...
According to the source code, what makes a pre-release a pre-release is not the 'pre' in its name, but that its parent (the release, in this case 0.92.3) does not have a date set, or the date is set after the pre-release's date.
(https://gitlab.com/inkscape/inkscape-web/blob/master/releases/models.py#L132)
So the code name doesn't make a difference, we should be able to safely remove it again. May I try?
Maren
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard
Am 05.03.2018 um 21:59 schrieb Maren Hachmann:
Am 05.03.2018 um 17:56 schrieb Eduard Braun:
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
I just added a picture, and a link to the release notes draft.
Great!
I noticed you removed the "codename" which I think we need for hiding pre-releases (or is there any other field to mark a release as pre-release which I overlooked?): https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L150 (that is unless you specifically wanted to make the pre-release more visible)
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
- I tested after I changed it, and it didn't show up as primary download
for me (but it did change, so I assumed it had worked). I found that duplicated name ugly...
According to the source code, what makes a pre-release a pre-release is not the 'pre' in its name, but that its parent (the release, in this case 0.92.3) does not have a date set, or the date is set after the pre-release's date.
- Mhm. Tried this (setting 0.92.3 without date as parent) but it doesn't appear in the list of parents to select from, after I created it. So, yeah... I think I once opened an issue about the number of ancestors a release can/cannot have on the website, which is maxed out by our point point releases.
Maren
(https://gitlab.com/inkscape/inkscape-web/blob/master/releases/models.py#L132)
So the code name doesn't make a difference, we should be able to safely remove it again. May I try?
Maren
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Am 05.03.2018 um 21:59 schrieb Maren Hachmann:
Am 05.03.2018 um 17:56 schrieb Eduard Braun:
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
I just added a picture, and a link to the release notes draft.
Great!
I noticed you removed the "codename" which I think we need for hiding pre-releases (or is there any other field to mark a release as pre-release which I overlooked?): https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L150 (that is unless you specifically wanted to make the pre-release more visible)
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
- I tested after I changed it, and it didn't show up as primary download
for me (but it did change, so I assumed it had worked). I found that duplicated name ugly...
That's why I suggested to drop the codename field below... a single Version field should suffice IMO (as you note they are set to the same anyway if set at all).
According to the source code, what makes a pre-release a pre-release is not the 'pre' in its name, but that its parent (the release, in this case 0.92.3) does not have a date set, or the date is set after the pre-release's date.
(https://gitlab.com/inkscape/inkscape-web/blob/master/releases/models.py#L132)
If I'm not missing something this function is not used anywhere.
So the code name doesn't make a difference, we should be able to safely remove it again. May I try?
The codename *does* matter. I think the following code decides what the "latest release" is: https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L56
Now I also get 0.92.2 again when visiting https://inkscape.org/en/release/
Maren
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard
Am 05.03.2018 um 22:23 schrieb Eduard Braun:
Am 05.03.2018 um 21:59 schrieb Maren Hachmann:
Am 05.03.2018 um 17:56 schrieb Eduard Braun:
Am 05.03.2018 um 13:31 schrieb Maren Hachmann:
However I'm not sure it works as I think it should as https://inkscape.org/en/release/ still points to the pre-release (which I assume it should not?). Maybe a caching issue?
- I tested after I changed it, and it didn't show up as primary download
for me (but it did change, so I assumed it had worked). I found that duplicated name ugly...
That's why I suggested to drop the codename field below... a single Version field should suffice IMO (as you note they are set to the same anyway if set at all).
According to the source code, what makes a pre-release a pre-release is not the 'pre' in its name, but that its parent (the release, in this case 0.92.3) does not have a date set, or the date is set after the pre-release's date.
(https://gitlab.com/inkscape/inkscape-web/blob/master/releases/models.py#L132)
If I'm not missing something this function is not used anywhere.
So the code name doesn't make a difference, we should be able to safely remove it again. May I try?
The codename *does* matter. I think the following code decides what the "latest release" is: https://gitlab.com/inkscape/inkscape-web/blob/master/releases/views.py#L56
- Yes, you're right. Confusing... @doctormo, can one of these two options that make a pre-release a pre-release be removed, then?
Maren
Now I also get 0.92.2 again when visiting https://inkscape.org/en/release/
Maren
As Inkscape does not use codenames for releases, maybe we can drop the codename field altogether?
Regards, Eduard
On Mon, 2018-03-05 at 22:37 +0100, Maren Hachmann wrote:
- Yes, you're right. Confusing... @doctormo, can one of these two
options that make a pre-release a pre-release be removed, then?
I agree it is confusing. Looking into it, the 'pre' check was put in because of pre point releases specifically. Because 0.92 release came before 0.92.3pre0 date-wise.
I will correct the code with a field specifically for is_prerelease and hopefully and clean up the items that check for pre.
Martin,
On Mon, 2018-03-05 at 11:47 +0100, Eduard Braun wrote:
Am 05.03.2018 um 05:56 schrieb Martin Owens:
On Sun, 2018-03-04 at 11:32 -0800, Bryce Harrington wrote:
Yes, still upload the end-user downloadable content to the website. We have mirroring and caching set up there.
Feel free to also copy the source tarball to the website.
A bit unfair to ask Eduard to do this, if the website isn't letting you deploy files easily, then that's a tooling issue we can fix.
But I can't fix it if the social protocol is to not ask for help and instead figure out a technical workaround.
Regards, Martin, Website guy who can help
I uploaded the files to the gallery and created the release: https://inkscape.org/en/release/0.92.3pre0/
@Martin: What did you have in mind? The most time consuming part for me is always filling out all the fields for each upload (unfortunately we have a lot on Windows) - not sure if/how could automate that, though...
Well there's two portions, the upload part and the releases part. Uploads could be done via scp for bryce, he has ssh access to the webserver. But for others, a token upload would be useful if we want to automate it.
The release is trickier because there's fields to fill in, although maybe a way to make a release will fill in fields? Let me know.
Best Regards, Martin Owens
Am 05.03.2018 um 14:49 schrieb Martin Owens:
Well there's two portions, the upload part and the releases part. Uploads could be done via scp for bryce, he has ssh access to the webserver. But for others, a token upload would be useful if we want to automate it.
Maybe we could make the webserver pull releases from a fixed location (may it be alpha.inkscape.org or something else)? As far as I understood Bryce giving the release team SSH/SCP access to a directory on alpha.inkscape.org would be a possibility - if the same works for the website server itself it might be even easier.
Either way I support Bryce's earlier statement, that having a fixed location with fixed file names (i.e. no slugs/ids like for website gallery items) that can be updated if need be would be preferential for certain applications (i.e. at the very least for packagers who need to maintain build recipes pulling in the latest source tarball). Probably not so important much for other (binary) releases, though.
The release is trickier because there's fields to fill in, although maybe a way to make a release will fill in fields? Let me know.
Maybe we can (in the above scenario) construct the information from uploaded filenames?
E.g. for a file called "inkscape-0.92.3pre0.tar.bz2" we immediately know it's version 0.92.3pre0 and it's a source tarball. For binary release we could come up with names like "inkscape-0.92.3pre0-win-x86.exe" telling us it's a release for Windows, i686 architecture, exe installer format. Other metadata (license / authors) should be the same for all Inkscape packages. Checksums/signatures could be pulled in from *.md5/*.sig files of the same name, e.g. inkscape-0.92.3pre0-win-x86.exe.md5.
If it's not straightforward to implement that's OK, though... releases don't happen every day, so at least personally I always felt I could invest the few additional minutes.
Am 05.03.2018 um 18:51 schrieb Bryce Harrington:
Perhaps instead, what I could do is along with the file itself, also scp up a YAML descriptive file with metadata. Then the toolage to produce it is entirely on my end, and how it gets digested for display can be dealt with as convenient.
While this sounds absolutely doable I'm not sure if it's not an overly complicated solution? The time every packager needs to invest to construct and update that .yml file properly might be more hassle than it's worth...
Regards, Eduard
On Mon, 2018-03-05 at 19:21 +0100, Eduard Braun wrote:
Maybe we can (in the above scenario) construct the information from uploaded filenames?
E.g. for a file called "inkscape-0.92.3pre0.tar.bz2" we immediately know it's version 0.92.3pre0 and it's a source tarball. For binary release we could come up with names like "inkscape-0.92.3pre0-win-x86.exe" telling us it's a release for Windows, i686 architecture, exe installer format. Other metadata (license / authors) should be the same for all Inkscape packages. Checksums/signatures could be pulled in from *.md5/*.sig files of the same name, e.g. inkscape-0.92.3pre0-win-x86.exe.md5.
If it's not straightforward to implement that's OK, though... releases don't happen every day, so at least personally I always felt I could invest the few additional minutes.
This is perhaps the most interesting and useful way to get skeleton entires up that I've heard. It fits quite well.
I'll ponder how to do it right.
The thing about stable filenames is just a django thing, it wants uploaded files to be 'sacrid' so you don't accidentally stamp over someone elses file. but it has their weird bug where you upload the same file again to exactly the same object and it just makes a new file. Inconvient.
Martin,
On Mon, Mar 05, 2018 at 11:47:33AM +0100, Eduard Braun wrote:
Am 05.03.2018 um 05:56 schrieb Martin Owens:
On Sun, 2018-03-04 at 11:32 -0800, Bryce Harrington wrote:
Yes, still upload the end-user downloadable content to the website. We have mirroring and caching set up there.
Feel free to also copy the source tarball to the website.
A bit unfair to ask Eduard to do this, if the website isn't letting you deploy files easily, then that's a tooling issue we can fix.
But I can't fix it if the social protocol is to not ask for help and instead figure out a technical workaround.
Regards, Martin, Website guy who can help
I uploaded the files to the gallery and created the release: https://inkscape.org/en/release/0.92.3pre0/
@Martin: What did you have in mind? The most time consuming part for me is always filling out all the fields for each upload (unfortunately we have a lot on Windows) - not sure if/how could automate that, though...
Regards, Eduard
Yeah same for me. What I really need, as I think I've mentioned in the past, is a commandline tool that can be automated.
Perhaps instead, what I could do is along with the file itself, also scp up a YAML descriptive file with metadata. Then the toolage to produce it is entirely on my end, and how it gets digested for display can be dealt with as convenient.
Bryce
participants (4)
-
Bryce Harrington -
Eduard Braun -
Maren Hachmann -
Martin Owens