Bug 285 - bugzilla to be made available "offline"
Summary: bugzilla to be made available "offline"
Status: DEFERRED
Alias: None
Product: Libre-SOC Website
Classification: Unclassified
Component: website (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks:
 
Reported: 2020-04-14 12:48 BST by Luke Kenneth Casson Leighton
Modified: 2020-09-02 18:26 BST (History)
3 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2020-04-14 12:48:21 BST
one of the important aspects of this project is it being possible to
replicate (for both offline real-time collaboration as well as legacy
archiving purposes) all resources.

bugzilla is one major piece of critical functionality that is also a
critical online resource.

about the only offline bugtracker that exists (and is any good) is
bugseverywhere.

that's interesting.
https://github.com/kalkin/be/blob/master/interfaces/email/interactive/be-handle-mail
Comment 1 Jacob Lifshay 2020-04-14 19:31:35 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.
Comment 2 Jacob Lifshay 2020-04-14 19:39:06 BST
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
Comment 3 Luke Kenneth Casson Leighton 2020-04-14 19:55:41 BST
(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.
Comment 4 Luke Kenneth Casson Leighton 2020-04-14 19:57:53 BST
(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.
Comment 5 Cole Poirier 2020-07-29 18:16:46 BST
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.
Comment 6 Jacob Lifshay 2020-09-02 17:52:30 BST
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
Comment 7 Luke Kenneth Casson Leighton 2020-09-02 18:26:51 BST
 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".