From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal Resent-From: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 19 Dec 2016 03:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 25227@debbugs.gnu.org X-Debbugs-Original-To: bug-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14821171856479 (code B ref -1); Mon, 19 Dec 2016 03:14:02 +0000 Received: (at submit) by debbugs.gnu.org; 19 Dec 2016 03:13:05 +0000 Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIoNp-0001g5-96 for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:13:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIoNn-0001ft-DK for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:13:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoNh-0001ht-1k for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:12:54 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43543) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cIoNg-0001hf-VF for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:12:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIoNf-0000n1-Ey for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoNb-0001bX-Hm for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:51 -0500 Received: from mail2.openmailbox.org ([62.4.1.33]:39280) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIoNb-0001av-8J for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:47 -0500 Received: by mail2.openmailbox.org (Postfix, from userid 1001) id C40641052CA; Mon, 19 Dec 2016 04:12:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1482117165; bh=xCp21Z3ZaWY/2fKNNfuf+yYOysg3/174xe3eZso7Iw0=; h=Date:From:To:Subject:From; b=TbPYDrr1KS1AdHF5Z7MDlZOBKSBLASRVusldL4PD1PIOlCg+IFjzjzkAPSszce3s6 nCq+33jgEr1MBVzRnn0uuUX0j3Y8UfeJOKzmgBv/6QTxeoOzZ3V2eRAOR+ysqzzew3 zfD7SwmhhfSvKStQoTTF2RjC/w7vgJj7ng+Pr1lI= Received: from www.openmailbox.org (unknown [10.91.130.55]) by mail2.openmailbox.org (Postfix) with ESMTP id F2DFB1052CE for ; Mon, 19 Dec 2016 04:12:39 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Sun, 18 Dec 2016 22:12:39 -0500 From: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Message-ID: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> X-Sender: felipe.lopez@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Hi, I was thinking on improving the package-related pages, and made these=20 mockups: Figure 1. Package list page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-vie= w-v0.png Notes: - The gray circles indicate package logos. - The red tag next to the name of a package indicates it has issues (I=20 don't know if just issues as in=20 https://www.gnu.org/software/guix/packages/issues.html or building=20 problems as well). - Packages are grouped in numbered pages because displaying a given set=20 of packages in one page may bring back the page size issue. For example,=20 the current page with packages that start with G is already ~1 MiB. - The option to browse by category is something I'd like to have, but I=20 don't see categories in package definitions, so I don't know if we could=20 use that. - The option to browse by architecture... I just put it there, I don't=20 know if that's needed. Figure 2. Package detail page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-v= iew-v0.png Notes: - The screenshots is something I'd like to have, but I don't know how=20 that can be done. - The issues for a package would be in the package page, so the current=20 issues page would be removed. URL paths =3D=3D=3D=3D=3D=3D=3D=3D=3D Implementing this would create web resources in paths like these: /packages/ (Packages home page) /packages/z/ (First page of the list of packages starting with letter Z) /packages/z/page/N/ (Page N of the list of packages starting with letter Z) /packages/categories/algebra/ (First page of the list of packages for algebra) /packages/icecat-X.Y.Z/ (Page with details about IceCat version X.Y.Z) This static pagination and filtering would generate A LOT of pages, but=20 of reasonable size for web browsers to load. Possible problems with the implementation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I mentioned this proposal in bug #25045, and it seems that the amount of=20 pages generated for the filtering part of this implementation could=20 choke CVS, which is used as the deployment repository of the website=20 (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25045#17). I quote Ludovic from that bug report: > Sounds like a good plan as well, though that=E2=80=99s indeed a lot of = web=20 > pages > for that rusty CVS repo to handle=E2=80=A6 >=20 > Medium-term, I think we should consider a solution involving pages > generated on the fly server-side, with a caching proxy (nginx!) in=20 > front > of it. We=E2=80=99ll have to seek assistance from the gnu.org web mast= ers, but > ISTR they were not against that idea. That said, the proposed design, if useful, could be used independent of=20 the nature of the website (static or dynamic). What do you think? --=20 Luis Felipe L=C3=B3pez Acevedo http://sirgazil.bitbucket.org/ From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal Resent-From: Alex Sassmannshausen Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 19 Dec 2016 07:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Cc: 25227@debbugs.gnu.org Reply-To: alex@pompo.co Received: via spool by 25227-submit@debbugs.gnu.org id=B25227.14821329386385 (code B ref 25227); Mon, 19 Dec 2016 07:36:01 +0000 Received: (at 25227) by debbugs.gnu.org; 19 Dec 2016 07:35:38 +0000 Received: from localhost ([127.0.0.1]:46757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIsTx-0001eu-MF for submit@debbugs.gnu.org; Mon, 19 Dec 2016 02:35:38 -0500 Received: from mail.pompo.co ([87.243.223.35]:39418 helo=ronja.pompo.co) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIsTw-0001ee-5Q for 25227@debbugs.gnu.org; Mon, 19 Dec 2016 02:35:36 -0500 Received: from rosser (unknown [91.178.67.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ronja.pompo.co (Postfix) with ESMTPSA id 7D35740D35; Mon, 19 Dec 2016 07:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pompo.co; s=mail; t=1482132929; bh=9Ns2MHGEKbyWXodgCzNSI00agAzNI+meNZ8AYiDv+0A=; h=References:From:To:Cc:Subject:Reply-To:In-reply-to:Date:From; b=Na11AWm8shMcOxpsdfenTMcDzbZJ2Kjsmh9ca/QTULedUQW/Iv+xHnXCokD9Vl3qG WHUblOmuoaejmIs7lbg8tqBnrfRKYAoIZ/81S23DNOXheUf7SXc/M6t1FK9Kfex8fX 5EgpU9atC82wZTSG2juAIs5XmxX4kn3wNvMrQR3U= References: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> User-agent: mu4e 0.9.16; emacs 25.1.1 From: Alex Sassmannshausen In-reply-to: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> Date: Mon, 19 Dec 2016 08:35:28 +0100 Message-ID: <87r354l6bj.fsf@pompo.co> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -3.1 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.1 (---) Hi Luis, Luis Felipe López Acevedo writes: > Hi, > > I was thinking on improving the package-related pages, and made these > mockups: > > > Figure 1. Package list page. > https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-view-v0.png Overall, I really like this design. My only immediate concern would be that it's only showing 6 packages at a time. Though this probably somewhat a subjective isuse, especially as the search form would allow far better paging of results than the current static paging. After thinking about it some more, I felt it would be a shame to lose build status indicators on the "overview page". Do you think it would be possible/desirable to retain the current build status indicators beneath each package div? > Notes: > > - The gray circles indicate package logos. > - The red tag next to the name of a package indicates it has issues (I > don't know if just issues as in > https://www.gnu.org/software/guix/packages/issues.html or building > problems as well). I like this. Very intuitive. > - Packages are grouped in numbered pages because displaying a given set > of packages in one page may bring back the page size issue. For example, > the current page with packages that start with G is already ~1 MiB. Agreed. The P page is problematic too (we already have quite a few perl packages!). > - The option to browse by category is something I'd like to have, but I > don't see categories in package definitions, so I don't know if we could > use that. Previous discussions centered around how difficult it is to maintain categories for packages. I think if we went this way we'd want to implement some form of deductive faceting, where we parse description/synopsis and try to generate keywords. But that sounds like it could quite easily become a can of worms… > - The option to browse by architecture... I just put it there, I don't > know if that's needed. > > > Figure 2. Package detail page. > https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-view-v0.png > > Notes: > > - The screenshots is something I'd like to have, but I don't know how > that can be done. In fact, how would the logos work? Short of having metadata fields in package definitions (which probably is not desirable) I can't help but think that these would have to be manual additions somehow, which would not scale. Though having logos and screenshots would be huge UI wins! What about having some form of way to "mine" screenshots/logos (e.g., naive implementation: try $homepage/logo.{png,jpg}, else try $homepage/images/logo.{png,jpg}), and caching those? Again, quite elaborate, but perhaps something that could be played with iteratively? One could try something similar for screenshots, as a lot of package homepages already contain an "image gallery" anyway. We'd need to find a way to automatically locate those, and probably cache those too… WDYT? Might be over-engineering this problem… ;-) > - The issues for a package would be in the package page, so the current > issues page would be removed. I like this. > URL paths > ========= > > Implementing this would create web resources in paths like these: > > /packages/ > (Packages home page) > > /packages/z/ > (First page of the list of packages starting with letter Z) > > /packages/z/page/N/ > (Page N of the list of packages starting with letter Z) So /packages/z/ is an alias for /packages/z/page/1/? > /packages/categories/algebra/ > (First page of the list of packages for algebra) > > /packages/icecat-X.Y.Z/ > (Page with details about IceCat version X.Y.Z) > > This static pagination and filtering would generate A LOT of pages, but > of reasonable size for web browsers to load. Indeed. In general, I'm a fan of static pages. Here, we'd be generating: - 1 page per package - 1 page per 6 packages (paginated overview pages) - 1 page per 6 packages per category - 1 page per 6 packages per architecture (probably a few more than that). That is indeed a *lot* of pages… > Possible problems with the implementation > ========================================= > > I mentioned this proposal in bug #25045, and it seems that the amount of > pages generated for the filtering part of this implementation could > choke CVS, which is used as the deployment repository of the website > (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25045#17). > > I quote Ludovic from that bug report: > >> Sounds like a good plan as well, though that’s indeed a lot of web >> pages >> for that rusty CVS repo to handle… >> >> Medium-term, I think we should consider a solution involving pages >> generated on the fly server-side, with a caching proxy (nginx!) in >> front >> of it. We’ll have to seek assistance from the gnu.org web masters, but >> ISTR they were not against that idea. > > That said, the proposed design, if useful, could be used independent of > the nature of the website (static or dynamic). How would the search work with statically generated pages? Unless there's an approach that I haven't come across yet, you'd *need* dynamically generated pages for this anyway (and the search would be a requirement for useability in this design) — so it looks like we may have to go dynamic from day 1 here? > What do you think? Overall, I think this is a great initiative and effort. I love the clean and elegant design and think it would be a great win for Guix. Excellent work. HTH, Alex From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal Resent-From: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 19 Dec 2016 20:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: alex@pompo.co Cc: 25227@debbugs.gnu.org Received: via spool by 25227-submit@debbugs.gnu.org id=B25227.148217814329251 (code B ref 25227); Mon, 19 Dec 2016 20:10:02 +0000 Received: (at 25227) by debbugs.gnu.org; 19 Dec 2016 20:09:03 +0000 Received: from localhost ([127.0.0.1]:47982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ4F4-0007bj-VW for submit@debbugs.gnu.org; Mon, 19 Dec 2016 15:09:03 -0500 Received: from mail2.openmailbox.org ([62.4.1.33]:56619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ4F1-0007bC-Qt for 25227@debbugs.gnu.org; Mon, 19 Dec 2016 15:09:00 -0500 Received: by mail2.openmailbox.org (Postfix, from userid 1001) id 6081F103402; Mon, 19 Dec 2016 21:08:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1482178138; bh=KdlKAMLVxpH81XzxyYrveMaxSyAKGWWk1+USh9Qt+HA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=akmre/5cTmlNhqJBuYfCuJqDlet6G0A+ZtU5KcDd4N1SXrSrzyfhxosdrt0ljlYe5 WTT+AtH256G88NjlP+9rX2AgUxMveTC8lCx2Y3PCJrREM3LlsevgIkCCxQuYc9I4bl U9EOLVog5CoUtDXyQZjjz5TcwkOVV6jFA/l750Ak= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on h4 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from www.openmailbox.org (unknown [10.91.130.51]) by mail2.openmailbox.org (Postfix) with ESMTP id CFA821059C9; Mon, 19 Dec 2016 21:08:45 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 19 Dec 2016 15:08:44 -0500 From: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo In-Reply-To: <87r354l6bj.fsf@pompo.co> References: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> <87r354l6bj.fsf@pompo.co> Message-ID: <1ea95ccf0ed7cece5a04ded029944c98@openmailbox.org> X-Sender: felipe.lopez@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 X-Spam-Score: -3.8 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.8 (---) On 2016-12-19 02:35, Alex Sassmannshausen wrote: > Hi Luis, > > Luis Felipe López Acevedo writes: > >> Hi, >> >> I was thinking on improving the package-related pages, and made these >> mockups: >> >> >> Figure 1. Package list page. >> https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-view-v0.png > > Overall, I really like this design. My only immediate concern would be > that it's only showing 6 packages at a time. Though this probably > somewhat a subjective isuse, especially as the search form would allow > far better paging of results than the current static paging. The six packages there is just for illustration purposes (to make the mockup image smaller). The actual limit per page would be around 30 packages, depending on the resulting page size. > After thinking about it some more, I felt it would be a shame to lose > build status indicators on the "overview page". Do you think it would > be possible/desirable to retain the current build status indicators > beneath each package div? It could be included, I don't see why not. From my perspective, I'd prefer to use the red tag to indicate build issues as well. But that's just me as an average Joe user, not as a developer. >> Notes: >> >> - The gray circles indicate package logos. >> - The red tag next to the name of a package indicates it has issues (I >> don't know if just issues as in >> https://www.gnu.org/software/guix/packages/issues.html or building >> problems as well). > > I like this. Very intuitive. > >> - Packages are grouped in numbered pages because displaying a given >> set >> of packages in one page may bring back the page size issue. For >> example, >> the current page with packages that start with G is already ~1 MiB. > > Agreed. The P page is problematic too (we already have quite a few > perl > packages!). > >> - The option to browse by category is something I'd like to have, but >> I >> don't see categories in package definitions, so I don't know if we >> could >> use that. > > Previous discussions centered around how difficult it is to maintain > categories for packages. I think if we went this way we'd want to > implement some form of deductive faceting, where we parse > description/synopsis and try to generate keywords. But that sounds > like > it could quite easily become a can of worms… If that is not possible, we can just ignore it for now :) >> - The option to browse by architecture... I just put it there, I don't >> know if that's needed. >> >> >> Figure 2. Package detail page. >> https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-view-v0.png >> >> Notes: >> >> - The screenshots is something I'd like to have, but I don't know how >> that can be done. > > In fact, how would the logos work? Short of having metadata fields in > package definitions (which probably is not desirable) I can't help but > think that these would have to be manual additions somehow, which would > not scale. > > Though having logos and screenshots would be huge UI wins! > > What about having some form of way to "mine" screenshots/logos (e.g., > naive implementation: try $homepage/logo.{png,jpg}, else try > $homepage/images/logo.{png,jpg}), and caching those? Again, quite > elaborate, but perhaps something that could be played with iteratively? > > One could try something similar for screenshots, as a lot of package > homepages already contain an "image gallery" anyway. We'd need to find > a way to automatically locate those, and probably cache those too… > > WDYT? Might be over-engineering this problem… ;-) Seeing the way the current logos from GNU packages are handled, I'm not optimist about having logos for non-GNU packages and screenshots for applications, any time soon. Too much manual work indeed. So I think we can ignore images, to keep it simple. >> - The issues for a package would be in the package page, so the >> current >> issues page would be removed. > > I like this. > >> URL paths >> ========= >> >> Implementing this would create web resources in paths like these: >> >> /packages/ >> (Packages home page) >> >> /packages/z/ >> (First page of the list of packages starting with letter Z) >> >> /packages/z/page/N/ >> (Page N of the list of packages starting with letter Z) > > So /packages/z/ is an alias for /packages/z/page/1/? Yes, both exist, but have the same content. >> /packages/categories/algebra/ >> (First page of the list of packages for algebra) >> >> /packages/icecat-X.Y.Z/ >> (Page with details about IceCat version X.Y.Z) >> >> This static pagination and filtering would generate A LOT of pages, >> but >> of reasonable size for web browsers to load. > > Indeed. In general, I'm a fan of static pages. Here, we'd be > generating: > - 1 page per package > - 1 page per 6 packages (paginated overview pages) > - 1 page per 6 packages per category > - 1 page per 6 packages per architecture > > (probably a few more than that). > > That is indeed a *lot* of pages… > >> Possible problems with the implementation >> ========================================= >> >> I mentioned this proposal in bug #25045, and it seems that the amount >> of >> pages generated for the filtering part of this implementation could >> choke CVS, which is used as the deployment repository of the website >> (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25045#17). >> >> I quote Ludovic from that bug report: >> >>> Sounds like a good plan as well, though that’s indeed a lot of web >>> pages >>> for that rusty CVS repo to handle… >>> >>> Medium-term, I think we should consider a solution involving pages >>> generated on the fly server-side, with a caching proxy (nginx!) in >>> front >>> of it. We’ll have to seek assistance from the gnu.org web masters, >>> but >>> ISTR they were not against that idea. >> >> That said, the proposed design, if useful, could be used independent >> of >> the nature of the website (static or dynamic). > > How would the search work with statically generated pages? Unless > there's an approach that I haven't come across yet, you'd *need* > dynamically generated pages for this anyway (and the search would be a > requirement for useability in this design) — so it looks like we may > have to go dynamic from day 1 here? Generate JSON files with packages grouped alphabetically, and display results in the current page? But yes, the limitations of static sites :) >> What do you think? > > Overall, I think this is a great initiative and effort. I love the > clean and elegant design and think it would be a great win for Guix. > Excellent work. Glad to hear that, Alex. Thanks a bunch for taking the time to give some feedback :) So I see that some parts of the design could be used in the current static site, advanced filtering and search may have to wait for a dynamic site, logos and screenshots may be a can of worms. -- Luis Felipe López Acevedo http://sirgazil.bitbucket.org/ From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 19 Dec 2016 21:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Cc: 25227@debbugs.gnu.org, alex@pompo.co Received: via spool by 25227-submit@debbugs.gnu.org id=B25227.14821821123310 (code B ref 25227); Mon, 19 Dec 2016 21:16:02 +0000 Received: (at 25227) by debbugs.gnu.org; 19 Dec 2016 21:15:12 +0000 Received: from localhost ([127.0.0.1]:48008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ5H6-0000rK-JI for submit@debbugs.gnu.org; Mon, 19 Dec 2016 16:15:12 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41977) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ5H5-0000r8-8P for 25227@debbugs.gnu.org; Mon, 19 Dec 2016 16:15:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJ5Gv-0007Qu-9b for 25227@debbugs.gnu.org; Mon, 19 Dec 2016 16:15:06 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49554) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ5Gv-0007Qq-6x; Mon, 19 Dec 2016 16:15:01 -0500 Received: from reverse-83.fdn.fr ([80.67.176.83]:54534 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cJ5Gu-0004Vl-J8; Mon, 19 Dec 2016 16:15:00 -0500 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> <87r354l6bj.fsf@pompo.co> <1ea95ccf0ed7cece5a04ded029944c98@openmailbox.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 29 Frimaire an 225 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu Date: Mon, 19 Dec 2016 22:14:58 +0100 In-Reply-To: <1ea95ccf0ed7cece5a04ded029944c98@openmailbox.org> ("Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo"'s message of "Mon, 19 Dec 2016 15:08:44 -0500") Message-ID: <87k2av1uzx.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) Hello! Luis Felipe L=C3=B3pez Acevedo skribis: > On 2016-12-19 02:35, Alex Sassmannshausen wrote: >> Hi Luis, >> >> Luis Felipe L=C3=B3pez Acevedo writes: >> >>> Hi, >>> >>> I was thinking on improving the package-related pages, and made these >>> mockups: >>> >>> >>> Figure 1. Package list page. >>> https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-v= iew-v0.png Awesome, I really like both mockups! >> Previous discussions centered around how difficult it is to maintain >> categories for packages. I think if we went this way we'd want to >> implement some form of deductive faceting, where we parse >> description/synopsis and try to generate keywords. But that sounds >> like >> it could quite easily become a can of worms=E2=80=A6 > > > If that is not possible, we can just ignore it for now :) We already have categories for GNU packages, and in theory it might be possible to get categories for non-GNU packages from the FSD (directory.fsf.org). But that=E2=80=99s just theory, so yes, probably best to keep it as future work. :-) In the meantime, we can try to find Someone willing to see how we could get data from the FSD. > Seeing the way the current logos from GNU packages are handled, I'm > not optimist about having logos for non-GNU packages and screenshots > for applications, any time soon. Too much manual work indeed. So I > think we can ignore images, to keep it simple. Agreed. In the future, we could also try to get logos and screenshot from some other database: FSD, Debian/Ubuntu, WikiData, etc. > So I see that some parts of the design could be used in the current > static site, advanced filtering and search may have to wait for a > dynamic site, logos and screenshots may be a can of worms. I=E2=80=99ve started a discussion with the Savannah folks (Cc=E2=80=99d you= ) to see whether/how we could have those pages generated on the server side. Thank you for the great work! Ludo=E2=80=99. From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal References: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> In-Reply-To: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> Resent-From: sirgazil Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Wed, 13 Feb 2019 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 25227@debbugs.gnu.org Received: via spool by 25227-submit@debbugs.gnu.org id=B25227.15500681492967 (code B ref 25227); Wed, 13 Feb 2019 14:30:02 +0000 Received: (at 25227) by debbugs.gnu.org; 13 Feb 2019 14:29:09 +0000 Received: from localhost ([127.0.0.1]:45914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gtvXA-0000ll-6k for submit@debbugs.gnu.org; Wed, 13 Feb 2019 09:29:08 -0500 Received: from sender-pp-091.zoho.com ([135.84.80.236]:25136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gtvX7-0000lY-KN for 25227@debbugs.gnu.org; Wed, 13 Feb 2019 09:29:07 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1550068129; cv=none; d=zoho.com; s=zohoarc; b=RfyCnNyzfvIBuuqjtpnkZKtcxOlPpItyrMSQkKIv9au8t49jalVTbKEFHeNs7GZdDhOeRyLM0WpptzuEQryah4JJhdV1mG5IKeIefvgJx3eHNXuAxFUxlx0d1YJDLPMFYx/ZzVD38IcYg3yzEklZph/3CwtOnjk1+kww08fzTVE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1550068129; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=oHBIsZS0dDfLgzBU0yFM4P/D6IjgCWf+dhYxhkneelw=; b=c0KY6IX6sn9kFzJ2Hc/FbvqRhIhiqN9eENoh7mUsPDUJOp7vPteMkttB3UtEPR0SjBq+g6thA8ce722+JPA/pMGmozPm3YVjy+BjpWQBcIXugGJAYMs2i10RG8gqxQAmr/h3f9u+yNqVWY6kt5QNyFWykyy35SMkQLrhK+iQPEA= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=sirgazil@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=to:from:message-id:subject:date:user-agent:mime-version:content-type; b=t2cDgTZ/NlI0RWgEhrSYSyLipXfwLIrvkEu9j2DBl6VvPFh3bgo7dzEFWNPVGC8wueZHFpJmL29Q gvLfiwvyXYhJFYQ9j1jQZUutiAxJ1Yp9yuqygqXuTFq7gs29K0T1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1550068129; s=default; d=zoho.com; i=sirgazil@zoho.com; h=To:From:Message-ID:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1659; bh=oHBIsZS0dDfLgzBU0yFM4P/D6IjgCWf+dhYxhkneelw=; b=aL1CMb6RVSJz3ayAL8abRX25CwUb5D6uJHqynSrrjdIzffRThiK3xv/gu5YodzMi 4KIBpGsGzJyygPrvH9L5sj1Wx/UULiJXqy/cEblZ8qJ3hWVNItsWRBto8+4bwPTCOEz vMCcFHpg2eq4F9HxPXZ/wMBstO/r5mP7OQGGv60Y= Received: from [192.168.1.57] (181.130.25.222 [181.130.25.222]) by mx.zohomail.com with SMTPS id 155006812760090.04900086700695; Wed, 13 Feb 2019 06:28:47 -0800 (PST) From: sirgazil Message-ID: Date: Wed, 13 Feb 2019 09:28:45 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, I'd like to summarize the status of this proposal. Parts of this proposal that have been implemented in the website source=20 (https://git.savannah.gnu.org/cgit/guix/guix-artwork.git) include: * Paginated list of packages (available both in gnu.org and guix.info). * Individual package pages (available in guix.info only). Using individual package pages in gnu.org continues to be a problem=20 because of the CVS limitation. However, here is a recent comment from=20 Ricardo Wurmus, one of GNU Guix maintainers, about a possible future for=20 the Guix website=20 (https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00107.html): > Eventually, I=E2=80=99d like guix.info to disappear and to be replaced w= ith > guix.gnu.org, but that new domain isn=E2=80=99t ready yet. Eventually, > the DNS records for guix.gnu.org and all subdomains should be managed > by us and be hosted on our servers, so we no longer suffer from > limitations imposed by the use of CVS, for example. Finally, the following parts were not implemented, but could be in the=20 future: * Category and architecture filters. * Package issue indicators (lint, build issues). (Actually, page templates have the code to display the indicator and list lint issues, but the `package-lint-issues` procedure is a stub.) * Package logo and screenshots. I think this proposal could be closed once guix.gnu.org is available and=20 the current implementation deployed to it. The parts that were not=20 implemented could be reported as individual issues if necessary. --=20 Luis Felipe L=C3=B3pez Acevedo http://sirgazil.bitbucket.io/ From unknown Fri Jun 20 20:05:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25227: [Website] Package-related pages redesign proposal References: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> In-Reply-To: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> Resent-From: sirgazil Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 14 Feb 2019 00:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25227 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 25227@debbugs.gnu.org Received: via spool by 25227-submit@debbugs.gnu.org id=B25227.155010514912243 (code B ref 25227); Thu, 14 Feb 2019 00:46:01 +0000 Received: (at 25227) by debbugs.gnu.org; 14 Feb 2019 00:45:49 +0000 Received: from localhost ([127.0.0.1]:47502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gu59x-0003BO-7M for submit@debbugs.gnu.org; Wed, 13 Feb 2019 19:45:49 -0500 Received: from sender-pp-091.zoho.com ([135.84.80.236]:25063) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gu59v-0003BD-2Z for 25227@debbugs.gnu.org; Wed, 13 Feb 2019 19:45:48 -0500 ARC-Seal: i=1; a=rsa-sha256; t=1549990661; cv=none; d=zoho.com; s=zohoarc; b=KkwuEwUmcQa3PiM+fXpT2ff+04Twe4q1zrxI9MJR15tkr+w7f+qBi80qK7Myv8uSkj9bQaDsJrHRdJvhoHfrCTyyvn2zuGBljO498X0zdc1QMFGX7vwb43Ke8poGzc7peoBew4j84wjno8WRlDqF2puGXsj1D1Npo21tXL5/MXw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1549990661; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results; bh=T0kggBa32b0LAf/TwT1mEs6rUjdiZBYE/kbfgSI7Jek=; b=Z5PA2hn4F1W5u+7u+ESOXkoauOF6cAAqyFmHe1HkeVmIsLKtqWEhOrRf27Ztg9ZR4WGzAsKvJUVnT7PPp/bUFmTtN8cmVm+wq7JAGcCUeqX1XGEwZ3iXZs4zJf19t9Mf4eXviB3Oc/EnalUJaidkJy7OGRbcqZvettfkgas0zpM= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=sirgazil@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=to:from:message-id:subject:date:user-agent:mime-version:content-type; b=v4BNu3Ziw7dcu093Dd7pW1Jc0+4JImW/An54E3slTtreAmLB5UD3DsUqSnm2Dqk84Ih03Xfo3fCF gzupzoGk4zDgKzd7h+hRlZpBbS7jb332oRPTNZOYGIXzg1C4MPi5 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1549990661; s=default; d=zoho.com; i=sirgazil@zoho.com; h=To:From:Message-ID:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding; l=1661; bh=T0kggBa32b0LAf/TwT1mEs6rUjdiZBYE/kbfgSI7Jek=; b=kgt1EKelkWKv1WYpSsPoiP9aFzd8WGLuipJ9qULXkwdluz1nmKgGLhECri0E3EXB 2s58PE0idURAiJmJdC3vu+j5cXcIrWJ5L3moOhEXOosq0d5XhRZr/V34P20MDBZqCYX xS+zGuIp8ctr+dI2eJYSsZxqeBxqh9BGj45Lunz8= Received: from [192.168.1.57] (181.130.25.222 [181.130.25.222]) by mx.zohomail.com with SMTPS id 1549990658827948.978431070229; Tue, 12 Feb 2019 08:57:38 -0800 (PST) From: sirgazil Message-ID: <8ca1499f-a02a-3de9-630d-8a7bb71376dd@zoho.com> Date: Tue, 12 Feb 2019 11:57:36 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, I'd like to summarize the status of this proposal. Parts of this proposal that have been implemented in the website source=20 (https://git.savannah.gnu.org/cgit/guix/guix-artwork.git) include: * Paginated list of packages (available both in gnu.org and guix.info). * Individual package pages (available in guix.info only). Using individual package pages in gnu.org continues to be a problem=20 because of the CVS limitation. However, here is a recent comment from=20 Ricardo Wurmus, one of GNU Guix maintainers, about a possible future for=20 the Guix website=20 (https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00107.html): > Eventually, I=E2=80=99d like guix.info to disappear and to be replaced w= ith > guix.gnu.org, but that new domain isn=E2=80=99t ready yet. Eventually, > the DNS records for guix.gnu.org and all subdomains should be managed > by us and be hosted on our servers, so we no longer suffer from > limitations imposed by the use of CVS, for example. Finally, the following parts were not implemented, but could be in the=20 future: * Category and architecture filters. * Package issue indicators (lint, build issues). (Actually, page templates have the code to display the indicator and list lint issues, but the `package-lint-issues` procedure is a stub.) * Package logo and screenshots. I think this proposal could be closed once guix.gnu.org is available and=20 the current implementation deployed to it. The parts that were not=20 implemented could be reported as individual issues if necessary. --=20 Luis Felipe L=C3=B3pez Acevedo http://sirgazil.bitbucket.io/ From unknown Fri Jun 20 20:05:32 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Luis Felipe =?UTF-8?Q?L=C3=B3pez?= Acevedo Subject: bug#25227: closed ([Website] Package-related pages redesign proposal) Message-ID: References: <174d07cbbd0.ac6275cb22655.3734740254168230788@zoho.com> <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> X-Gnu-PR-Message: they-closed 25227 X-Gnu-PR-Package: guix Reply-To: 25227@debbugs.gnu.org Date: Sun, 27 Sep 2020 16:55:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1601225702-26559-1" This is a multi-part message in MIME format... ------------=_1601225702-26559-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #25227: [Website] Package-related pages redesign proposal which was filed against the guix package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 25227@debbugs.gnu.org. --=20 25227: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25227 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1601225702-26559-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 25227-done) by debbugs.gnu.org; 27 Sep 2020 16:54:39 +0000 Received: from localhost ([127.0.0.1]:50329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMZwd-0006tm-AZ for submit@debbugs.gnu.org; Sun, 27 Sep 2020 12:54:39 -0400 Received: from sender4-pp-o93.zoho.com ([136.143.188.93]:25315) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kMZwa-0006tb-Ne for 25227-done@debbugs.gnu.org; Sun, 27 Sep 2020 12:54:37 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1601225674; cv=none; d=zohomail.com; s=zohoarc; b=fKlxqz3ctIE+QA2muyzW6WTfX07ThVkaIWJjPWlhsbeMLpbLgSROgdwUEeYJWDcgBqyZd4Hz3IXCCvTwVPFI8RI3ZdNCmGgYXdqNUKB8gWua7vwhP5VwuWAoEG9c2Dh+lBEjU7mVP0pOXCgHemxRLXuQHnrZv/7/M8JAW1C0aYg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1601225674; h=Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:Message-ID:Subject:To; bh=0Jn+EoeeFh9WzCmdP9G0g2H344H1Bj8Ll3jvrSonUEE=; b=G33iu3X4S6x5/04lIaAWkear4mostQXsOb6jZu4IGqne6NC9p5uEzhaC0wxazlVjUwOO3z9O2rLTjdMFsSik/1dkL2ci9TxnguZWCAuGvB6XWjwRbIJ7CYrJqmWWn8gTfeSl0Ox0FgG2nxai9KD2g58hONNhkWR/MrT1uN/F+NU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=zoho.com; spf=pass smtp.mailfrom=sirgazil@zoho.com; dmarc=pass header.from= header.from= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=date:from:to:message-id:in-reply-to:subject:mime-version:content-type:user-agent; b=pbedUwrtxvrOjISk90lBk1A0hPgiDolgdXgzGfrkkhLcYghiRii0vKW9BwQnpN2Bu/cUoCdjJUsD JMGRBhAyk/Ps1oi+PsxX/+PSZ5WTelYdVmpcfamhFuvbPxAQ9jBf DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1601225674; s=zm2020; d=zoho.com; i=sirgazil@zoho.com; h=Date:From:To:Message-ID:In-Reply-To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=0Jn+EoeeFh9WzCmdP9G0g2H344H1Bj8Ll3jvrSonUEE=; b=FdI8zf28bc5v8leQcN9fq1ZlYwFNFxlzz3ZvIlGeKfi/b0asfNCWRVvnTE4bZjCq MsgcZl0MlLD1S9/p9RsD17mP8LxOJI7OmI2+YO+uDktZtSjRZsLU8KQH6KUb6lFFYQp /drrKFcrWP8Z3IULJdC7mK51Ob7CtZ3y+p8V6OzY= Received: from mail.zoho.com by mx.zohomail.com with SMTP id 1601225669585170.11235447340857; Sun, 27 Sep 2020 09:54:29 -0700 (PDT) Received: from [179.15.13.185] by mail.zoho.com with HTTP;Sun, 27 Sep 2020 09:54:29 -0700 (PDT) Date: Sun, 27 Sep 2020 11:54:29 -0500 From: sirgazil To: "25227-done" <25227-done@debbugs.gnu.org> Message-ID: <174d07cbbd0.ac6275cb22655.3734740254168230788@zoho.com> In-Reply-To: Subject: [Website] Package-related pages redesign proposal MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Importance: Medium User-Agent: Zoho Mail X-Mailer: Zoho Mail X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Closing this, since guix.gnu.org is available for several months now. Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (sirgazil[at]zoho.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [136.143.188.93 listed in list.dnswl.org] 1.0 PDS_TONAME_EQ_TOLOCAL_VSHORT Very short body and From looks like 2 different emails 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches everything in local email X-Debbugs-Envelope-To: 25227-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Closing this, since guix.gnu.org is available for several months now. Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [136.143.188.93 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (sirgazil[at]zoho.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 PDS_TONAME_EQ_TOLOCAL_VSHORT Very short body and From looks like 2 different emails 2.0 PDS_TONAME_EQ_TOLOCAL_SHORT Short body with To: name matches everything in local email -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Closing this, since guix.gnu.org is available for several months now. ------------=_1601225702-26559-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 19 Dec 2016 03:13:05 +0000 Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIoNp-0001g5-96 for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:13:04 -0500 Received: from eggs.gnu.org ([208.118.235.92]:37750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIoNn-0001ft-DK for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:13:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoNh-0001ht-1k for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:12:54 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:43543) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cIoNg-0001hf-VF for submit@debbugs.gnu.org; Sun, 18 Dec 2016 22:12:52 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIoNf-0000n1-Ey for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIoNb-0001bX-Hm for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:51 -0500 Received: from mail2.openmailbox.org ([62.4.1.33]:39280) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIoNb-0001av-8J for bug-guix@gnu.org; Sun, 18 Dec 2016 22:12:47 -0500 Received: by mail2.openmailbox.org (Postfix, from userid 1001) id C40641052CA; Mon, 19 Dec 2016 04:12:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1482117165; bh=xCp21Z3ZaWY/2fKNNfuf+yYOysg3/174xe3eZso7Iw0=; h=Date:From:To:Subject:From; b=TbPYDrr1KS1AdHF5Z7MDlZOBKSBLASRVusldL4PD1PIOlCg+IFjzjzkAPSszce3s6 nCq+33jgEr1MBVzRnn0uuUX0j3Y8UfeJOKzmgBv/6QTxeoOzZ3V2eRAOR+ysqzzew3 zfD7SwmhhfSvKStQoTTF2RjC/w7vgJj7ng+Pr1lI= Received: from www.openmailbox.org (unknown [10.91.130.55]) by mail2.openmailbox.org (Postfix) with ESMTP id F2DFB1052CE for ; Mon, 19 Dec 2016 04:12:39 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Sun, 18 Dec 2016 22:12:39 -0500 From: =?UTF-8?Q?Luis_Felipe_L=C3=B3pez_Acevedo?= To: bug-guix@gnu.org Subject: [Website] Package-related pages redesign proposal Message-ID: <947ab515dfb2323742d5a83dfc183de5@openmailbox.org> X-Sender: felipe.lopez@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) Hi, I was thinking on improving the package-related pages, and made these=20 mockups: Figure 1. Package list page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-list-vie= w-v0.png Notes: - The gray circles indicate package logos. - The red tag next to the name of a package indicates it has issues (I=20 don't know if just issues as in=20 https://www.gnu.org/software/guix/packages/issues.html or building=20 problems as well). - Packages are grouped in numbered pages because displaying a given set=20 of packages in one page may bring back the page size issue. For example,=20 the current page with packages that start with G is already ~1 MiB. - The option to browse by category is something I'd like to have, but I=20 don't see categories in package definitions, so I don't know if we could=20 use that. - The option to browse by architecture... I just put it there, I don't=20 know if that's needed. Figure 2. Package detail page. https://multimedialib.files.wordpress.com/2016/12/guixsd-package-detail-v= iew-v0.png Notes: - The screenshots is something I'd like to have, but I don't know how=20 that can be done. - The issues for a package would be in the package page, so the current=20 issues page would be removed. URL paths =3D=3D=3D=3D=3D=3D=3D=3D=3D Implementing this would create web resources in paths like these: /packages/ (Packages home page) /packages/z/ (First page of the list of packages starting with letter Z) /packages/z/page/N/ (Page N of the list of packages starting with letter Z) /packages/categories/algebra/ (First page of the list of packages for algebra) /packages/icecat-X.Y.Z/ (Page with details about IceCat version X.Y.Z) This static pagination and filtering would generate A LOT of pages, but=20 of reasonable size for web browsers to load. Possible problems with the implementation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I mentioned this proposal in bug #25045, and it seems that the amount of=20 pages generated for the filtering part of this implementation could=20 choke CVS, which is used as the deployment repository of the website=20 (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25045#17). I quote Ludovic from that bug report: > Sounds like a good plan as well, though that=E2=80=99s indeed a lot of = web=20 > pages > for that rusty CVS repo to handle=E2=80=A6 >=20 > Medium-term, I think we should consider a solution involving pages > generated on the fly server-side, with a caching proxy (nginx!) in=20 > front > of it. We=E2=80=99ll have to seek assistance from the gnu.org web mast= ers, but > ISTR they were not against that idea. That said, the proposed design, if useful, could be used independent of=20 the nature of the website (static or dynamic). What do you think? --=20 Luis Felipe L=C3=B3pez Acevedo http://sirgazil.bitbucket.org/ ------------=_1601225702-26559-1--