Well, on the devices I have which are constantly on Extras-devel, I've found the UI perfectly fine. I don't really have anything stand out in my mind as particularly bad/unintuitive about it. Well, that Automated Keyset Search or whatever - it's a bit unclear just from looking at it how it's supposed to work. But I suspect if I just started fiddling with it, I'd figure it out pretty quickly.

I have a couple of other ideas for how you can enable pushing keyset updates without having to update the entire app:

1. Separate it out into two packages, "pierogi" for the actual executable, conffiles, etc, and "pierogi-data" (nice, general naming that I see Debian packages use all the time) or "pierogi-keysets" or something more explicit like that, for the actual keyset data. Then pierogi can list pierogi-data in it's "Depends" field. That way, when you've got a keyset update, you can upload and promote it through independently of the code-base. Since keysets are probably a lot easier to verify as not-broken than a non-trivial program is, this allows you to decouple the promotion of keyset updates from the promotion of the program, while still keeping it within the packaging system.

2. You could have pierogi automatically check for keyset updates and download new keysets. The biggest advantage it has over the repos is that you can get keyset updates out even faster. The biggest (dis)advantage (depending on what aspect of this point you feel is more significant), this removes the "community-votes-on-it" check from the keyset data. The biggest technical disadvantage is that now you're maintaining it on some other server outside of the repos (which has two implications: 1, availability is now dependent on a third party besides community-maintained infrastructure; 2, it's outside the package management system, which means that if a good reason ever came up, I couldn't make a package depend on a specific version or later of your keyset files.)

[edit]Another advantage to point 1 is that it requires no additional complexity in the pierogi code: pierogi doesn't have to suddenly gain a whole slew of networking, version checking, downloading/unpacking/etc code, which number 2 would require. Admittedly, you could just shell script all of that, thereby offloading most of the complexity, but it's still more than nothing - I imagine the keysets are currently in their own separate files already, and not hard-coded into the code, hence my assumption that just having it as two separate packages would add no complexity. But if they are hard-coded into the binary right now, then I would argue it would be must better from a design perspective to split them off regardless of what you did with the packaging for the repos, so that complexity is justified and ought to be in there anyway.[/edit]

Well, I think the first path is more or less the correct one, but I wouldn't necessarily be so cautious/strict about what goes to testing. I think the idea is, you push things from -devel to testing as soon as you think it's ready for extras. Which to me would mean, as soon as I subjectively think it doesn't have any new bugs/problems, or that any problems it does have are outweighed by the improvements. But once I was fairly certain I didn't break anything with it, I'd go and push it down into testing.

For aircrack-ng, for example, I would usually capture some packets, maybe crack a single WEP network with it, but then I'd figure "well, it installs/uninstalls/reinstalls fine, and the likelihood of stuff having broken isn't too big since the code is mostly good, so I'll just push it into testing and other people who use it will yell at me or downvote it if there's a problem."

As a maintainer, I expect -devel to be my playground/scratch-space, -testing to be where versions I thought were good enough for general consumption to go, and extras to be where version "the public" considered worthy would go. I trust that if I put a flawed version into -testing, it will either get caught and stopped early on, or if a problem does get through, that the fix will likely be promoted through fairly quickly.

So in short, I think your extras-testing criteria needs to be that it's "nearly-perfect" - you just need to think it's "probably not more broken than it was".