search

mk-fg / feedjack

Feedparser-based feed aggregation django app
BSD 3-Clause "New" or "Revised" License
8 stars 7 forks source link

feedjack_clean script to selectively purge content from the database #2

Closed lockhart closed 11 years ago

lockhart commented 11 years ago

This extra command line utility was in the previous pull request but not sure if this was rejected or just missed. I find this very useful to keep the database volume under control.

mk-fg commented 11 years ago

Hm, previous pull (#1) seem to be from @rolo, not sure which PR you mean...

Thanks. It's very useful indeed, had to purge old posts using ./manage.py shell a few times in the past myself.

lockhart commented 11 years ago

Thanks. I am new with github features and apparently did not manage to register the pull request earlier but was notified on the @rolo merge and mistook that for the one I had intended. Speaking of github, is there a mechanism for discussing features or merges or ?? Without an outstanding pull request is there a way to communicate? @allo- is coordinating with @cato- and you mentioned possibly merging back with their fork(s) but not sure the best way to get this worked out.

mk-fg commented 11 years ago

I think entry in /issues is as close to a message thread as one can get on github, lots of examples of these opened just as RFC in other projects.

But not sure if there's much to discuss wrt that particular fork - it's there in the open, one can go ahead and pick whatever is useful, then open a PR here. Guess there can be a discussion of whether a particular implementation of something there is right way to go about it or if some feature is worth trade-offs before merging it, but these seem to be a perfectly legitimate "issue" tickets, each of which can be upgraded to PR if necessary, it seem to be their intended purpose.

Wrt the the actual merge into one fork - maybe it should rather be merge of all the stuff into @tabo's original repo and push of whole merged thing to PyPI? People who benefit most from such merge seem to be users, so it should be non-private fork and a visible thing. Asking tabo to maintain all these (and future) changes doesn't seem to be a good idea though - there's a lot of these, out-of-style or even breaking some stuff that was in original version (e.g. translations).

Since there seem to be some interest in the thing, guess I'll ask tabo about commit access or something, thanks for the idea.

lockhart commented 11 years ago

OK, great. I have enabled "issues" on my fork but of course issues should probably be visible as far upstream as possible. Do you want to enable issues (it does not seem visible to me, assuming that it would be if enabled!) for your fork to represent at least this side of the code?

mk-fg commented 11 years ago

Oh, right, I didn't realize these were disabled here. Fixed ;)