[arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)

[Pierre Schmitz]

Sure, I am not suggesting a rewrite; but when we do it a slightly
different approach could be taken.

Also to explain it further: Whether I or someone else is reviewing PRs
I suggest a way how we could manage such major refactorings. ATM the
diff between gbfs and our origin branch reads as:
 80 files changed, 1578 insertions(+), 3959 deletions(-)
It seems nobody really felt comfortable merging that; which is sad as
a lot of effort went into this.

Two possible strategies:
a) Gradual migration: It might not work out for some aspects, but
maybe there is way to prepare the current code to replace svn by git
and postpoing the actual switch to the very end. It's also a good
strategy to always have code merged that can and will be "deployed to
production". Of course this would mean that we have git and svn
running at the same time at some point.

b) Big bang: Refactor in a branch; keep tests working and plan a
migration in the end. Maybe have PRs from feature to a new develop
branch to make code reviews possible. In the end replace the system,
migrate all data and hope for the best.

On Mon, Jan 29, 2018 at 9:05 PM, Eli Schwartz via arch-dev-public
<arch-dev-public at archlinux.org> wrote:
> On 01/29/2018 02:19 PM, Pierre Schmitz wrote:
>> Hi all. I feel bad about this. I was not transparent at all about my
>> plans and got lost in a pile of projects which are only slowly
>> progressing. I started improving dbscripts to make it easier to work
>> with; which led to creating a Docker base image to be able to test the
>> latter. Most of my free time then went into a huge refactoring of
>> archlinux.de to finally extract and improve on the pkgstats backend.
>> Now I am drowning in hundreds of arch related emails and "things I
>> should do".
>
> No problem, life gets to all of us! Thanks for getting back to us about
> what happened so we we don't have lingering feelings of guilt like we
> stole it out from under you, though. :)
>
>> I would welcome help on dbscripts a lot. I had a look at those git
>> attempts in the past but in the end they were not easily mergable.
>> Maybe a few suggestions:
>> * Let's use github for Pull Requests
>
> I'm okay with that, TBH I don't think we got a lot of dbscripts email on
> [arch-projects] but I am okay with tracking patches from either location.
>
>> * Make sure PRs are small enough to be reviewable in let's say within an hour
>
> Well, I think patchsets however they come should probably aspire to this. :D
>
>> * New code needs to be tested (Travis build needs to pass)
>> * Code Coverage should be as close to 100% as possible and useful
>
> I will see what I can do, bats looks simpler than I thought at first anyway.
>
>> If we prefer a complete rewrite (e.g. when moving from Bash to e.g.
>> Go) where small pull requests are not possible and we need to start
>> from scratch, I would still strongly recommend my suggestions above;
>> esp. those about testing.
>
> I see no reason to suddenly rewrite everything in a new programming
> language, surely dbscripts isn't *that* bad! :D
>
> I'm not sure we should be replacing parts of our infra with something
> that isn't a scripted language, but that may be a personal opinion....
> Moreover, if the goal is to encourage contributions then bash is a
> pretty good language for that.
>
> --
> Eli Schwartz
> Bug Wrangler and Trusted User
>