Tue, Jul 14
Mon, Jul 13
Jul 4 2020
Jul 2 2020
This is an important feature: it has been dormant for a while, but we need to actually start implementing it.
Jul 1 2020
Jun 26 2020
This is now published in CTAN (biblatex-software)
Jun 25 2020
I cannot reproduce this anymore either!
Closing this for now.
May be related to T2406
This seems to be related to T2465 too
Filtering is broken in the admin interface for deposits.
Jun 24 2020
Jun 23 2020
- if you still have that tarball at hand, then it can be ingested in SWH, and we keep the correspondence between SWHID and SHA256; in principle, you need to trust us, but one can foresee having external parties checking that the correspondence is real while the tarball is still there, and adding their observation to the chain of trust means you need to trust us less and less
By we keep the correspondence between SWHID and SHA256 you mean you on the SWH side?
@rdicosmo The discussion of the "source of trust" is an important one, and it's interesting to see how we can address it going forward.
The proposal of a correspondence table, as I wrote on swh-devel, leaves open the question of today's and yesterday's software, assuming SWHIDs become the de facto standard tomorrow. How can I check the integrity of code fetched from SWH if all I have is its tarball's SHA256 from its release announcement? How can I check its authenticity if all I have is an OpenPGP signature computed over a tarball?
Jun 22 2020
Jun 18 2020
Clean and elegant, LGTM
Jun 17 2020
The impression I get from playing with the interface is that at some moment the browser decides to "wrap" some of the components of the page in the source code view, that leads to the unwanted behaviour.
When we'll come to this, it might be interesting to compare with the behaviour of similar web front ends (GitHub, BitBucket, GitLab) that seem to handle this corner case seamlessly.
Better. but not yet there... if you play with Ctrl+ Ctrl- a bit you'll see that the source code pane still ends up having a size controlled by the central part of the top bar that show the path
Jun 16 2020
Mailchimp is closed source (*sigh*) but is well accepted and has interesting features, so we'll not move away unless there are strong reasons.
Ack for the PDF way, as it seems the HTML one is too fragile/cumbersome.
For the record, the same kind of rendering is obtained when browsing Github and playing with the browser zoom.
After some other tests, it seems this mostly happens with Chrome: you can trigger the behaviour by playing with Ctrl + and Ctrl -
Firefox seems much more resilient.
To reproduce, enlarge the browser window: if the browser width is small enough, the source code pane wraps below and uses all the available space.
In my case, I'm using a full screen on a 2560 pixel display
Fortunately, this is already the case.
I can not reproduce locally. I think this is due to your browser cache.
Is refreshing the page with Ctrl+F5 fixes the display ?
Jun 15 2020
A bare bone process may be something like this:
- every time a newsletter is sent Marla does the following
- get the HTML of the newsletter from Mailchimp
- use it to create a new page on the SWH website
- add a link to this new page at the bottom of the newsletter page on SWH (in all three languages)
This way the subscription page is also the archive page and may attract more traffic.
Any comments/improvements on this?
This sounds quite complicated and cumbersome to do ... We need a process that requires less copy / paste operations.
Possible solutions are:
- We create the newsletter for each supported languages and send it directly from WordPress through the Newsletter plugin.
- We keep using mailchimp to create the newsletter and print each mail to a PDF file. This works really well when using Chromium browser, seeas an example. Apart the top mailchimp bar to remove, the PDF rendering looks great. We can then upload the PDF to our main site and offers a link to it in the Newsletter page. This way the only thing to maintain will be an archive table in the Newsletter page containing link to pdf files.
Just follow these instructions and copy / paste the HTML code at the bottom of the Newsletter page.
Jun 9 2020
Le mar. 9 juin 2020 à 16:18, anlambert (Antoine Lambert) <
email@example.com> a écrit :
Is there a way to improve the regex in https://github.com/inveniosoftware/idutils/pull/60 to allow qualifiers to come in any order instead of the canonical one?
Jun 6 2020
An important issue indeed :-)
Jun 5 2020
A quick comment on the code above: it seems to depend on the use of sha1_git parameters passed in the urls used for browsing.
While this is perfectly ok for today, we need a way to be future proof, when different versions of SWHIDs will come in, using different hashing algorithms.
Since we commit to maintain forever the resolution of previous versions of identifiers, the navigation in the webapp will need to be able to accomodate multiple hashing algorithm at the same time, and we need to plan to structure the code accordingly.
May 29 2020
May 27 2020
May 26 2020
May 25 2020
Adding a last comment after a last reread
May 21 2020
We decided to answer IPOL's question in a conservative way, by using the current metadata.xml approach, without introducing roles for authors, nor the JSON-LD format.
May 20 2020
I removed the following sentence, that will be confusing for Jose Luis (and btw, here the external library is included so it is technically not a sparse deposit either :-))
This might be a good example for the sparse deposit use case (even if in this specific case, the deposit will include the libraries).
May 19 2020
May 18 2020
I applied most of your comments,
For the snapshot key in the dictionary, use the snapshot core SWHID, not the visit integer (that is an internal implementation detail)
because I don't understand it.
Notice also that if/when we introduce new versions of SWHIDs with other
hashing algorithms, we need to maintain backward compatibility.
Metadata introduced with a given context must not be "migrated" to the new
SWHIDs, but "duplicated" for the new SWHIDs.
Better think right now of a schema that allows to "share" metadata payloads
among multiple versions of SWHIDs without actually copying them over.
Great, thanks. Dont think you need a test on a function as basic as this :-)
It would be better to make the code robust w.r.t. future potential changes in qualifier order.
Suggested pseudo-code attached (to be checked :-))
May 16 2020
Thanks for sharing this: we're definitely going forward!
Comments are in the text, but overall:
- agree that we need a way to store and retrieve metadata that is contextless (or... valid in all contexts)
- for the context, we need to use the SHWIDs themselves, not the sha1_git that is bound to version 1 of SWHIDS
May 14 2020
I would say go... HAL identifiers may be updated (not a big deal for them to update them) or may not be updated, but as you say they will be resolvable, so better have a uniform status of all deposits.
I agree: the links in the current UI presentation are sometimes confusing.
We need to think this a bit over to get all the functionalities we want into a clean UI:
A generic way to address this feature is by adding "exclusion" criteria to the existing "inclusion" criteria.
May 13 2020
Indeed! Getting the swh:rev and swh:snp for the swh:dir for the deposit
should not be that complicated navigating the Merkle tree upwards, though,
as we expect little deduplication there, but we'll need to see..
May 12 2020
- Do we migrate the old deposit values to the new ones? (sounds reasonable to do so)
May 9 2020
Once this is ready, check with HAL that everything works in software deposits (see https://gitlab.ccsd.cnrs.fr/ccsd/hal/-/issues/264)
Is this now done? If that's the case this ticked should be closed.
Now that we have access to CCSD's gitlab, this issue must move there.
May 8 2020
May 7 2020
Thanks for diving into this.
May 6 2020
May 5 2020
May 4 2020
The issue has been clarified, no need to change anything in the code, only clarifications in the documentation with examples.
Users of the deposit API command line client must add a --slug command line option to avoid the creation of a uuid.
For IPOL, we agreed on the following:
SWH configuration side: provider_url = https://doi.org/10.5201/
slug on the command line = rest of the url, that is, for example, ipol.2018.236
May 1 2020
Apr 30 2020
I hear your concerns, but the discussion already took place and we have now already 2 published articles out there using visit, plus documentation shared that uses this new terminology.
So, no, we cannot change this now.
We considered snapshot vs visit when choosing the qualifier name, and we settled with visit, as it conveys the idea that a repository snapshot is taken when a visit is performed (not necessarily through the same origin).
Apr 28 2020
Thanks @vlorentz !