Re: Data Services: use cases

Hi Chris >> Service will store when the branch was updated (it uses the date of the >> email as a proxy for this). > > Now, after this discussion, I am not convinced anymore that the email > header date is the right thing because we (user) do not have this > information when debugging locally;

Re: Data Services: use cases

Pierre Neidhardt writes: > Thanks! Maybe this could be added to the View packages page as well to > avoid too many page loads? This is one of the most useful pages in my > experience, and it's like 3-4 pages away. Do you mean link to something else on this [1] page? 1:

Re: Data Services: use cases

Hi Chris, On Mon, 16 Nov 2020 at 21:08, Christopher Baines wrote: > Yeah, I think you're on the right track. I'm not set on mirroring the > exact Debian services though. Yeah, for sure. Just to fix the idea by approximated examples. :-) > A similar idea to the package search prototype here

Re: Data Services: use cases

Pierre Neidhardt writes: > Christopher Baines writes: > >>> - (More information) should be renamed to something like "Package >>> information". >> >> I've made this change now. > > Great! > > Something else: I couldn't figure out how to access > >

Re: Data Services: use cases

On Mon, 16 Nov 2020 at 21:50, Christopher Baines wrote: >> The first commit producing j5llsz…-ghc-haddock is not >> 3922208091 but 12dc9f58c4. And then compare: >> >> author date commit date >> 3922208091|Thu Jul 23 14:03:19 2020|Fri Jul 24 14:21:31 2020 >>

Re: Data Services: use cases

zimoun writes: > Cool! I have seen that you added the commit! Great. > > On Mon, 16 Nov 2020 at 20:54, Christopher Baines wrote: > > 2: > The Guix Data Service stores the date in the email from the Git hook

Re: Data Services: use cases

Cool! I have seen that you added the commit! Great. On Mon, 16 Nov 2020 at 20:54, Christopher Baines wrote: 2: >>> The Guix Data Service stores the date in the email from the Git hook >>> that runs when one pushes

Re: Data Services: use cases

zimoun writes: > Hi Chris, > > On Mon, 16 Nov 2020 at 19:17, Christopher Baines wrote: > >>> - list all the versions available (since Dec. 2019 I guess) >>> - know which build and which not >>> - easily find the commit for “guix time-machine” > > [...] > >> Maybe there could be a

Re: Data Services: use cases

zimoun writes: > Hi Chris, > > On Mon, 16 Nov 2020 at 19:28, Christopher Baines wrote: > >>> I recently have a very similar issue [1]. And based on my >>> investigations [2], the issue seems "commit date vs author date"; >>> especially when merges are floating around. Because of that, from

Re: Data Services: use cases

Hi Chris, On Mon, 16 Nov 2020 at 19:17, Christopher Baines wrote: >> - list all the versions available (since Dec. 2019 I guess) >> - know which build and which not >> - easily find the commit for “guix time-machine” [...] > Maybe there could be a packages.guix.gnu.org service which pulls

Re: Data Services: use cases

Hi Chris, On Mon, 16 Nov 2020 at 19:28, Christopher Baines wrote: >> I recently have a very similar issue [1]. And based on my >> investigations [2], the issue seems "commit date vs author date"; >> especially when merges are floating around. Because of that, from >> "From" to "To" is not

Re: Data Services: use cases

Ludovic Courtès writes: > Hi, > > Pierre Neidhardt skribis: > >> In particular, the "Version From To" table is hard to grasp to a >> newcomer. > > I’m not a newcomer but I find it limpid: I think it immediately shows > that this is about version changes and when they happened. Maybe it >

Re: Data Services: use cases

zimoun writes: >> BTW, when looking at /output-history, the commits in “From” and “To” can >> be a bit confusing. Take: >> >> >> https://data.guix.gnu.org/repository/1/branch/master/package/openmpi/output-history >> >> I see “To” pointing to >>

Re: Data Services: use cases

Pierre Neidhardt writes: > Sorry if I'm stating the obvious, but ideally it'd be nice if the > interface would be so straightforward it didn't need any instructions to > use :) > > In particular, the "Version From To" table is hard to grasp to a > newcomer. > > During the Guix Days we talked

Re: Data Services: use cases

zimoun writes: > Hi Chris, > > Since blog post about Data Services seems floating around, I describe > what I find useful as an end-user of the service. And if you have not > showed me IRL at FOSDEM (and you showed me several times ;-)), then I > would not be using the service so often. ...

Re: Data Services: use cases

Hi Ludo, On Wed, 21 Oct 2020 at 11:27, Ludovic Courtès wrote: > Pierre Neidhardt skribis: > > > In particular, the "Version From To" table is hard to grasp to a > > newcomer. > > I’m not a newcomer but I find it limpid: I think it immediately shows > that this is about version changes and when

Re: Data Services: use cases

Hi Ludo! Ludovic Courtès writes: > I’m not a newcomer but I find it limpid: I think it immediately shows > that this is about version changes and when they happened. What about the 4 points I listed? I find that they make a case for what could be improved in terms of clarity. Cheers! --

Re: Data Services: use cases

Hi, Pierre Neidhardt skribis: > In particular, the "Version From To" table is hard to grasp to a > newcomer. I’m not a newcomer but I find it limpid: I think it immediately shows that this is about version changes and when they happened. Maybe it could be decluttered a bit by using shorter

Re: Data Services: use cases

Hi! Sorry if I'm stating the obvious, but ideally it'd be nice if the interface would be so straightforward it didn't need any instructions to use :) In particular, the "Version From To" table is hard to grasp to a newcomer. During the Guix Days we talked about how to make it a bit more

Data Services: use cases

Hi Chris, Since blog post about Data Services seems floating around, I describe what I find useful as an end-user of the service. And if you have not showed me IRL at FOSDEM (and you showed me several times ;-)), then I would not be using the service so often. To me, the entry point is always: