FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 06-25-2010, 11:27 PM
Jesse Keating
 
Default Evolution update in F13

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

Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.

Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?

- --
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwlO0cACgkQ4v2HLvE71NXVxwCfS59qPC/vUPT1rEIMrhMRijDL
C9gAnj8FKdjdPHqL4lZPFWiAMKWsEXma
=OHPB
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 05:33 AM
Adam Miller
 
Default Evolution update in F13

Sounds like it might need to be. Maybe push stable requests with -2 karma to some list that requires investigation and possibly a +3 (or other agreed upon number) proventesters karma to go stable?


Just a thought.


-AdamM (From Android)


On Jun 25, 2010 6:27 PM, "Jesse Keating" <jkeating@redhat.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



Can anybody tell me what went wrong with this update? *It was submitted

at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was

submitted for stable two hours later. *Between that submission and the

push to stable (push to stable happened at 18:09 on 06-25) numerous

negative karma came in due to broken deps. *The update went out anyway,

and now we have a mess of broken updates on a critical path package, and

have to scramble to fix it with more updates, on a Friday.



Can anybody help me understand the scenario here? *Should we start

filtering out push requests that have more than -2 karma?



- --

Jesse Keating

Fedora -- Freedom˛ is a feature!

identi.ca: http://identi.ca/jkeating





-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.9 (Darwin)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/



iEYEARECAAYFAkwlO0cACgkQ4v2HLvE71NXVxwCfS59qPC/vUPT1rEIMrhMRijDL

C9gAnj8FKdjdPHqL4lZPFWiAMKWsEXma

=OHPB

-----END PGP SIGNATURE-----

--

devel mailing list

devel@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/devel



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 05:50 AM
Adam Williamson
 
Default Evolution update in F13

On Fri, 2010-06-25 at 16:27 -0700, Jesse Keating wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Can anybody tell me what went wrong with this update? It was submitted
> at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
> submitted for stable two hours later. Between that submission and the
> push to stable (push to stable happened at 18:09 on 06-25) numerous
> negative karma came in due to broken deps. The update went out anyway,
> and now we have a mess of broken updates on a critical path package, and
> have to scramble to fix it with more updates, on a Friday.
>
> Can anybody help me understand the scenario here? Should we start
> filtering out push requests that have more than -2 karma?

I talked to notting &c about this earlier, and we've hit this situation
before. The 'scenario' is simply that there's really no screening
between 'submit' and 'push' for stable updates, and this one was
submitted to stable before any negative karma came in. There's no
reliable process whereby whoever's doing the push to stable actually
looks at feedback before doing it; unless they happen to have been made
aware that a particular package shouldn't be pushed, they just push
everything that's been submitted.

Clearly the maintainer did not allow sufficient time for testing here;
there's a grand 4 hour window between the update being 'pushed to
testing' and 'submitted to stable'. That probably wasn't long enough for
it even to hit any public mirrors.

AutoQA will also help a lot here, obviously, when it's fully
implemented. If implemented as planned, the depcheck tests would have
prevented the update from being pushed.

The requirement for proventester feedback for critpath updates, when we
turn it on, should also catch problems like this in the critpath. Evo
isn't critpath, though, I believe.

Until AutoQA is in place to tackle this, the obvious option is for there
to be a process improvement whereby whoever's doing stable update pushes
at least gets notified if a package has received negative karma since
the submission. I think we discussed something similar on -devel last
time this happened. Not sure if there's a ticket, or how hard that would
be to implement.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 05:53 AM
Ralf Corsepius
 
Default Evolution update in F13

On 06/26/2010 07:33 AM, Adam Miller wrote:
> Sounds like it might need to be. Maybe push stable requests with -2 karma to
> some list that requires investigation and possibly a +3 (or other agreed
> upon number) proventesters karma to go stable?

Would you mind to explain how could have happened:

# yum update
...
---> Package evolution.x86_64 0:2.30.2-1.fc13 set to be updated
--> Processing Dependency: libedataserver-1.2.so.11()(64bit) for
package: gnome-panel-2.30.0-1.fc13.x86_64
--> Processing Dependency: libedataserver-1.2.so.11()(64bit) for
package: glabels-2.2.8-1.fc13.x86_64
---> Package evolution-data-server.x86_64 0:2.30.2-2.fc13 set to be updated
--> Finished Dependency Resolution
Error: Package: glabels-2.2.8-1.fc13.x86_64 (@updates)
Requires: libedataserver-1.2.so.11()(64bit)
Removing: evolution-data-server-2.30.1-2.fc13.x86_64 (@fedora)
Error: Package: gnome-panel-2.30.0-1.fc13.x86_64 (@fedora)
Requires: libedataserver-1.2.so.11()(64bit)
Removing: evolution-data-server-2.30.1-2.fc13.x86_64 (@fedora)

To me this is a clear case of package-push which should not have
happened and is not related to karma votes at all.

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 06:23 AM
Jesse Keating
 
Default Evolution update in F13

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

On 6/25/10 10:50 PM, Adam Williamson wrote:
> Until AutoQA is in place to tackle this, the obvious option is for there
> to be a process improvement whereby whoever's doing stable update pushes
> at least gets notified if a package has received negative karma since
> the submission. I think we discussed something similar on -devel last
> time this happened. Not sure if there's a ticket, or how hard that would
> be to implement.

Likely the easiest thing to do is on the client side we use, filter any
update requests that have too negative of karma. It would have caught
this issue. They can be displayed for a releng person to further
investigate.

- --
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwlnOUACgkQ4v2HLvE71NUVrwCfUw3Ji+33uZ k2QwvsfZO1JGeM
jH0An13glytiG7P9a2n7POsdzCqX5MUz
=XHtq
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 06:29 AM
Rahul Sundaram
 
Default Evolution update in F13

On 06/26/2010 11:20 AM, Adam Williamson wrote:
>
> Clearly the maintainer did not allow sufficient time for testing here;
> there's a grand 4 hour window between the update being 'pushed to
> testing' and 'submitted to stable'. That probably wasn't long enough for
> it even to hit any public mirrors.
>

Can the maintainers please explain why they did this? We need that
answer before looking at AutoQA IMO.

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 12:10 PM
Peter Robinson
 
Default Evolution update in F13

On Sat, Jun 26, 2010 at 7:23 AM, Jesse Keating <jkeating@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/25/10 10:50 PM, Adam Williamson wrote:
>> Until AutoQA is in place to tackle this, the obvious option is for there
>> to be a process improvement whereby whoever's doing stable update pushes
>> at least gets notified if a package has received negative karma since
>> the submission. I think we discussed something similar on -devel last
>> time this happened. Not sure if there's a ticket, or how hard that would
>> be to implement.
>
> Likely the easiest thing to do is on the client side we use, filter any
> update requests that have too negative of karma. *It would have caught
> this issue. They can be displayed for a releng person to further
> investigate.

That would only work if the script that does the push to stable (as
opposed to processing the request to push to stable) checks if any
negative karma has appeared since the request has happened.

I believe that a deps autoqa is still a good idea for stable releases.

Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 04:14 PM
Luke Macken
 
Default Evolution update in F13

On Fri, 2010-06-25 at 22:50 -0700, Adam Williamson wrote:
> I talked to notting &c about this earlier, and we've hit this situation
> before. The 'scenario' is simply that there's really no screening
> between 'submit' and 'push' for stable updates, and this one was
> submitted to stable before any negative karma came in. There's no
> reliable process whereby whoever's doing the push to stable actually
> looks at feedback before doing it; unless they happen to have been made
> aware that a particular package shouldn't be pushed, they just push
> everything that's been submitted.

There actually is a way to get feedback on updates before pushing.
Bodhi's admin request list interface gives everything in the list headed
to stable a color based on some heuristics. So it's quite easy to scan
the list and look at the red updates, which have negative karma, or
haven't been in testing long. However, I think all of our bodhi admins
who kick off the pushes use the command-line instead.

I think that in this case, the command-line bodhi client could be
improved to make it obvious that they're about to push an update with
negative karma.

[...]

> The requirement for proventester feedback for critpath updates, when we
> turn it on, should also catch problems like this in the critpath. Evo
> isn't critpath, though, I believe.

evolution-data-server is in the critpath, and having the proventester
feedback policy implemented would have definitely caught this issue.

luke

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 05:24 PM
Orcan Ogetbil
 
Default Evolution update in F13

On Sat, Jun 26, 2010 at 12:14 PM, Luke Macken wrote:
> On Fri, 2010-06-25 at 22:50 -0700, Adam Williamson wrote:
>> I talked to notting &c about this earlier, and we've hit this situation
>> before. The 'scenario' is simply that there's really no screening
>> between 'submit' and 'push' for stable updates, and this one was
>> submitted to stable before any negative karma came in. There's no
>> reliable process whereby whoever's doing the push to stable actually
>> looks at feedback before doing it; unless they happen to have been made
>> aware that a particular package shouldn't be pushed, they just push
>> everything that's been submitted.
>
> There actually is a way to get feedback on updates before pushing.
> Bodhi's admin request list interface gives everything in the list headed
> to stable a color based on some heuristics. *So it's quite easy to scan
> the list and look at the red updates, which have negative karma, or
> haven't been in testing long. *However, I think all of our bodhi admins
> who kick off the pushes use the command-line instead.
>
> I think that in this case, the command-line bodhi client could be
> improved to make it obvious that they're about to push an update with
> negative karma.
>

Once 2 curious users went and downloaded the package for their
architecture from koji when it was in queue for testing (it wasn't in
the repo yet). They couldn't install the package because they couldn't
figure out that they need to download the noarch subpackage that needs
to be installed simultaneously with the arch-specific one. They gave
me -2 karma for that reason, which means absolutely nothing.

Therefore banning a push because of negative karma can be pointless in
certain cases. Again, my vote goes to leave everything in testing for
336 hours, at least, and proceeding accordingly.

Orcan

Orcan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 06-26-2010, 06:59 PM
Jesse Keating
 
Default Evolution update in F13

On 06/26/2010 05:10 AM, Peter Robinson wrote:
> That would only work if the script that does the push to stable (as
> opposed to processing the request to push to stable) checks if any
> negative karma has appeared since the request has happened.

Well, if there is a update push to stable request that has any amount of
net negative karma, it needs to be looked at and a human should
intercept it.

>
> I believe that a deps autoqa is still a good idea for stable releases.

Correct, this is not a replacement for that, just something we can do
today while AutoQA work continues.


--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 11:50 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org