I got pinged yesterday on IRC (I hang out on Freenode far too often) about putting together a roadmap for what’s left to getting the new Gentoo packages website live …. so here it is.
This is an incomplete list, and I’ve just started jotting it down yesterday afternoon as I started working on the site some more. Also, it’s a brain dump, so excuse the randomness.
Roadmap:
- package masks
- website; new design
- load testing
- bash script w/import options
- expanded versions
- options to use find all ebuilds updated recently
- status column for updates to happen in background
- db classes to access properties
I’ll explain quickly what some of those mean.
Finding out whether a package is masked or not is a real pain in the butt. The reason is you have so many ways a package can be masked. I’m not gonna go into the coding required to checking it. It’s possible, and it’s nice when it’s done, but it’s painful to write out.
New website — yes, I’m rewriting it from scratch. Well, the backend. The functionality is going to be there 100%, so nothing is going to be lost. If anything, there’s gonna be a lot more stuff. I’m also hoping to get a new design done before launching it. Also, I’m probably going to do a closed testing invite session before launching it, so I can get some serious feedback first.
Okay, the status column thingie — that’s gonna eliminate one really annoying feature of the last website. It would shut down for about 5 minutes while the site was updating, because it would delete stuff and add stuff all over the place. The new one is just going to insert all the new stuff in the background, but won’t flip it on to be actually visible until the import is completed. So, it’ll be completely transparent to the user, and the site will always have populated data, and any updates will just show up all of a sudden.
Now, some of the feature requests:
- RSS feeds
- XML API
- import all metadata
- parse changelogs
- profile masks
- tags
- track deleted ebuilds, packages
- screenshots
- user ratings
- twitter feed
- GLSA integration
A quick disclaimer — no idea if and/or when any of those are going to be done, because they are all unnecessary to the actual launch of the site itself, which is what I’m working on now. Another quick recap on what I’m planning, though.
The RSS feeds are going to be much better this time, and I’ll have a larger selection: new ebuilds, recently updated ebuilds, per-arch feeds, etc. And they’ll have all the same info on the website too.
The XML API, which I’ve mentioned before, isn’t really going to be that fancy to start with. You’ll just be able to do something like browse to website/app-admin/foobar/xml and it will have an XML printout of all the data that I have on that package. Same for category pages, too. Nothing fancy to start with. Oh yes, I’ll also produce database dumps as usual.
I need to import all metadata too to get GPNL back on its feet. I already *have* it all in the database, but just as the raw original strings. I need to sort through it and get it into its individual tables. Again, I’m just doing the bare minimum right now to get the site up and running.
Parsing the changelogs, ugh. That’s a new feature I tried adding in the old website, and it never quite worked out exactly how I planned. I’ll get that one in eventually.
Profile support is one feature I’m really excited about, and one I wanted to keep a lid on for as long as possible. Oh well. Now you know. 🙂 Basically, I’m going to add support to the site to browse the keyword statuses for a specific profile instead of just the default one. Once you change your profile, it’ll affect package masks … and, that’s about it for now. Still I think it’d be a handy feature.
Tags, screenshots, user ratings — just some features that I’ll eventually add to make the site actually accept user input. That’s gonna be a long way off because of all the work involved in user accounts and preferences and uploads.
Tracking deleted ebuilds — I’m still debating whether I want to do this one or not. I mean, I’ll track them in the database, but it could be inaccurate for a number of reasons. Not sure if I’m going to have a display for it on the website or not. Would be kinda nice, though.
GLSA integration will hopefully be easy enough, I haven’t looked at it at all. Just track what GLSA notices there have been for a certain package and display them when you view it. Nothing really fancy.
Alright, so that’s about it. I know I’ve gotten some feature requests from people, and if you don’t see it listed here, then I’ve forgotten about it. Please do me a favor and ping me on IRC or email and let me know, and I’ll get it added to the list.
I still don’t have a timeline to get the old site back up and running. The good news is it is using a lot less CPU than I thought it’d be, so that expands my options for hosting. The coding for the original roadmap is coming along at a clipped pace. Everything I need to do has either already been done and just needs to be rewritten for the new backend, or is possible without too much problem. In other words, there are no major roadblocks. I still see it taking a few weeks, though.
I’ll keep you posted. 🙂