Merge other Feedjack-Fork?
- Appended to comment:
fraggod added on 2011-08-10 04:37:10 UTC:
I see your point, an interesting concept to abuse.
Problem with my
"feedgroups: just grouping feeds at one site." == "separate site with all the feeds"
"all feeds at one site, but sometimes i just want to read a specific group" == "sites with some subset of feeds"
approach is that to make this useful you'll need a links between sites (like "this site has following subsites: ..."), plus a way to group these, maybe tag them, and make it all available in the templates, and I guess that'd be overloading and overcomplicating the concept too much.
Admittedly, I never seen much point in having "grand unified feed", since I tend to check produced aggregations by priority or time available, so I group feeds that way and check groups in order, but pushing this priority attribute to groups will allow to output a feeds, sorted by groups (i.e. by priority), combined with even simpliest client-side hiding of read entries, I think it's a great idea.
I'll look into git issue over the next few days, basically it worked but then I updated the system here and there, and without decent monitoring system I just failed to notice the problem.
Current version of web interface (cgit) seem to have some problem, spitting stuff like "[100159.066539] cgit.cgi general protection ip:7f0f3e8c958c sp:7fffebb16708 error:0 in libc-2.12.1.so[7f0f3e7c1000+15d000]" on all the repos I create via git fast-import, maybe I did something wrong there, although regular git cli doesn't seem to have any problems with it.
I haven't really touched the code since the initial merge (aside from a few bugfixes) I've done in an afternoon or two. Wanted to, but then other more "urgent" stuff piled on top and the rest isn't really hard to predict...
So, while I'd totally like to merge more stuff and improve on it here and there, realistically I think it's unlikely to happen in the nearest future, and you might be better off improving stuff on your own.
That said, I'll fix git export asap, although it shouldn't be too hard to pull the stuff out from fossil by yourself - whole scm is a single cross-platform binary, and there's little point in constant export unless there is constant stream of changes, which my repo, alas, lacks these days.