[arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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
[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
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 <arch-dev-public@archlinux.org> 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
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
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@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
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
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
participants (4)
-
Eli Schwartz
-
Florian Pritz
-
Gaetan Bisson
-
Pierre Schmitz