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

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 cont

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

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]

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 > p

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

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

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

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 hav

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

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/ ? T

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

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 project/c

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

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): https://zu

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

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 and

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

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 w

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

> 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

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 Utk

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

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 > >>> recomme

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

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

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, without

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

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 th

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

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

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 debhelpe

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

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 OpenSt

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

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

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 doing

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

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 op

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

> 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 i

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

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

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, and