Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer
On Fri, Jan 31, 2014 at 10:19 AM, hasufell wrote: > Googleearth is 90% of the time broken. I don't see how you can do > automated version bumps there. And we should not bump if the new version > is broken. > If that is the case, it sounds like it isn't worth keeping it in the tree.
Re: [gentoo-dev] January 2014 QA Policy Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/31/2014 09:07 AM, Peter Stuge wrote: > Alec Warner wrote: >>> hmm? >> >> To be fair, I had a long discussion with this regarding when QA >> has the authority to temporarily ban a developer. > > Cool. > > >> In the case where policy is missing, QA does not have a clear >> case of authority there. It becomes a more murky area. I've tried >> to very much encourage QA to both publish the policies they want >> to enforce, and automate enforcement with better tooling (repoman >> or otherwise). Being transparent and consistent in enforcement >> of policy goes a long way for getting developers on your side. > > Absolutely. > > >> So in short, while one could read that passage as you did, I >> don't think that is their intention. > > To be clear, I don't think so either. > > > Rich Freeman wrote: >> I was really happy to see a public notice of meeting and a >> published summary. > > Yes, me too! > > > I still think it seems like QA could essentially introduce > arbitrary new policies and 2 weeks later be expected to effect > them. > > Fine when everyone agrees. Not so much at other times. The > responsibility is with QA to build support among the developers, > and I agree that the transparency goes a long way! > > > //Peter > Regarding the question in your first email: We will not create a policy then immeiately use the policy as justification to to go edit packages. The intention of the "we may ask the developer to stop" line is for cases where we suspect that what the developer is doing is causing a problem and would like to discuss it further. I feel that that is well within the bounds of GLEP 48. As for the "when/how we make and communicate fixes," I think that just about any policy we make will fall into the middle ground you omitted of "file a bug, wait 2 weeks, fix." So no, we will not be making arbitrary fixes just because we can. Regarding your concern about us introducing arbitrary policies: again, most will fall into the "file a bug" middle ground. We also are perfectly aware that you can't expect people to change overnight, and we will not be shouting at devs just because they didn't implement $(new-policy) right away. We will file bugs asking for changes, and we will try to offer suggestions or patches wherever possible to make it easier for maintainers. Chris Reffett Gentoo QA Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLrv0hfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak =5CIT -END PGP SIGNATURE-
Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer
On 01/30/2014 11:02 PM, Mike Gilbert wrote: > On Thu, Jan 30, 2014 at 4:36 PM, Pacho Ramos wrote: >> El jue, 30-01-2014 a las 13:47 +0100, Marc Schiffbauer escribió: >>> * Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr: Currently, there is no really working version of it in the tree: https://bugs.gentoo.org/show_bug.cgi?id=494624 But due its bumps and current bugs, this needs a maintainer... otherwise, I would treeclean it (the problem is that looks like some people use it, but without none of them willing to maintain it, it will be difficult to handle :( ) >>> >>> I would help taking care of it, as I use it sometimes. >>> >>> How oftes does this need to be bumped? >>> >>> >> >> I am not sure :(, I am not too familiar with it since it never worked ok >> on my machines >> > > I do a lot of version bumping on google-chrome, and I have a script > that automates the process for me. If anyone is interested in > maintaining googleearth in a similar manner, you might find my script > useful. > > http://dev.gentoo.org/~floppym/chrome-bump > Googleearth is 90% of the time broken. I don't see how you can do automated version bumps there. And we should not bump if the new version is broken.
Re: [gentoo-dev] January 2014 QA Policy Updates
Alec Warner wrote: > > hmm? > > To be fair, I had a long discussion with this regarding when QA has the > authority to temporarily ban a developer. Cool. > In the case where policy is missing, QA does not have a clear case > of authority there. It becomes a more murky area. I've tried to > very much encourage QA to both publish the policies they want to > enforce, and automate enforcement with better tooling (repoman or > otherwise). Being transparent and consistent in enforcement of > policy goes a long way for getting developers on your side. Absolutely. > So in short, while one could read that passage as you did, I don't > think that is their intention. To be clear, I don't think so either. Rich Freeman wrote: > I was really happy to see a public notice of meeting and a published > summary. Yes, me too! I still think it seems like QA could essentially introduce arbitrary new policies and 2 weeks later be expected to effect them. Fine when everyone agrees. Not so much at other times. The responsibility is with QA to build support among the developers, and I agree that the transparency goes a long way! //Peter
Re: [gentoo-dev] January 2014 QA Policy Updates
On Fri, Jan 31, 2014 at 1:14 AM, Alec Warner wrote: >> sounds to me like QA is giving itself carte blanche to make any "fix" >> they want as per "we think a developer's actions are causing problems" >> hmm? > > So in short, while one could read that passage as you did, I don't think > that is their intention. Probably also worth noting that QA isn't giving itself any authority - GLEP 48 gave them very broad authority some time ago. QA has been operating in the manner described for a fairly long time as well. It just seems like they're trying to be more transparent about it, which I applaud. GLEP 48 was recently amended to require QA to have its nominated lead confirmed by the council largely because it is a position that wields a great deal of authority. I was really happy to see a public notice of meeting and a published summary. While any kind of policy-making will always involve some level of controversy, I think that this goes a long way towards assuring the community that they have a voice and that if policies don't turn out well they can be adjusted. Maybe the only thing that changed is perceptions, but those are important. Rich
Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer
* Tom Wijsman schrieb am 31.01.14 um 00:52 Uhr: On Thu, 30 Jan 2014 13:47:27 +0100 Marc Schiffbauer wrote: * Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr: >Currently, there is no really working version of it in the tree: >https://bugs.gentoo.org/show_bug.cgi?id=494624 > >But due its bumps and current bugs, this needs a maintainer... >otherwise, I would treeclean it (the problem is that looks like some >people use it, but without none of them willing to maintain it, it >will be difficult to handle :( ) > > I would help taking care of it, as I use it sometimes. How oftes does this need to be bumped? Check the ChangeLog (`grep '^*' ChangeLog`): *googleearth-7.1.1.1888 (18 Aug 2013) *googleearth-7.1.1.1871 (01 Jul 2013) *googleearth-7.1.1.1580 (19 May 2013) *googleearth-7.0.3.8542 (02 Mar 2013) *googleearth-7.0.2.8415-r2 (10 Feb 2013) *googleearth-7.0.2.8415-r1 (04 Feb 2013) *googleearth-7.0.2.8415 (02 Feb 2013) *googleearth-6.2.2.6613 (05 May 2012) *googleearth-6.2.1.6014-r1 (02 Mar 2012) *googleearth-6.2.1.6014 (01 Mar 2012) *googleearth-6.0.3.2197 (24 May 2011) *googleearth-6.0.2.2074 (02 Apr 2011) *googleearth-6.0.1.2032_beta (31 Jan 2011) Looks reasonable. The tricky thing with this package (not sure whether it has improved over the last year) is that there are bundled libraries; and depending on how you handle (or don't handle) them, it can lead to breakages. Due to a binary nature, this is often something you can't resolve yourself; iotw, this means you'll need to check up with upstream to fix these. Besides that, there is also RESTRICT="mirror"; so, you are restricted to providing the versions upstream provides (eg. in case you want to mask newer versions until a bug is resolved). Thanks for the info Tom. I will subscribe myself to the package. Anybody else is invited to help me with it. -Marc -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
Re: [gentoo-dev] sci-geosciences/googleearth is orphan and needs a dedicated maintainer
* Mike Gilbert schrieb am 30.01.14 um 23:02 Uhr: On Thu, Jan 30, 2014 at 4:36 PM, Pacho Ramos wrote: El jue, 30-01-2014 a las 13:47 +0100, Marc Schiffbauer escribió: * Pacho Ramos schrieb am 29.01.14 um 07:58 Uhr: >Currently, there is no really working version of it in the tree: >https://bugs.gentoo.org/show_bug.cgi?id=494624 > >But due its bumps and current bugs, this needs a maintainer... >otherwise, I would treeclean it (the problem is that looks like some >people use it, but without none of them willing to maintain it, it will >be difficult to handle :( ) > > I would help taking care of it, as I use it sometimes. How oftes does this need to be bumped? I am not sure :(, I am not too familiar with it since it never worked ok on my machines I do a lot of version bumping on google-chrome, and I have a script that automates the process for me. If anyone is interested in maintaining googleearth in a similar manner, you might find my script useful. http://dev.gentoo.org/~floppym/chrome-bump Thanks, I will have a look! -- 0x35A64134 - 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134 signature.asc Description: Digital signature
