[libre-riscv-dev] Introduction

[Cole Poirier]

On Jun 16 2020, at 6:13 am, Luke Kenneth Casson Leighton <lkcl at lkcl.net> wrote:

> the unix philosophy serves us extremely well: each tool shall do one
> thing and do it well.
> 
> gitlab fundamentally violates that.

Indeed. My application will be specific to our needs with regard to
organization and planning, without *any* extraneous things like managing
CI tests/builds/deployments.
 
> this is a perspective that can only really be fully appreciated when
> you have tried to do simple web development tasks that pull in 250
> megabytes of dependencies.

This is the reason I will be writing the application in Elm, all
dependencies are *compiled* into the application at *compile* time, the
resulting transpiled-to-js compressed binary is pretty tiny compared to
most javascript frameworks, or vanilla js applications that have
comprable functionality. But comes with the added benefit of
guaranteeing there will be *zero* runtime errors.
 
>> > yes it does.  the hassle associated with it unfortunately has
>> alreadyeliminated it from consideration.
>> 
>> Isn't it time to reevaluate if people are planning to implement
>> kanban boards and other things on top of the bugzilla REST API?
> 
> there is existing kanban board code.   we do not have to write one at all
> https://github.com/leif81/bzkanban
> 
> however Cole feels inclined to write something and i am not going to
> say "no you can't do that".

I will be effectively 'cloning' various different existing js projects
functionality, but while complex GUI apps are a very significant
undertaking in js, in Elm, a language built and designed from the ground
up to build high-performance single page web apps, cloning the
functionality of 1,000s of lines of javascript is a vastly simpler
though non-trivial undertaking.

> my brother dan has a business need which happens to match precisely
> with what we also need.
> 
> therefore we are not paying for it.
> 
> in addition it is a *focussed* and incremental enhancement, where we
> get the opportunity to input and decide what *we* want.
> 
> not what gitlab says we need.

Yes, I will implement only what we need from existing projects not take
all of the extraneous 'features' that various people have added over the
years. It should load very quickly and perform well even on low-bandwith
connections and low-spec devices. I am building the foundation of this
single-page web-app for Dan, and it will serve a dual purpose being the
foundation of our bug tracker's *additional* not replacement buzilla
frontend. But, as I have to work on bug/budget/time/etc. tracking
functionality specific to our projects needs, *some* money will be
needed for that.

Cole