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

2020-08-12 Thread Jean-Philippe MENGUAL
Hi, Interesting discussion folks, thanks. We're a little concerned that some of the messages may be perceived as not very respectful. You know, and probably are yourself affected, how it is hard to find new contributions in Debian and how it is important to have welcoming messages for new

Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-08 Thread Ondrej Novy
Hi, st 8. 7. 2020 v 12:14 odesílatel Thomas Goirand napsal: > There would be no point doing that, as all what pybuild would be doing > (ie: setup.py install and unit testing), I'd be overriding it. it's doing much more, but nevermind. > The other > (IMO preferred) way would be to contribute

Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-08 Thread Thomas Goirand
On 7/7/20 8:20 AM, Ondrej Novy wrote: > Hi, > > po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand > napsal: > > This isn't about hating or loving pybuild. This is all about being able > to control how this set of packages are build globally (the whole set of >

Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-07 Thread Ondrej Novy
Hi, po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand napsal: > This isn't about hating or loving pybuild. This is all about being able > to control how this set of packages are build globally (the whole set of > packages. so you could wrap these global things around pybuild, right? -- Best

Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]

2020-07-06 Thread Thomas Goirand
On 6/29/20 8:34 AM, Ondrej Novy wrote: > for my packages (i'm uploader): no, sorry. > > Reasons: > 1. I hate openstack-pkg-tools > 2. I like pybuild > 3. you hate pybuild and don't want to use it I thought about this for a long time, thinking if I should leave it unanswered or not. Finally, I

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

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

2020-06-28 Thread Thomas Goirand
Hi, Under a single Github account, the below packages are maintained: - mock - subunit - testtools - fixtures - funcsigs (deprecated, py2 backport) - testresources - traceback2 - testscenarios - testrepository - extras - linecache2 Currently, these packages are maintained by a variety of DDs,