[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26006: [Website] Integral update proposal

From: sirgazil
Subject: bug#26006: [Website] Integral update proposal
Date: Thu, 15 Jun 2017 21:52:41 -0500
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 15/06/17 02:59, Ludovic Courtès wrote:
> Hello,
> sirgazil <address@hidden> 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?

Right. My mistake :)

>>> 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.  :-)

No worries. The idea was to move the useful parts to guix-artwork on

To be honest, when I started this version of the website I was just
motivated on implementing the designs and exploring a way to organize
modules in a haunt website so that data, builders and templates were
separated. But I was not very interested in dealing with git workflows,
and strict commit messages. Sorry about that :)

So, what do we do? Create a branch on guix-artwork and drop these files
there to complete what is missing? I don't know...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]