Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-30 Thread Jeremy Stanley
On 2020-06-30 09:15:47 +0200 (+0200), Thomas Goirand wrote: [...] > If there's some nasty NPM job behind, then I probably will just > skip the dashboard, and expect deployment to get the dashboard not > from packages. What is included in the dashboard? Things like > https://zuul.openstack.org/ ?

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-30 Thread Thomas Goirand
On 6/30/20 12:41 AM, Jeremy Stanley wrote: > On 2020-06-29 23:55:49 +0200 (+0200), Thomas Goirand wrote: > [...] >> nodepool from OpenStack, > > Well, *formerly* from OpenStack, these days Nodepool is a component > of the Zuul project gating system, which is developed by an > independent

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Jeremy Stanley
On 2020-06-29 23:55:49 +0200 (+0200), Thomas Goirand wrote: [...] > nodepool from OpenStack, Well, *formerly* from OpenStack, these days Nodepool is a component of the Zuul project gating system, which is developed by an independent project/community (still represented by the OSF):

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 7:35 PM, Utkarsh Gupta wrote: >> Running the script shows that 279 reverse (build?) dependencies are >> affected by mock. This clearly isn't something one wants to run on a >> personal computer, and even less a test which one wants to run sequentially. > > Haha, right. > What we (me

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Utkarsh Gupta
Hello, On Mon, Jun 29, 2020 at 8:24 PM Thomas Goirand wrote: > Nice! Thanks a lot for the pointer. \o/ > I very much agree with you that the debate has to be emptied from > emotions if possible. My goal has never been to point finger at anyone, > but try to fix a reoccurring situation which I

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Sandro Tosi
> Running the script shows that 279 reverse (build?) dependencies are > affected by mock. This clearly isn't something one wants to run on a > personal computer, and even less a test which one wants to run sequentially. > > Has any thought went into having some kind of runners running on a cloud >

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 2:33 PM, Utkarsh Gupta wrote: > There exists such a thing which I use daily: ruby-team/meta[1]. > The meta/build script is (hopefully and exactly) what we need here! > > It checks all the reverse(-build)-dependencies and lets you know what's > going to break as soon as you dput. Hi

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Scott Kitterman
On Monday, June 29, 2020 7:53:46 AM EDT Thomas Goirand wrote: > On 6/29/20 12:58 PM, Scott Kitterman wrote: > > On June 29, 2020 10:12:49 AM UTC, Thomas Goirand wrote: > >> On 6/29/20 8:34 AM, Ondrej Novy wrote: > >>> nope, this is not true. Using the newest debhelper compat level is > >>>

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Scott Kitterman
On Monday, June 29, 2020 10:17:57 AM EDT Scott Talbert wrote: > On Mon, 29 Jun 2020, Scott Kitterman wrote: > >>> More over, mock debhelper was upgraded to 13, for no apparent > >> > >> reason > >> > >>> (yet another "cosmetic fix" that isn't helping?). I'd like to > >> > >> remind > >>

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Scott Talbert
On Mon, 29 Jun 2020, Scott Kitterman wrote: More over, mock debhelper was upgraded to 13, for no apparent reason (yet another "cosmetic fix" that isn't helping?). I'd like to remind everyone that, increasing debhelper compat version to a number that isn't in stable,

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Utkarsh Gupta
On Sun, Jun 28, 2020 at 11:29 PM Sandro Tosi wrote: > OS is *just* another software we package for > Debian; is it complex? sure, but it's not special, and it doesnt > warrant any special treatment. I am afraid when you say this. First of all, that's not completely true. But I don't want to go

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 12:58 PM, Scott Kitterman wrote: > On June 29, 2020 10:12:49 AM UTC, Thomas Goirand wrote: >> On 6/29/20 8:34 AM, Ondrej Novy wrote: >>> nope, this is not true. Using the newest debhelper compat level is >>> recommended, see man page. There is no reason to __not__ upgrade >>> debhelper

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Scott Kitterman
On June 29, 2020 10:12:49 AM UTC, Thomas Goirand wrote: >On 6/29/20 8:34 AM, Ondrej Novy wrote: ... >> More over, mock debhelper was upgraded to 13, for no apparent >reason >> (yet another "cosmetic fix" that isn't helping?). I'd like to >remind >> everyone that, increasing

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Thomas Goirand
On 6/29/20 8:34 AM, Ondrej Novy wrote: > Ondrej, you once cared for the OpenStack packages. Why are you now > completely careless? > > > because it's really hard to cooperate with you. I already tried to > explain it to you but you didn't listen. You're mixing 2 things: working on

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Ondrej Novy
Hi, ne 28. 6. 2020 v 16:48 odesílatel Thomas Goirand napsal: > Hi, > > Under a single Github account, the below packages are maintained: > - mock > - subunit > - testtools > - fixtures > - funcsigs (deprecated, py2 backport) > - testresources > - traceback2 > - testscenarios > - testrepository

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Thomas Goirand
On 6/28/20 7:59 PM, Sandro Tosi wrote: >> Is anyone from the team opposing to this? > > Yes, i'm against your proposal. > >> If so, please explain the >> drawbacks if the OpenStack team takes over. > > 1. you're personally attacking Ondrej, who is one of the very few > members of this team

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Scott Kitterman
On Sunday, June 28, 2020 1:59:08 PM EDT Sandro Tosi wrote: > 5. consolidating packages *into* the DPMT/PAPT gives a lot of > benefits, f.e. people basically got "free" handling of the py2removal > process; moving packages out is actually detrimental for the python > ecosystem (at least that's my

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Sandro Tosi
> Is anyone from the team opposing to this? Yes, i'm against your proposal. > If so, please explain the > drawbacks if the OpenStack team takes over. 1. you're personally attacking Ondrej, who is one of the very few members of this team doing team-wide work, and that should be enough to reject

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-28 Thread Jeremy Stanley
On 2020-06-28 16:48:02 +0200 (+0200), Thomas Goirand wrote: [...] > I don't want this to happen again. So I am hereby asking to take > over the maintenance of these packages which aren't in the > OpenStack team. They will be updated regularly, each 6 months, > with the rest of OpenStack, following