GNU bug report logs -
#25227
[Website] Package-related pages redesign proposal
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 <at> debbugs.gnu.org.
--
25227: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=25227
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Closing this, since guix.gnu.org is available for several months now.
[Message part 3 (message/rfc822, inline)]
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
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).
- 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.
- 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.
- 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.
- The issues for a package would be in the package page, so the current
issues page would be removed.
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)
/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.
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).
What do you think?
--
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/
This bug report was last modified 4 years and 238 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.