Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12684 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Maintaining all of the testing-cabal packages under the OpenStack team Sandro Tosi <morph@debian.org> - 2020-06-28 20:00 +0200
    Re: Maintaining all of the testing-cabal packages under the OpenStack team Scott Kitterman <debian@kitterman.com> - 2020-06-28 20:20 +0200
    Re: Maintaining all of the testing-cabal packages under the OpenStack team Utkarsh Gupta <utkarsh@debian.org> - 2020-06-29 14:40 +0200
      Re: Maintaining all of the testing-cabal packages under the OpenStack team Sandro Tosi <morph@debian.org> - 2020-06-29 18:30 +0200
      Re: Maintaining all of the testing-cabal packages under the OpenStack team Utkarsh Gupta <utkarsh@debian.org> - 2020-06-29 19:40 +0200
        Re: Maintaining all of the testing-cabal packages under the  OpenStack team Jeremy Stanley <fungi@yuggoth.org> - 2020-06-30 00:50 +0200
          Re: Maintaining all of the testing-cabal packages under the  OpenStack team Jeremy Stanley <fungi@yuggoth.org> - 2020-06-30 17:50 +0200

#12684 — 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 it
2. this is clearly an hostile take-over (even if you frame it as a
proposal), and that should be enough to reject it
3. you propose to only update those packages every 6 months, i dont
find it appropriate: 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.
4. you clearly want to have sole and absolute control of the packages
in the openstack-team, because what would happen if a os-team member
will upgrade one of those packages (in good faith) and things will
break? will they get another "well done! :( " email from you?
4.1. You wonder why Ondrey "stopped caring" about OS, if that's the
case, i could see why
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 opinion).

Thomas, this is not the first time your temperament and aggressive
behavior is causing some troubles, please reassess how you interact
and work with other fellow contributors.


--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [next] | [standalone]

#12685

[Multipart message — attachments visible in raw view] — view raw

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 opinion).

Definitely this.

Scott K

[toc] | [prev] | [next] | [standalone]

#12693

On Sun, Jun 28, 2020 at 11:29 PM Sandro Tosi <morph@debian.org> 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 there.

What I want to emphasis more on is:
It's okay if you don't want to treat packages in a "special" way,
that's totally fine!
But what's **not** fine is breaking something else whilst updating
something else.
That is just NOT...okay.

Sometimes it just happens (accidentally or whatever) but I think even then, the
person who does that should at least look up at the packages broken,
try to fix it,
and if it lies something outside their scope (because of time
constraints, etc), the
least they can do is report this to the respective maintainer(s) or at
least raise to
the list so that people who can, will help!

If everyone uploaded what they felt like without taking care of what's breaking,
the whole of Debian would just be chaos.

And I think, that's not the way it should be. At all.
And I completely agree with Thomas' statement when he says,
"No, this is not how Debian works, it never was, and hopefully, never will."

I love Ondrej and I love Thomas. And this mail has nothing to do with them.
Instead, this is a mail to everyone.
And while at it, I'd also request everyone to be a little empathetic.
I really hope that's not much to ask, is it!?


> It'd be nice if we had a framework to be able to rebuild all reverse
> build-dependency when we update a package. But currently, we don't have
> such CI. If one volunteers to write it, probably we can find some
> compute resources to make it happen. That's probably the way out, and
> IMO we should really all think about it.

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.


Best,
Utkarsh
---
[1]: https://salsa.debian.org/ruby-team/meta

[toc] | [prev] | [next] | [standalone]

#12701

> 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
> to run these tests, and maybe plug this into Salsa's CI to run it
> automatically?
>
> I'd very much would love to set this up, at least as a first
> experimentation on a bunch of package of the DPMT.

i sent this some time ago do d-devel

https://lists.debian.org/debian-devel/2020/03/msg00342.html

it didnt get much traction

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

[toc] | [prev] | [next] | [standalone]

#12702

Hello,

On Mon, Jun 29, 2020 at 8:24 PM Thomas Goirand <zigo@debian.org> 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 would like to avoid.

Definitely! Everyone would love to avoid that!

> 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 a couple others) do is run this build script on a
server (via screen) and call it a night :P
And we get the list of broken packages in the morning!

But of course, this is not a very "professional" way of doing it.

> Has any thought went into having some kind of runners running on a cloud
> to run these tests, and maybe plug this into Salsa's CI to run it
> automatically?

This seems to be a nice idea!
I am not sure if someone had the time or energy to do this, but this
is something we'd definitely love \o/

> I'd very much would love to set this up, at least as a first
> experimentation on a bunch of package of the DPMT.

Me too!


Best,
Utkarsh

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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://zuul-ci.org/
    https://opendev.org/zuul/nodepool/

You could probably run a Nodepool launcher daemon stand-alone
(without a Zuul scheduler), but it's going to expect to be able to
service node requests queued in a running Apache Zookeeper instance
and usually the easiest way to generate those is with Zuul's
scheduler. You might be better off just trying to run Nodepool along
with Zuul, maybe even set up a GitLab connection to Salsa:

    https://zuul-ci.org/docs/zuul/reference/drivers/gitlab.html

> and use instances donated by generous cloud providers (that's not
> hard to find, really, I'm convinced that all the providers that
> are donating to the OpenStack are likely to also donate compute
> time to Debian).
[...]

They probably would, I've approached some of them in the past when
it sounded like the Salsa admins were willing to entertain other
backend storage options than GCS for GitLab CI/CD artifacts. One of
those resource donors (VEXXHOST) also has a Managed Zuul offering of
their own, which they might be willing to hook you up with instead
if you decide packaging all of Zuul is daunting (it looks like both
you and hashar from WMF started work on that at various times in
https://bugs.debian.org/705844 but more recently there are some
JavaScript deps for its Web dashboard which could get gnarly to
unwind in a Debian context).
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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

That's a white-labeled tenant of https://zuul.opendev.org/ but yes,
basically an interface for querying the REST API for in-progress
activity, configuration errors, build results, log browsing, config
exploration and so on. The result URLs it posts on tested changes
and pull/merge requests are also normally to a build result detail
page provided by the dashboard, thought you should be able to
configure it to link directly to the job logs instead.
-- 
Jeremy Stanley

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web