| Summary: | bugzilla to be made available "offline" | ||
|---|---|---|---|
| Product: | Libre-SOC Website | Reporter: | Luke Kenneth Casson Leighton <lkcl> |
| Component: | website | Assignee: | Luke Kenneth Casson Leighton <lkcl> |
| Status: | DEFERRED --- | ||
| Severity: | enhancement | CC: | colepoirier, libre-soc-bugs, programmerjake |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| NLnet milestone: | --- | total budget (EUR) for completion of task and all subtasks: | 0 |
| budget (EUR) for this task, excluding subtasks' budget: | 0 | parent task for budget allocation: | |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: | ||
|
Description
Luke Kenneth Casson Leighton
2020-04-14 12:48:21 BST
was going to half jokingly suggest the impractical (and probably insecure) measure of putting the bugzilla installation in a public git repo -- bugs-everywhere looks much better, though I'd be concerned that we need a working, secure, public https interface for those who don't want to install bugs-everywhere locally and figure out how to use it. I know bugs-everywhere has a interactive web interface, I just don't know if it properly supports adding new users, authentication, etc. another option is fossil, which is a distributed version control system with a wiki and bug tracker: https://www.fossil-scm.org/home/doc/trunk/www/index.wiki (In reply to Jacob Lifshay from comment #1) > was going to half jokingly suggest the impractical (and probably insecure) > measure of putting the bugzilla installation in a public git repo -- sigh it'd involve dumping - then purging - parts of the bugzilla postgresql dump. bleh :) > bugs-everywhere looks much better, though I'd be concerned that we need a > working, secure, public https interface for those who don't want to install > bugs-everywhere locally and figure out how to use it. i'd want it anyway. > I know bugs-everywhere has a interactive web interface, yes. it's... "functional". > I just don't know if it properly supports > adding new users, authentication, etc. wark-wark :) not at all. i believe it's there for "convenience", for when you're running locally, and want to browse bugs, comment on them etc. locally then "git push" out to merge with other users. https://github.com/cherrypy/tools/blob/master/AuthenticationAndAccessRestrictions or this https://github.com/cherrypy/tools/blob/master/CASAuthentication funfunfun... sigh i kinda promised myself i wouldn't mess about with web frameworks any more :) however if my arm was sufficiently twisted i could likely throw something together that's suitable for public use, maybe even (gosh) using the bugzilla postgres user/pass to do it (!) hm i wonder if we can justify putting in an NLNet Grant request specifically for things like this, on the basis that, really, we do need full independence. we could then find - and pay - someone to do these kinds of things. (In reply to Jacob Lifshay from comment #2) > another option is fossil, which is a distributed version control system with > a wiki and bug tracker: > https://www.fossil-scm.org/home/doc/trunk/www/index.wiki sigh i'd really like it... if they hadn't decided to reinvent git. UNIX philosophy: do one thing, and do it well. the majority of other "project management" systems all allow alternative revision control to be used. an all-or-nothing approach does not inspire confidence. I spoke to Luke about this by happenstance on Sunday, he says that we should mirgate to Fossil-scm after the Oct 2020 tapeout. Deferring until after then. Michiel mentioned a protocol for a decentralized github-like protocol, allowing pull requests, issues, etc. Seems really interesting and worth investigating! https://notabug.org/peers/forgefed It allows users of any ForgeFed-compliant service to interact with other ForgeFed-compliant forge services, without being a registered user of that foreign service, just as if they were. In this way, users that choose to self-host have the additional benefit/responsibility of fully controlling of their own authentication/identityand their own data. briiilliant. at last. it would mean that anyone could submit a bugreport on github... *without* being forced to choose between "terms and conditions that they do not agree with" and "being entirely excluded from the community". |