| 1 |
On Thu, Sep 22, 2011 at 5:41 PM, Donnie Berkholz <dberkholz@g.o> wrote: |
| 2 |
> On 09:37 Wed 21 Sep , Alec Warner wrote: |
| 3 |
>> On Wed, Sep 21, 2011 at 6:11 AM, Donnie Berkholz <dberkholz@g.o> wrote: |
| 4 |
>> > Not really, because when you update a bundled lib you actually make |
| 5 |
>> > your whole app compile with it. People change the APIs of eclasses |
| 6 |
>> > and then just let every internal consumer (ebuilds in gentoo-x86) |
| 7 |
>> > break. Maybe if we put the burden on the one who changed the API, |
| 8 |
>> > like the Linux kernel model, it would bother me less. |
| 9 |
>> |
| 10 |
>> I think people do this for three reasons. |
| 11 |
>> |
| 12 |
>> 1) There are no refactoring tools that I know of for bash. |
| 13 |
>> 2) There exist some package maintainers that will yell at you if you |
| 14 |
>> touch their packages for any reason. |
| 15 |
> |
| 16 |
> To refer to the Linux model again, you send patches to the maintainers, |
| 17 |
> and they just commit them. This is much less effort than figuring out to |
| 18 |
> handle some incomprehensible change to an already weird eclass and then |
| 19 |
> sorting out how to deal with it across 20 or 30 packages. |
| 20 |
|
| 21 |
In my experience maintainers do not 'just commit my patches.' But |
| 22 |
perhaps I'm crazy. |
| 23 |
|
| 24 |
> |
| 25 |
>> 3) Breaking things means they get fixed. |
| 26 |
>> |
| 27 |
>> We have this notify -> deprecate -> break workflow; I actually don't |
| 28 |
>> mind it (but only because I've seen it used elsewhere.) |
| 29 |
> |
| 30 |
> I do, because I don't have time to deal with other people breaking my |
| 31 |
> packages, whether they're in gentoo-x86, the science overlay, or my |
| 32 |
> personal one. I've got more important things to deal with, within Gentoo |
| 33 |
> and in the rest of my life. |
| 34 |
|
| 35 |
You don't have time to fix breakages but you have time to do code reviews? |
| 36 |
|
| 37 |
I put a code review system in the infra survey because I think |
| 38 |
bugzilla is a poor way to track changes to the tree and there is not a |
| 39 |
good way to get feedback or track updates. I think if we had |
| 40 |
streamlined tools for this I'd be less concerned about mailing out |
| 41 |
changes to 60 or 100 or 1000 packages and having any sane idea which |
| 42 |
packages were fixed, which were pending, which packages I had not |
| 43 |
heard from someone in a while.. etc... |
| 44 |
|
| 45 |
-A |
| 46 |
|
| 47 |
> |
| 48 |
> -- |
| 49 |
> Thanks, |
| 50 |
> Donnie |
| 51 |
> |
| 52 |
> Donnie Berkholz |
| 53 |
> Council Member / Sr. Developer |
| 54 |
> Gentoo Linux |
| 55 |
> Blog: http://dberkholz.com |
| 56 |
> |
Archives