New dbscripts maintainer (aka: Making dbscripts great again!)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
Hi,

Once again, debug repos came up in IRC. AFAIK progress on this is
blocked by Pierre not responding/merging patches. gbs has implemented
quite a lot in dbscripts itself, but we still need someone to come up
with a migration plan, testing and deploying the whole thing.

Eli offered to take the lead on getting that done and also later
migrating us to git instead of svn. If there are no objections I'll help
where necessary and give him access to the dbscripts and devtools repos
in two weeks.

I'm also CC'ing Pierre and gbs so they can jump in if necessary.

Florian


signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
On 29.01.2018 16:57, Bruno Pagani wrote:
> Le 29/01/2018 à 16:51, Florian Pritz via arch-dev-public a écrit :
>> I'm also CC'ing Pierre and gbs so they can jump in if necessary.
>
> Did you forgot to add them or they were in CC/I/? ;)

They were, but it seems mailman removed it. Probably because they are
both subscribed to the list. Thanks for checking.

Florian


signature.asc (875 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
In reply to this post by arch dev mailing list
[2018-01-29 16:51:54 +0100] Florian Pritz via arch-dev-public:
> Eli offered to take the lead on getting that done and also later
> migrating us to git instead of svn. If there are no objections I'll help
> where necessary and give him access to the dbscripts and devtools repos
> in two weeks.

That sounds great!

--
Gaetan

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

Pierre Schmitz
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".

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
* Make sure PRs are small enough to be reviewable in let's say within an hour
* New code needs to be tested (Travis build needs to pass)
* Code Coverage should be as close to 100% as possible and useful

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.

Greetings,

Pierre

On Mon, Jan 29, 2018 at 7:29 PM, Gaetan Bisson via arch-dev-public
<[hidden email]> wrote:

> [2018-01-29 16:51:54 +0100] Florian Pritz via arch-dev-public:
>> Eli offered to take the lead on getting that done and also later
>> migrating us to git instead of svn. If there are no objections I'll help
>> where necessary and give him access to the dbscripts and devtools repos
>> in two weeks.
>
> That sounds great!
>
> --
> Gaetan
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
On 01/29/2018 03:27 PM, Pierre Schmitz wrote:
> 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.

I'd prefer this, especially as we had a general intention of making
dbscripts VCS-agnostic anyway.

What would be nice, is if we could get things to a state where modifying
a config.local variable and running anthraxx's migration script is all
it takes to start using git. Then in 20 years when we decide we want to
use the next great VCS it will be easier to switch...

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New dbscripts maintainer (aka: Making dbscripts great again!)

arch dev mailing list
In reply to this post by Pierre Schmitz
On Mon, Jan 29, 2018 at 08:19:50PM +0100, Pierre Schmitz wrote:
> 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
> * Make sure PRs are small enough to be reviewable in let's say within an hour
> * New code needs to be tested (Travis build needs to pass)
> * Code Coverage should be as close to 100% as possible and useful


I've given Eli write access on github now. Let's try to follow these
suggestions and get the patches merged.

Florian

signature.asc (849 bytes) Download Attachment