Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 Description: OpenPGP digital signature
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
[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 Description: PGP signature
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 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
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 Description: OpenPGP digital signature
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 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 >
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 Description: OpenPGP digital signature
Re: [arch-dev-public] New dbscripts maintainer (aka: Making dbscripts great again!)
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 Description: PGP signature
