| 1 |
James Broadhead <jamesbroadhead <at> gmail.com> writes: |
| 2 |
|
| 3 |
|
| 4 |
> You seem to be talking about doing a few different things, none of |
| 5 |
> which is _quite_ what I'd call a code review. |
| 6 |
|
| 7 |
Well my experience is if you cannot hack the code a little bit, |
| 8 |
reviews of just reading and using parsing tools, are mostly |
| 9 |
benign in performing a solid code review.... ymmv. |
| 10 |
|
| 11 |
|
| 12 |
> If you want to work on writing patches for it, then it doesn't make as |
| 13 |
> much sense. |
| 14 |
|
| 15 |
Some times code changes rarely. Like minicom. There is no GIT |
| 16 |
or repository activity that amounts to anything. In general, |
| 17 |
with active projects, you are right. Much of what I'm doing |
| 18 |
is cleaning up old, neglected code, that most do not use anymore.... |
| 19 |
|
| 20 |
|
| 21 |
> So basically, I'm advising you to check out from upstream's version |
| 22 |
> control, work on your patching inside the checkout, perform builds, |
| 23 |
> but don't "make install". Run the test builds from your development |
| 24 |
> folder (that way you can have $APP-nopatch installed and working |
| 25 |
> system-wide, and can compare to it while you're testing). Once your |
| 26 |
> patch is ready, create a local overlay + update the ebuild to apply |
| 27 |
> your patch. Finally, file those bug reports! |
| 28 |
|
| 29 |
I have to delete much of your message to use gmane.... |
| 30 |
|
| 31 |
|
| 32 |
Anyway, I agree with and like your suggestions. I'm also reading |
| 33 |
some docs I found on overlays and gentoo development. |
| 34 |
I guess I'll survey all of the ideas and then mostly use |
| 35 |
what I'm use to, in a gentoo_ish approach. |
| 36 |
|
| 37 |
Thanks to you and Paul for posting. |
| 38 |
Yes, I'll post the patches somewhere. Some may not be |
| 39 |
appropriate for gentoo mainline. |
| 40 |
|
| 41 |
|
| 42 |
James |
Archives