| 1 |
On 12/01/2010 01:16 PM, Diego Elio Pettenò wrote: |
| 2 |
> Il giorno mer, 01/12/2010 alle 19.05 +0100, Thomas Kahle ha scritto: |
| 3 |
>> |
| 4 |
>> |
| 5 |
>> I agree, comments within the ebuild are practically invisible to |
| 6 |
>> archteams (at least to me for x86). But also running repoman is |
| 7 |
>> usually |
| 8 |
>> the final step, right before committing. The place for comments that |
| 9 |
>> need to be considered during archtesting would be right in the stable |
| 10 |
>> request bug. This is where I usually start. |
| 11 |
> |
| 12 |
> This is where I usually try to provide them; it's a bit more complex |
| 13 |
> when users require the stable themselves, or when new developers are |
| 14 |
> replacing the old ones. |
| 15 |
|
| 16 |
Agreed on all points. Ideal behavior is to provide comments in the bug. |
| 17 |
However, if that doesn't happen then this comment will give a warning |
| 18 |
to the arch team before they inadvertently shoot themselves in the foot. |
| 19 |
|
| 20 |
> |
| 21 |
>> |
| 22 |
>> If I do normal build tests first and then find they have been in vain |
| 23 |
>> when running repoman, then I wasted cycles for the build tests. I'm |
| 24 |
>> unsure if this would apply to your original example, though. |
| 25 |
>> |
| 26 |
> I sincerely expect(ed) a repoman scan of the ebuild to be done after |
| 27 |
> tweaking keywords to ensure all the deps are stable already, thus why I |
| 28 |
> asked it to be printed on scan. |
| 29 |
> |
| 30 |
|
| 31 |
So, my typical stable workflow is: |
| 32 |
|
| 33 |
Install package, after overriding keywords/etc in /etc/portage. |
| 34 |
Test package and satisfy myself that it is OK. |
| 35 |
From CVS tree, cvs update, ekeyword, echangelog, repoman manifest, |
| 36 |
repoman scan, repoman commit. |
| 37 |
|
| 38 |
All the testing typically takes place well before I've touched an ebuild |
| 39 |
or run repoman. |
| 40 |
|
| 41 |
However, I don't see this as a big deal. Right now I shoot myself in |
| 42 |
the foot and make a bunch of users upset if I don't know about something |
| 43 |
when I stable a package. The enhancement causes me to potentially waste |
| 44 |
some of my time, but less than if I have a big mess to clean up. The |
| 45 |
ideal solution as all agree is to have the package maintainer point |
| 46 |
things out in the STABLEREQ. |
| 47 |
|
| 48 |
Rich |
Archives