GNU bug report logs - #26006
[Website] Integral update proposal

Previous Next

Full log

View this message in rfc822 format

From: ludo <at> gnu.org (Ludovic Courtès)
To: sirgazil <sirgazil <at> zoho.com>
Cc: 26006 <at> debbugs.gnu.org
Subject: bug#26006: [Website] Integral update proposal
Date: Thu, 15 Jun 2017 09:59:53 +0200

Hello,

sirgazil <sirgazil <at> zoho.com> skribis:

> On 13/06/17 17:08, Ludovic Courtès wrote:

[...]

>> I found it a little bit confusing that talks and papers now appear as if
>> they were blog posts, but after all it’s probably better to have it this
>> way, especially since tags allow people to find them more easily I guess.
>>
>> The packages pages look better than what we have (minus the loss of the
>> JS code to display the build status ;-)).
>
> About the JS, I couldn't figured out exactly how it works, so that I
> could adapt it to the new page structure. Additionally, there is the
> problem that the JS looks for packages in the DOM by id, and package ids
> are not unique, which confuses me. Also, using duplicated id attributes
> is non-valid HTML.

The current code that generates the package pages intends to compute
unique anchor names for each package (see ‘packages->anchors’), and I
think it’s those IDs that the JS code uses, isn’t it?

>> I think there are a few little changes that were made in the current
>> site that were lost in the process.  For example, on the front page, we
>> now have “DOWNLOAD v0.13.0” instead of “TEST v0.13.0”.  I’ve also seen
>> that links to the package definitions at git.sv.gnu.org from the package
>> pages no longer include the commit.  Anyway, these are really tiny
>> issues but we should pay attention to them when we migrate.
>
> I updated the download button.
>
> As for the commit in the links, I tried to add it, but couldn't. I
> implemented this website using the Guix API as a user (installing guix
> with guix), but it seems that the code to generate the commit part in
> the links requires that the guix in the GUILE_LOAD_PATH be a git
> repository, right? Since it uses "git describe" on "guix/config.scm".

Indeed, good point.  I guess we could have a fallback case for when ‘git
describe’ fails.

On a more practical level, what would you like the workflow to be like
from there on?  I would prefer hosting the source on gnu.org rather than
{bitbucket,gitlab,github}.com and I would also prefer Git over
Mercurial, but I don’t want to be a hindrance so I’m open to
discussions.  :-)

Thanks!

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.