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