Re: [gentoo-dev] gstreamer eclass review
Le jeudi 06 décembre 2012 à 06:01 +0200, Maxim Kammerer a écrit :
Hi, after the commit 3 days ago all kinds of plugins suddenly depend
on gst-plugins-bad. E.g.: gst-plugins-{dts,faad,libmms,resindvd,xvid}.
Is gst-plugins-bad eclass the wrong one to inherit in their case?
Also, vp8 plugin both inherits from the eclas, and has an explicit
dependency on media-libs/gst-plugins-bad — perhaps one or the other
should be removed.
Please open bug reports at gentoo's bugzilla if you have problem with
the ebuilds.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 4 December 2012 17:19, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 01:18, Ben de Groot yng...@gentoo.org wrote: In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin As I said, the only drawback is that devmanual will become huge and without a proper search functionality, it will be a real pain to search for something quickly. Especially for new developers who are not familiar with how devmanual is structured. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 Except the situation now is worse. Things are spread over multiple documents, and we don't have a proper site search. Even so, 1) Google is your friend, and 2) a single document with a good index would be a step forward. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 5 December 2012 02:51, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 17:28, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. Actually, as I have been arguing elsewhere, scattering policies over multiple documents is not helpful. So this should be documented in devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 6 December 2012 11:02, Ben de Groot yng...@gentoo.org wrote: On 5 December 2012 02:51, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 17:28, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. Actually, as I have been arguing elsewhere, scattering policies over multiple documents is not helpful. So this should be documented in devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. However, it is possible to add a note on metadata.xml section in devmanual to explain how to structure a metadata.xml file for proxy maintainers. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
Markos Chandras wrote: This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. The reason is that I as a developer (whenever I become one) want to be able to fix stuff right now that is broken on my system and publish those fixes somewhere. I believe and hope that working with bugs will see new approaches when the warm git blanket is swept around the portage repo. In the last 15 hours I've dealt with several trivial bugs that I've found fixes for in bugzilla but which were not committed anywhere. I've committed them to my overlay and that's fine for me, but if I were a developer I would find it super lame to have to stop there and wait for $otherguy to take time to look at his bugs. The bugs are equally much mine, because they bite me. I'm not saying I expect to change everyone's ebuilds, but I'm saying that I think the bug tracker has way more emphasis today than I would like it to. I think most of that is because it simply couldn't have worked any other way. In the future it might, and I think that's good. I would expect to fix the bugs, and then email patches to whoever is the maintainer. It would be worthwhile to have automatic extraction of who needs to get that email based on what files were touched. No bug needed, if maintainers get perfect patches in email they can review them quickly and simply push them into the tree. End result: Everyone has mandate to fix bugs and it becomes so easy for maintainers to apply fixes that they can do it immediately when anyone sends a perfect patch. The dream scenario would be a gerrit instance in front of the repo. (Yes infra, that means Java. Sorry, but that tool is best in class IMO.) Finally my thanks to everyone who helps make Gentoo better every day! //Peter
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/12 10:27 AM, Peter Stuge wrote: [ Snip! ] In the last 15 hours I've dealt with several trivial bugs that I've found fixes for in bugzilla but which were not committed anywhere. I've committed them to my overlay and that's fine for me, but if I were a developer I would find it super lame to have to stop there and wait for $otherguy to take time to look at his bugs. [ Snip! ] I would expect to fix the bugs, and then email patches to whoever is the maintainer. It would be worthwhile to have automatic extraction of who needs to get that email based on what files were touched. No bug needed, if maintainers get perfect patches in email they can review them quickly and simply push them into the tree. There's a bit of an issue with this, though -- for many projects, and many bugs, patches are not committed to the tree until that bug and patch has been submitted upstream (job of the maintainer) and upstream has approved or accepted that patch. I think quite often this is why patches sit in bugs instead of getting to the tree. Essentially, if the problem is with the ebuild or the way the package is integrated into gentoo, then fixing it immediately is fine. If the problem is with the software itself, then usually upstream needs to be involved before the fix will occur in gentoo. Also, Emailing patches to the maintainer is much less acceptable/desirable than filing them through bugzilla. As a developer, I find it much easier to grab patches from this nice centralized bug-tracking filing system than to have to organize them in email, and git integration is not something I see changing this. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDAv7EACgkQ2ugaI38ACPCQ/QEAmYjna1exh9qxqptbdB08Hvoo TzJi72ux2nf9edZsR3IA+wXENBA1EDuc/8JDN74aJ0/iFdhL1yG2CxJ515tNDxxX =4d2v -END PGP SIGNATURE-
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
Ian Stakenvicius wrote: Essentially, if the problem is with the ebuild or the way the package is integrated into gentoo, then fixing it immediately is fine. If the problem is with the software itself, then usually upstream needs to be involved before the fix will occur in gentoo. Yes that's fair of course. None of the handful issues I've had so far while building 900 packages were about upstream however. Also, Emailing patches to the maintainer is much less acceptable/desirable than filing them through bugzilla. As a developer, I find it much easier to grab patches from this nice centralized bug-tracking filing system than to have to organize them in email, and git integration is not something I see changing this. Have you tried gerrit? It is really a leap ahead. //Peter
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 6 December 2012 15:27, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. The reason is that I as a developer (whenever I become one) want to be able to fix stuff right now that is broken on my system and publish those fixes somewhere. ... I am not sure I understand how this is related to this discussion. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
