| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 01-03-2010 06:39, Markos Chandras wrote: |
| 5 |
> On Friday 26 February 2010 18:40:47 Alec Warner wrote: |
| 6 |
>> You mistake the intent I think. We deploy automation because humans |
| 7 |
>> fail; even when they have the best intentions. We make typos, copy |
| 8 |
>> and paste errors, accidentally leave whitespace, type commands into |
| 9 |
>> the wrong shell, hit the wrong key that kills our session, etc. Smart |
| 10 |
>> people avoid work by making a computer do parts that are easily |
| 11 |
>> automated; which is why the proposed system is so fine-grained. We |
| 12 |
>> can likely add some logic to our current toolset to remind the human |
| 13 |
>> that they may have further obligations than just typing repoman commit |
| 14 |
>> (like asking on a bug, a mailing list, irc, etc.) With a really |
| 15 |
>> simple system; we cannot easily automate when to do what because the |
| 16 |
>> criteria are so broad. I agree that a moderately complex system is |
| 17 |
>> useless for humans (I'd ignore it straight out) which is why we should |
| 18 |
>> write software to do the work for us. I am much more likely to |
| 19 |
>> respond to a message from repoman telling me I need to file a bug |
| 20 |
>> first as opposed to me looking at metadata.xml every time I commit |
| 21 |
>> something. Sure there are people who never read repoman output and |
| 22 |
>> commit utter crap to the tree; but I do not really expect 100% success |
| 23 |
>> from any system we deploy; I'd be happy with 60% honestly. |
| 24 |
>> |
| 25 |
> In my eyes, we don't need a smarter repoman to check whether we are supposed |
| 26 |
> or not to do a specific commit. What we need are rules ( stricter or not ) |
| 27 |
> which DO apply to all developers, and a team ( devrel ) which will be |
| 28 |
> responsible to do that. Repoman will not help the situation but it will add a |
| 29 |
> new level of complexity into our already complex "communication" system. |
| 30 |
> We need an active devrel team which will postpone commit access to those |
| 31 |
> developers who are repeatedly fail to behave correctly whatever that means. |
| 32 |
> |
| 33 |
> That said, i am totally again messing with metadata.xml as long as there |
| 34 |
> problem resides in a much higher level |
| 35 |
|
| 36 |
Markos, |
| 37 |
|
| 38 |
the job of Developer Relations is not to act as a "repo police". What |
| 39 |
you're talking about is mostly a QA issue. |
| 40 |
Whenever Developers, in particular maintainers for a package, feel |
| 41 |
someone ignored or broke policy and report that to Developer Relations, |
| 42 |
than it will get into the team's radar. However, Developer Relations is |
| 43 |
not and will not grep the commits ml to find "offenders". |
| 44 |
|
| 45 |
PS - As Alec suggested, automated tools that help identify and report |
| 46 |
issues are a good idea. In the least, when someone ignores a rule |
| 47 |
repoted by repoman, you can be sure it wasn't a distraction, but a |
| 48 |
conscious decision to ignore its output. |
| 49 |
|
| 50 |
- -- |
| 51 |
Regards, |
| 52 |
|
| 53 |
Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org |
| 54 |
Gentoo- forums / Userrel / Devrel / KDE / Elections |
| 55 |
-----BEGIN PGP SIGNATURE----- |
| 56 |
Version: GnuPG v2.0.14 (GNU/Linux) |
| 57 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
| 58 |
|
| 59 |
iQIcBAEBAgAGBQJLi7U1AAoJEC8ZTXQF1qEPJHEP/3eZp8fFoqdcgNJJVDHS6Xa3 |
| 60 |
YXKUYthkEzZZQhtfPgQdRh4pYqFwrc+d+uq1CoRLECLOuhNk0m+wu+jN7UByJGQp |
| 61 |
wSlZMFxHuvI410oHhGTkNH7Mes9BBGKF3hYRyyd5og7qCseo3S6BTvJSdvV1QbH9 |
| 62 |
l1W3inag56ZjwCMWDjr2Z/iqhiym6lPBI7ShEz13SYffOKWrbMErDqIDi/JbIb4a |
| 63 |
N7YKhTUEqsfYkVZbO42uj0wVWGR+mz0lAwJozh0jLvTtLLQc3xcr74SlsRno18k6 |
| 64 |
922JXxatbDQdsL3xDY4rxWUKlF2q/HDNLdKx4LLEIyr+oOH1V6Jaf9ygWlfhjQGQ |
| 65 |
6KV6yQSvRcDhIGg4PLirfzXswFqxjfVc1jtc1JEHRjSFsWxAfZ4FNNk7w+XHo0Cx |
| 66 |
5oPV5yNKCnYfOmq2BLyVQI8VALQ0dnv3OW3Hg1nGv0ILcrM6g35cvmPNqgyZXDid |
| 67 |
5ut6u86U+JSFhq2geeCaIBqaZbOpWy8wJ7zIZ7MjMx9CzYpSHF4olAVy0JY+sQe7 |
| 68 |
NjNy1BM+gENqlFezltQGDaHwA1A/xNsaH0c8P0Zlc7QeoNQw/KQn7n5EpsWr+RR6 |
| 69 |
8c/mOQAruyA3BsWD2g+NOU64+Yo7NuGUAo94broIVBNf5wWbynC1pPFU7r3g0055 |
| 70 |
d385QdXsv8MlvosRkWck |
| 71 |
=tXdy |
| 72 |
-----END PGP SIGNATURE----- |
Archives