Re: Bits from the Release Team: ride like the wind, Bullseye!

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Lisandro Damián Nicanor Pérez Meyer-2
Hi Paul!

El sáb., 20 jul. 2019 16:42, Paul Gevers <[hidden email]> escribió:
Hi Lisandro,

On 07-07-2019 16:16, Lisandro Damián Nicanor Pérez Meyer wrote:
>> All autopkgtest failures considered RC for bullseye
>> ===================================================
>>
>> From now on, all autopkgtest failures will be considered release-critical for
>> bullseye. So if your package has failing autopkgtests, now is a good time to
>> start looking for a fix
>
> Now this raises some questions for me. Now I maintain a (huge) library
> (hello Qt!). I do an unstable upload and package A starts failing it's
> autopkgtests. In this case:
>
> - How does this failure affects the uploaded library (imagine we have
> a transition, as it will always be Qt's case due to private headers).

By default, the migration to testing will be blocked, exactly like we
have been doing the last half year.

> - What's expected from the maintainers of the library?

It is expected that you communicate (e.g. via a bug report filed against
both packages like I have been doing for over a year now, see examples
on [1]) with the maintainers of the package to see why the test starts
failing. Together, you should be able to work out which package needs to
adapt. Either the autopkgtest found a real issue in your library which
you need to fix, or the package needs to adapt to the new status of your
library, either by fixing the package itself, or its autopkgtest. The
migration of your library will be stalled to give the package time to be
adapted. Of course that needs to happen within a reasonable amount of
time, so if it takes to long, or you and the maintainers of the package
can't agree on who should adapt what, contact the release team.

Just to be clear, in case you got confused by it, if the package
*already* fails in testing, it isn't a concern for packages that just
trigger that autopkgtest, only for the package with the failing autopkgtest.

I wonder if you were thinking of something else? If so, please elaborate.


First of all thanks for replying and sorry for not doing so sooner, I clearly missed it.

No, what I have been perceiving (and pretty please note that this is my personal "feeling") is that maintainers, specially library maintainers, have even more and more "stuff to care for". Also please don't get me wrong, I do understand that this is indeed with the idea of improving Debian. But the amount of work needed to maintain the same stuff I have been working with this last years take more and more time, to the point that sometimes I feel it gets into pair with a payed job.

Once again please remember it's my personal point of view, and if something above doesn't seems quite right it might be my not so good English ;-)

Again, thanks a lot for replying.

Cheers, Lisandro.
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Ian Jackson-2
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"):
> No, what I have been perceiving (and pretty please note that this is my
> personal "feeling") is that maintainers, specially library maintainers, have
> even more and more "stuff to care for".

I can see why you feel that way.

I think maybe we need to make it easier for the maintainer of a
widely-used library to push some of this out to depending packages.

(And I speak as a maintainer of a leaf package with a thorough
autopkgtest suite which often blocks the migration of my
dependencies.)

Lisandro, would it meet your needs if you had free licence to file RC
bugs against all packages which were blocking your migration, before
you had done the investigation yourself ?

I think the effect would be that a maintainer of a dependent package
would have to engage with the situation and if they did nothing for
long enough, the autoremoval would kick in.  Then your library would
be able to migrate.

This seems similar to the approach we take with (say) new compilers,
which trigger FTBFS bugs in depending packages.  The compiler
maintainers do not investigate the issues - they file bugs, which
eventually become RC, and then the depending packages must either be
fixed our autoremoved.

(Of course some library maintainers would prefer to do some
investigation first.)

Ian.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Paul Gevers-4
Hi,

On 07-08-2019 16:57, Ian Jackson wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"):
>> No, what I have been perceiving (and pretty please note that this is my
>> personal "feeling") is that maintainers, specially library maintainers, have
>> even more and more "stuff to care for".
>
> I can see why you feel that way.
>
> I think maybe we need to make it easier for the maintainer of a
> widely-used library to push some of this out to depending packages.

<RT hat off>I agree with this.</RT hat off>

> (And I speak as a maintainer of a leaf package with a thorough
> autopkgtest suite which often blocks the migration of my
> dependencies.)
>
> Lisandro, would it meet your needs if you had free licence to file RC
> bugs against all packages which were blocking your migration, before
> you had done the investigation yourself ?
>
> I think the effect would be that a maintainer of a dependent package
> would have to engage with the situation and if they did nothing for
> long enough, the autoremoval would kick in.  Then your library would
> be able to migrate.
Obviously this only works if the reverse dependency isn't also a key
package. So, in any case, please contact the release team early if you
experience problems, we can help.

> This seems similar to the approach we take with (say) new compilers,
> which trigger FTBFS bugs in depending packages.  The compiler
> maintainers do not investigate the issues - they file bugs, which
> eventually become RC, and then the depending packages must either be
> fixed our autoremoved.

I think we should also try to improve the visibility towards reverse
dependencies that their autopkgtest is blocking other packages. I would
love tracker (and the old pts) to show this on their page. (Working on
such a patch is on my TODO list, except not at the top).

> (Of course some library maintainers would prefer to do some
> investigation first.)

I can already trigger all the autopkgtests in unstable for packages that
are in experimental, so if you interested in this, please contact me.
This would enable library maintainers to at least have an overview of
what would happen. I could even activate this by default.

We also have an Outreachy intern working on a self-service corner on
ci.d.n, so that more testing can be done if people want it.

Paul


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Pirate Praveen-3


On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers <[hidden email]> wrote:
>I can already trigger all the autopkgtests in unstable for packages
>that
>are in experimental, so if you interested in this, please contact me.
>This would enable library maintainers to at least have an overview of
>what would happen. I could even activate this by default.

Yes, please do this by default so we can have a better picture of the transition. Though for many libraries we also need to rebuild reverse build dependencies. I have been using salsa.debian.org/ruby-team/meta/build for this. Right now I'm interested in libgit2, grpc and protobuf transitions.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Lisandro Damián Nicanor Pérez Meyer-2
In reply to this post by Paul Gevers-4
First of all sorry for the late late reply, I was hoping to find time to
reply to this sooner :-/

On 19/08/08 09:46, Paul Gevers wrote:

> Hi,
>
> On 07-08-2019 16:57, Ian Jackson wrote:
> > Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"):
> >> No, what I have been perceiving (and pretty please note that this is my
> >> personal "feeling") is that maintainers, specially library maintainers, have
> >> even more and more "stuff to care for".
> >
> > I can see why you feel that way.
> >
> > I think maybe we need to make it easier for the maintainer of a
> > widely-used library to push some of this out to depending packages.
>
> <RT hat off>I agree with this.</RT hat off>
>
> > (And I speak as a maintainer of a leaf package with a thorough
> > autopkgtest suite which often blocks the migration of my
> > dependencies.)
> >
> > Lisandro, would it meet your needs if you had free licence to file RC
> > bugs against all packages which were blocking your migration, before
> > you had done the investigation yourself ?

It might help, but I'm not certain. The bug may or may not be in the library on
in the leaf packages. Filing bugs may start a ping pong of "it's your fault"
bugs between maintainers.

My personal point of view (and because of this it might be biased) is that the
maintainers of the packages that ship autopkgtest should be the reponsibles for
any breackage it might occur on them because:

- They added autopkgtests, so they are showing an intent on reviewing them when
  they fail.
- They will certainly know their packages better than the library maintainer,
  and thus they have more chances to get the root of the issue sooner. Of course
  that might mean finding a bug in the library, but that's just ok.

Note that the principle I'm basing myself is "we can't force a maintainer to do
stuff". So whoever adds autopkgtests to their packages must be the one who
starts the debugging when something fails, not the other side.

Pretty please don't get me wrong: in an ideal world everyone should start
digging the issue. But Debian being volunteer-based simply can't get to that
point, except by forcing maintainers to do even more stuff.

> > I think the effect would be that a maintainer of a dependent package
> > would have to engage with the situation and if they did nothing for
> > long enough, the autoremoval would kick in.  Then your library would
> > be able to migrate.
>
> Obviously this only works if the reverse dependency isn't also a key
> package. So, in any case, please contact the release team early if you
> experience problems, we can help.
>
> > This seems similar to the approach we take with (say) new compilers,
> > which trigger FTBFS bugs in depending packages.  The compiler
> > maintainers do not investigate the issues - they file bugs, which
> > eventually become RC, and then the depending packages must either be
> > fixed our autoremoved.
>
> I think we should also try to improve the visibility towards reverse
> dependencies that their autopkgtest is blocking other packages. I would
> love tracker (and the old pts) to show this on their page. (Working on
> such a patch is on my TODO list, except not at the top).
>
> > (Of course some library maintainers would prefer to do some
> > investigation first.)
>
> I can already trigger all the autopkgtests in unstable for packages that
> are in experimental, so if you interested in this, please contact me.

**Yes please**. This will certainly help *a lot* specially for us that we
prepare new releases on experimental.

> This would enable library maintainers to at least have an overview of
> what would happen. I could even activate this by default.
>
> We also have an Outreachy intern working on a self-service corner on
> ci.d.n, so that more testing can be done if people want it.

Perhaps derailing the thread a little, but other "pretty nice stuff to have" as
a Debian service would be something that allows rebuilds of rdeps of stuff in
experimental. It can be on just one powerful arch (amd64 possibly?). In this way
we libs maintainers would not need to use or personal resources in rebuilding
stuff. Says someone from Argentina who has a 10+years old machine as main
machine and a quite devaluated (and devaluating) currency. I think Ubuntu has
something along this idea.

But yes, once again I can't nor will force anyone into doing it :-)

Cheers, Lisandro.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Ian Jackson-2
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: ride like the wind, Bullseye!"):

> My personal point of view (and because of this it might be biased)
> is that the maintainers of the packages that ship autopkgtest should
> be the reponsibles for any breackage it might occur on them because:
>
> - They added autopkgtests, so they are showing an intent on
>   reviewing them when they fail.
> - They will certainly know their packages better than the library
>   maintainer, and thus they have more chances to get the root of the
>   issue sooner. Of course that might mean finding a bug in the
>   library, but that's just ok.

In the general case the proper investigation of a bug might need
involvement from both people, collaboratively.  That involves a kind
of ping pong on a technical level.

> On 19/08/08 09:46, Paul Gevers wrote:
> > I think we should also try to improve the visibility towards reverse
> > dependencies that their autopkgtest is blocking other packages. I would
> > love tracker (and the old pts) to show this on their page. (Working on
> > such a patch is on my TODO list, except not at the top).

I already made grep-excuses print this information.  It has been very
helpful to me.  Maybe we should make --autopkgtests the default ?

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Mattia Rizzolo-5
On Sun, Aug 18, 2019 at 08:54:21AM +0100, Ian Jackson wrote:
> > On 19/08/08 09:46, Paul Gevers wrote:
> > > I think we should also try to improve the visibility towards reverse
> > > dependencies that their autopkgtest is blocking other packages. I would
> > > love tracker (and the old pts) to show this on their page. (Working on
> > > such a patch is on my TODO list, except not at the top).
>
> I already made grep-excuses print this information.  It has been very
> helpful to me.  Maybe we should make --autopkgtests the default ?

I think no: --autopkgtests requires quite a bit more computation and
connecting to udd and whatnot, I don't think that should be the default.
Especially because udd-mirror is starting to be under-dimensioned so
it's sometimes quite slow to serve responses (like in the times when its
importing a new dump).

--
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Paul Gevers-4
In reply to this post by Lisandro Damián Nicanor Pérez Meyer-2
Hi,

On 18-08-2019 04:46, Lisandro Damián Nicanor Pérez Meyer wrote:
>> I can already trigger all the autopkgtests in unstable for packages that
>> are in experimental, so if you interested in this, please contact me.
>
> **Yes please**. This will certainly help *a lot* specially for us that we
> prepare new releases on experimental.

Soon. Figuring out some details on our side.

> Perhaps derailing the thread a little, but other "pretty nice stuff to have" as
> a Debian service would be something that allows rebuilds of rdeps of stuff in
> experimental.

I can think of two existing services, albeit both need a bit of
scripting on your side:
1) porterboxes (see e.g.
   https://lists.debian.org/msgid-search/20190614222919.GC24581@...)
2) http://debomatic-amd64.debian.net/ (and other archs).

> But yes, once again I can't nor will force anyone into doing it :-)

Nor do you need to in my opinion. Yes, running on your own hardware is a
pity.

Paul


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Paul Gevers-4
In reply to this post by Pirate Praveen-3
Hi Pirate, and other interested parties,

On 09-08-2019 08:22, Pirate Praveen wrote:
> On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers <[hidden email]> wrote:
>> I can already trigger all the autopkgtests in unstable for packages
>> that
>> are in experimental, so if you interested in this, please contact me.
>> This would enable library maintainers to at least have an overview of
>> what would happen. I could even activate this by default.
>
> Yes, please do this by default so we can have a better picture of the transition.

It's not running 100% automatically and it has a bit (600 tests) of
backlog, but it's here already:
https://release.debian.org/britney/pseudo-excuses-experimental.html

I'll cron it probably tomorrow evening.

Paul


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bits from the Release Team: ride like the wind, Bullseye!

Pirate Praveen-3


On 2019, സെപ്റ്റംബർ 2 1:26:51 AM IST, Paul Gevers <[hidden email]> wrote:

>Hi Pirate, and other interested parties,
>
>On 09-08-2019 08:22, Pirate Praveen wrote:
>> On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers <[hidden email]>
>wrote:
>>> I can already trigger all the autopkgtests in unstable for packages
>>> that
>>> are in experimental, so if you interested in this, please contact
>me.
>>> This would enable library maintainers to at least have an overview
>of
>>> what would happen. I could even activate this by default.
>>
>> Yes, please do this by default so we can have a better picture of the
>transition.
>
>It's not running 100% automatically and it has a bit (600 tests) of
>backlog, but it's here already:
>https://release.debian.org/britney/pseudo-excuses-experimental.html
>
>I'll cron it probably tomorrow evening.
>
>Paul

Thanks a lot, it is really helpful for transitions. Now I can see a list of packages blocking gitlab upload to unstable in one place.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

12