stabilizing libraries without testing reverse deps

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

stabilizing libraries without testing reverse deps

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It seems this happens more frequently these days, so I'd like to
remind people to check stable reverse deps before stabilizing a
library, especially when this is a non-maintainer stablereq.

Arch teams do not test them, so this is the business of the maintainer
or the dev who requested stabilization.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSJ5vAAoJEFpvPKfnPDWz9IAH/iFs7a87ylffzSBALk7FqmPw
voO1ubXaneNsjAGErZpj2XZlmZHuWHGrbPbvJllHKoKTWcXV1hUwYMYgUWwEF8Th
Ypco+MM/kAlcaB8vPVOjV+k3h3ogqcz7xUhkl9qShMgyKJrLS4gwlXavEpFQi0Mq
u/uqIwW2XN8tfrPCbB/FG4A6GqggIDb6ce9UCCjyYuqF3IUOKlj2LMz1SMBI7/ZQ
fVLrk9DqYzgns5Q0cQmCN+Fk+/2ypBdhybLNCpUD0HfhP8U05S5Cp1VEN9XOczDs
EAM/3pXRG6rZZspQmFIPjiTiQMFvxlF1kexpp1QQ/mqiWfRbjU4j7hHkc4//npE=
=w1hs
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Paweł Hajdan, Jr.
On 9/29/13 2:41 PM, hasufell wrote:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.

+1 to the reminder. It would be great to hear about specific examples of
problems happening more frequently recently. FWIW I didn't notice such
tendency, but that doesn't mean it's not happening.

> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

This is new to me.

Do you have anything official to point to so that you could back your claim?

See e.g.
<http://www.gentoo.org/proj/en/base/x86/arch-testers-faq.xml#steptest>:
"If the package is a library, emerge a couple of packages that use the
library to ensure they still work with the new version (best option: all
that depend on it and have a stable version)."

I also created a tool
(<http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=blob;f=reverse-dependencies.py;hb=HEAD>)
to assist arch teams in testing reverse dependencies.

As far as I know the person opening the bug does not guarantee anything.
Furthermore, the bugs I've filed using an automated tool explicitly ask
for maintainer's opinion before adding arches. They are only filed for
packages with no open bugs by the way. The person stabilizing the
package is ultimately responsible for breakages - otherwise why would we
have dedicated arch teams instead of letting anyone stabilize anything?

Paweł


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

Re: stabilizing libraries without testing reverse deps

Thomas Kahle
In reply to this post by hasufell
On 09/29/2013 11:41 PM, hasufell wrote:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.
>
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

Huh.  This must be new.  When I was still arch-testing, reverse deps
were checked.  app-portage/tatt (which is sort of maintainer-needed now)
has support for these tests too.

Cheers,
Thomas

--
Thomas Kahle


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

Re: stabilizing libraries without testing reverse deps

Andreas K. Huettel
In reply to this post by hasufell
Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
> It seems this happens more frequently these days, so I'd like to
> remind people to check stable reverse deps before stabilizing a
> library, especially when this is a non-maintainer stablereq.
>
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.

Arch testing includes testing of reverse deps.
If that's not the case, arch teams are not doing their job.

--

Andreas K. Huettel
Gentoo Linux developer
[hidden email]
http://www.akhuettel.de/


Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2013 12:54 AM, Andreas K. Huettel wrote:

> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
>> It seems this happens more frequently these days, so I'd like to
>> remind people to check stable reverse deps before stabilizing a
>> library, especially when this is a non-maintainer stablereq.
>>
>> Arch teams do not test them, so this is the business of the
>> maintainer or the dev who requested stabilization.
>
> Arch testing includes testing of reverse deps. If that's not the
> case, arch teams are not doing their job.
>

I'd have to search the irc logs, but afair I was told so by ago.

CCing him if I am wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSMJoAAoJEFpvPKfnPDWzKM0IAJE9RHUsSJKS9owZbuAdfvPh
3SSQDmXOP3WqG71Q0tLh0kYLH5IkSBktqypEgIBTyXbEiak8BH9tyR9xCSi6sEtb
toId4i9xCPZuHc5nLl6Yllc4uHQpkHziRGChESxWrGUv/+BVfrs9DhYA17yy3JYc
R1QGANf82v4hH85zsN9ITbJK07YkEzOsdBTbKZpxMeku6+X70KWMe51TImXDhOup
fVNTL5uss5BhHpbhVB4PInlTpSTBGUVbiNQRmdmxs+oj/IKfOQZZaWa4ax1d7gmI
hDunq5ZjsetaU3o7bDLzantSyLEX5fMYbOrZA/HTAKSX6jLDykmLRkrov39/E8M=
=RK65
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Rich Freeman
On Sun, Sep 29, 2013 at 8:14 PM, hasufell <[hidden email]> wrote:

> On 09/30/2013 12:54 AM, Andreas K. Huettel wrote:
>> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
>>> It seems this happens more frequently these days, so I'd like to
>>> remind people to check stable reverse deps before stabilizing a
>>> library, especially when this is a non-maintainer stablereq.
>>>
>>> Arch teams do not test them, so this is the business of the
>>> maintainer or the dev who requested stabilization.
>>
>> Arch testing includes testing of reverse deps. If that's not the
>> case, arch teams are not doing their job.
>>
>
> I'd have to search the irc logs, but afair I was told so by ago.
>
> CCing him if I am wrong.

If you aren't wrong, that might be why Ago is about the only one
stabilizing libraries...  :)

It probably makes sense for arch teams to test a few reverse
dependencies as the FAQ suggests.  If we want them all tested, then it
would make a lot more sense to have a tinderbox or other automated
testing tools of some sort.  Even then, we won't get much more than
compile testing, or whatever test suites the packages happen to come
with.

I haven't really seen any sign of widespread breakage though.  I'm
sure some issues slip through, but short of having automated testing I
doubt we'll ever do better than that.

Rich

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Paweł Hajdan, Jr.
On 9/29/13 7:41 PM, Rich Freeman wrote:
> Even then, we won't get much more than compile testing, or whatever
> test suites the packages happen to come with.

That's right.

I think we can rely on the time packages spend in ~arch to catch the
issues that wouldn't come up with compile and test phases.

Also, when stable is not far behind testing, the testing that ~arch
packages get is more applicable to stable (because there are less
differences). This is one of the main reason for my push to stabilize
more packages (always with proper testing), and I've also seen bugs
being fixed in ~arch but the fixes are not always pushed to stable
(which can be addressed by stabilizing more packages in general).

Paweł


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

Re: stabilizing libraries without testing reverse deps

pva0xd
In reply to this post by Andreas K. Huettel
В Пн, 30/09/2013 в 00:54 +0200, Andreas K. Huettel пишет:

> Am Sonntag, 29. September 2013, 23:41:03 schrieb hasufell:
> > It seems this happens more frequently these days, so I'd like to
> > remind people to check stable reverse deps before stabilizing a
> > library, especially when this is a non-maintainer stablereq.
> >
> > Arch teams do not test them, so this is the business of the maintainer
> > or the dev who requested stabilization.
>
> Arch testing includes testing of reverse deps.
> If that's not the case, arch teams are not doing their job.

I think it's good idea if maintainers and arch team developers will work
in tandem and help each other by both checking reverse deps. That said
the question here is who is in charge for stable tree stability? Stable
tree is the arch team's primary responsibility. That is why only they
are allowed to touch stable keywords after all. So arch team developer
should never commit anything if at least few reverse deps were checked.
Last but not least, I guess that average developer has lot's of things
in package.keywords, so it's not sane to expect developer to do stable
tree checks.

--
Peter.



Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Agostino Sarubbo-2
In reply to this post by Rich Freeman
This is a delicate point.

If you look at the policy, it says to test few rdeps.

The arch tester is in charge to test the packages on his architecture. These type of failures are _not_ architecture dependant.

So, instead of have 10 ATs that are testing the same rdeps, seems logic that the maintainer could do it one time.

What do you think?

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Sergey Popov
In reply to this post by hasufell
30.09.2013 01:41, hasufell пишет:
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.
>

I hope you are kidding, cause when i was joining to arch teams, i was
taught to test reverse dependencies of libraries.

Of course, maintainer should test this also when bringing new version to
tree to prevent breakages. But stabilizing is different story and those
who putting apropriate version to stable should be 100% sure that it
would not break revdeps.

--
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop Effects project lead
Gentoo Qt project lead
Gentoo Proxy maintainers project lead


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

Re: stabilizing libraries without testing reverse deps

Markos Chandras-2
In reply to this post by hasufell
On 09/29/2013 10:41 PM, hasufell wrote:
> Arch teams do not test them, so this is the business of the maintainer
> or the dev who requested stabilization.
>

That is definitely not true. We always trained Arch Testers to test
reverse dependencies as well.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2013 09:22 AM, Markos Chandras wrote:
> On 09/29/2013 10:41 PM, hasufell wrote:
>> Arch teams do not test them, so this is the business of the
>> maintainer or the dev who requested stabilization.
>>
>
> That is definitely not true. We always trained Arch Testers to
> test reverse dependencies as well.
>

Then something is wrong:

https://bugs.gentoo.org/show_bug.cgi?id=464536
https://bugs.gentoo.org/show_bug.cgi?id=470554

for the first bug:
net-libs/ortp media-libs/mediastreamer and net-voip/linphone
are from the same upstream and actually have to be bumped and
stabilized TOGETHER, because it is very likely that they break
otherwise. And that's exactly what happened. The maintainer was
probably aware of it, but didn't respond, so arch testers went ahead
and did not test reverse deps.

for the second bug:
we now have a stable net-libs/libosip that cannot be installed when
you want to install stable net-libs/libeXosip... that is not a good
spot. Those libraries again should have been stabilized TOGETHER.

To me it seems one relies on the other to handle this and in the end
no one does?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSVYfAAoJEFpvPKfnPDWzPm0H+wU2G0iWQOT1cF02UPLUNFYF
GniIti6UBxV1iHmMBBLuKLzQYsSQtYQLSE7vTrbjUE2LyY6GlcfTOFiJOZG3Kar7
SNpH6jKkFY0XQnB7IaUcEKNJ+7esXZt9C3OvLJ/IqLcrQrqNsggGyKjoHwE7DoCG
RRAt+P18iU+XCOWgqGDCCzv6Ocez1aGhQ83geimTJB5aap1dQiI96S3obN6hu+8F
m9aXZ/nqBYLcrKQvjTWRtGX9Vz0WLN/F3vnfz7LcV5plz33tAn1rHSoe7okI5LQr
KP84dT+t6ixv8UHX8uPc2hFd3XvxVNKgduyvpLf7NnWN2A3D+JToM6zCJ64Xz5Q=
=J4jo
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Chí-Thanh Christopher Nguyễn
hasufell schrieb:

> https://bugs.gentoo.org/show_bug.cgi?id=464536
> https://bugs.gentoo.org/show_bug.cgi?id=470554
>
> for the first bug:
> net-libs/ortp media-libs/mediastreamer and net-voip/linphone
> are from the same upstream and actually have to be bumped and
> stabilized TOGETHER, because it is very likely that they break
> otherwise. And that's exactly what happened. The maintainer was
> probably aware of it, but didn't respond, so arch testers went ahead
> and did not test reverse deps.

I already replied in the second bug but let me reiterate again. What I
wrote in October 2012 to this list[1] is basically still true.

Following retirements, there is nobody in voip team who is interested in
these packages any more. Nobody in voip requested that these packages go
stable. When I read bugzilla reports that version bumps (typically done
as drive-by commits by outside developers) break consumers, then I
sometimes update the dependencies to account for that. When I saw the
second stabilization bug, I added the blocker, but the stabilization
proceeded anyway due to technical issues with the robo-stable scripts.

The ffmpeg-1.0 (and libav-9) situation got especially bad. For example,
a ptlib ebuild was committed which introduced libav-9 compatibility, but
also broke *every* *single* *consumer* of the package[2]! I have only
little time to dedicate to voip packages, and cleaning up the mess that
other developers leave is not a good way to use this time.

> To me it seems one relies on the other to handle this and in the end
> no one does?

We have one user, Andrew Savchenko, who expressed interest to proxy
maintain linphone and its dependencies via the voip overlay. I have
offered to commit the ebuilds for him to g-x86. Unfortunately it was a
lengthy process to allow him access to the overlay but that was cleared
10 days ago.

Once he starts pushing new ebuilds to the overlay, I will add him as
proxy maintainer in metadata.xml.


Best regards,
Chí-Thanh Christopher Nguyễn


[1] http://thread.gmane.org/gmane.linux.gentoo.devel/80638
[2] https://bugs.gentoo.org/show_bug.cgi?id=474742


Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

hasufell
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/30/2013 01:45 PM, Chí-Thanh Christopher Nguyễn wrote:

> hasufell schrieb:
>> https://bugs.gentoo.org/show_bug.cgi?id=464536 
>> https://bugs.gentoo.org/show_bug.cgi?id=470554
>>
>> for the first bug: net-libs/ortp media-libs/mediastreamer and
>> net-voip/linphone are from the same upstream and actually have to
>> be bumped and stabilized TOGETHER, because it is very likely that
>> they break otherwise. And that's exactly what happened. The
>> maintainer was probably aware of it, but didn't respond, so arch
>> testers went ahead and did not test reverse deps.
>
> I already replied in the second bug but let me reiterate again.
> What I wrote in October 2012 to this list[1] is basically still
> true.
>
> Following retirements, there is nobody in voip team who is
> interested in these packages any more. Nobody in voip requested
> that these packages go stable. When I read bugzilla reports that
> version bumps (typically done as drive-by commits by outside
> developers) break consumers, then I sometimes update the
> dependencies to account for that. When I saw the second
> stabilization bug, I added the blocker, but the stabilization
> proceeded anyway due to technical issues with the robo-stable
> scripts.
>
> The ffmpeg-1.0 (and libav-9) situation got especially bad. For
> example, a ptlib ebuild was committed which introduced libav-9
> compatibility, but also broke *every* *single* *consumer* of the
> package[2]! I have only little time to dedicate to voip packages,
> and cleaning up the mess that other developers leave is not a good
> way to use this time.
>
>> To me it seems one relies on the other to handle this and in the
>> end no one does?
>
> We have one user, Andrew Savchenko, who expressed interest to
> proxy maintain linphone and its dependencies via the voip overlay.
> I have offered to commit the ebuilds for him to g-x86.
> Unfortunately it was a lengthy process to allow him access to the
> overlay but that was cleared 10 days ago.
>
> Once he starts pushing new ebuilds to the overlay, I will add him
> as proxy maintainer in metadata.xml.
>
>
> Best regards, Chí-Thanh Christopher Nguyễn
>
>
> [1] http://thread.gmane.org/gmane.linux.gentoo.devel/80638 [2]
> https://bugs.gentoo.org/show_bug.cgi?id=474742
>
>

Yeah... I mean, I noticed. And this isn't critique to the team for the
packages being outdated. No bump is better than a shitty bump imo.

However... the fact still stands: arch team did not realize that it
breaks linphone. It could have been discussed on that bug how to
proceed because of the severity of the ffmpeg situation. But there was
no discussion and it broke a package in stable arch 3 months ago or so
and is unresolved til now.

That's not the way we should do things. If we know this is going to
happen we have to do something and in the worst case that is dropping
back to ~arch, tree-cleaning or hardmasking.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSWd8AAoJEFpvPKfnPDWzBwsH/RNPbDqHwi3zO685i+3BIoYn
T2u6JpdMeXdyco1UaYcTxZcp46oHjP40XG6wNWv73O+EydtwxR2Gl5Z/3VS1liXx
QdQ2eBLR0R5aqFYJYzX6vj2iEDypeMoz7ka/0CiaS/uL1ygrEkJ2GB1X4TE/td8p
58OjsD0T8+wo3OZphUu+tyALI2v3AS9J60U9DEv9nTZ55kWVHVpmClxDJudgHmFv
RriqcViFapFf54fnVXtOUzw8l7to5+bhiSM4Ne5cRvfu+cdn06w7p4iMEIiwshYS
OHUqG3K5peDW6BiO/T8Vg1hZuc/BMtDrg9Z8mj8vvZIC4axaesfKRUtykgijXUc=
=fuyE
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Paweł Hajdan, Jr.
In reply to this post by Agostino Sarubbo-2
On 9/29/13 11:14 PM, Agostino Sarubbo wrote:
> If you look at the policy, it says to test few rdeps.

And I think this is right. If you'd like things to be done in a
different way, discussing them is OK, but "unilaterally" just skipping
that is not OK.

> The arch tester is in charge to test the packages on his architecture.
> These type of failures are _not_ architecture dependant.

It depends. It certainly can be package-version-dependent, and this can
vary by arch, even between x86 and amd64.

> So, instead of have 10 ATs that are testing the same rdeps, seems logic
> that the maintainer could do it one time.
>
> What do you think?

It's not always the maintainer who files the stabilization bug. It can
be a user, or it can be me using automated scripts (which for the first
bug submission ask for maintainer's OK).

One possible option is for arch teams to refuse to do stabilization bugs
not explicitly approved by maintainers. If everybody agrees that such
approval also means testing reverse dependencies, it may be a move in
direction you're saying.

Now you've used an argument of scale: 10 ATs doing the "same thing"
(which btw I rarely see so many AT reports in one bug) vs. just 1
maintainer doing that.

I think that's a too local view. When you take the whole stabilization
queue into account (at least 80-120 bugs, below that it's not worth it
to me) you can save a lot of time through batching. Here's how:

1. On a fully stable system (even before testing packages to be
stabilized) emerge the reverse dependencies to make sure they currently
work (sometimes they're already broken in the stable tree, and some
packages to be stabilized actually fix these breakages). This can easily
take an overnight emerge, so it's good to put as many packages there as
possible to use that time effectively (and emerge's --keep-going option
is very helpful).

2. Emerge the packages to be tested. Usually another overnight emerge.

3. revdep-rebuild and all usual actions after updating the system.

4. Explicitly re-emerge the reverse dependencies again and compare the
results with run from (1). This would usually also take a long time on
my machine, so it's good to batch as many packages as possible. File
bugs for any regressions and do not stabilize packages introducing the
breakages.

As you see, the arch team member can do the all ~100 packages in about
3-4 days, and most of the process doesn't require human input. Most of
the time is spent reviewing the bugs (I have a script for that called
bugzilla-viewer.py which also displays related bugs and repoman output)
and reviewing the error messages for packages to be tested and reverse
dependencies. This is more effective the more packages you have, so arch
team member has a great advantage here being able to batch ~100 packages
instead of asking several maintainers to do their tests.

Of course it's good when maintainers also do their own testing in
stable, but I wouldn't block stabilization on that. IMHO instead of
trying to put the blame/duty on either maintainers or arch teams, the
right question to ask is what's the best process to do stabilizations well.

Paweł


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

Re: stabilizing libraries without testing reverse deps

Paweł Hajdan, Jr.
In reply to this post by hasufell
On 9/30/13 3:44 AM, hasufell wrote:
> https://bugs.gentoo.org/show_bug.cgi?id=470554
> [...]
> for the second bug:
> we now have a stable net-libs/libosip that cannot be installed when
> you want to install stable net-libs/libeXosip... that is not a good
> spot. Those libraries again should have been stabilized TOGETHER.
>
> To me it seems one relies on the other to handle this and in the end
> no one does?

Applying the maintainer timeout might be the problematic part there.

Note that the arch teams should still look at the blocking bug, and e.g.
bugzilla-viewer.py displays that prominently.

Paweł


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

Re: stabilizing libraries without testing reverse deps

Patrick Lauer
In reply to this post by Chí-Thanh Christopher Nguyễn
On 09/30/2013 07:45 PM, Chí-Thanh Christopher Nguyễn wrote:

> hasufell schrieb:
>> https://bugs.gentoo.org/show_bug.cgi?id=464536
>> https://bugs.gentoo.org/show_bug.cgi?id=470554
>>
>> for the first bug:
>> net-libs/ortp media-libs/mediastreamer and net-voip/linphone
>> are from the same upstream and actually have to be bumped and
>> stabilized TOGETHER, because it is very likely that they break
>> otherwise. And that's exactly what happened. The maintainer was
>> probably aware of it, but didn't respond, so arch testers went ahead
>> and did not test reverse deps.
>
> I already replied in the second bug but let me reiterate again. What I
> wrote in October 2012 to this list[1] is basically still true.
>
> Following retirements, there is nobody in voip team who is interested in
> these packages any more. Nobody in voip requested that these packages go
> stable. When I read bugzilla reports that version bumps (typically done
> as drive-by commits by outside developers) break consumers, then I
> sometimes update the dependencies to account for that. When I saw the
> second stabilization bug, I added the blocker, but the stabilization
> proceeded anyway due to technical issues with the robo-stable scripts.
>

> due to technical issues with the robo-stable scripts.

> due to technical issues with the robo-stable scripts.


let me summarize my response as "WAT"


Maybe we should just have a cronjob that just does all that automatically?

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

Markos Chandras-2
In reply to this post by hasufell
On 09/30/2013 11:44 AM, hasufell wrote:

> On 09/30/2013 09:22 AM, Markos Chandras wrote:
>> On 09/29/2013 10:41 PM, hasufell wrote:
>>> Arch teams do not test them, so this is the business of the
>>> maintainer or the dev who requested stabilization.
>>>
>
>> That is definitely not true. We always trained Arch Testers to
>> test reverse dependencies as well.
>
>
> Then something is wrong:
>
> https://bugs.gentoo.org/show_bug.cgi?id=464536
> https://bugs.gentoo.org/show_bug.cgi?id=470554
>
> for the first bug:
> net-libs/ortp media-libs/mediastreamer and net-voip/linphone
> are from the same upstream and actually have to be bumped and
> stabilized TOGETHER, because it is very likely that they break
> otherwise. And that's exactly what happened. The maintainer was
> probably aware of it, but didn't respond, so arch testers went ahead
> and did not test reverse deps.
>
The fact that an AT may or may not do his job properly does not mean
that we should delegate the problem to the maintainer. I am not saying
that the maintainer should not test his packages. But when it comes to
stabilizations it's the job of ATs and Arch developers to decide what
does and what doesn't belong to the stable tree.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Reply | Threaded
Open this post in threaded view
|

Re: stabilizing libraries without testing reverse deps

William Hubbs
In reply to this post by Thomas Kahle
On Mon, Sep 30, 2013 at 12:40:04AM +0200, Thomas Kahle wrote:

> On 09/29/2013 11:41 PM, hasufell wrote:
> > It seems this happens more frequently these days, so I'd like to
> > remind people to check stable reverse deps before stabilizing a
> > library, especially when this is a non-maintainer stablereq.
> >
> > Arch teams do not test them, so this is the business of the maintainer
> > or the dev who requested stabilization.
>
> Huh.  This must be new.  When I was still arch-testing, reverse deps
> were checked.  app-portage/tatt (which is sort of maintainer-needed now)
> has support for these tests too.
Agreed. I was always told that it is up to the arch teams to test the
reverse deps.

William

William

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

Re: stabilizing libraries without testing reverse deps

Rich Freeman
On Mon, Sep 30, 2013 at 12:58 PM, William Hubbs <[hidden email]> wrote:
>
> Agreed. I was always told that it is up to the arch teams to test the
> reverse deps.

While I think this makes the most sense in general, I think
maintainers do have a role.

If some package has 75 reverse dependencies, and 1 of them tends to
break every time there is an upgrade, then it makes more sense for the
maintainer to stay on top of that and coordinate stabilization.  The
arch team isn't going to remember that, and unless they test all 75
they're not going to spot the 1 that breaks.

Now, in cases like the VOIP ones where there are only 3 reverse deps
it really does make sense for the arch teams to be expected to spot
issues, especially now that tools exist to make this a bit easier...

Rich

12