> On Tue, 9 Sep 2008, Jon Ciesla wrote: > >> >> > On Tue, 9 Sep 2008, Jon Ciesla wrote: >> > >> >> >> >> > Mike McGrath wrote: >> >> > >> >> > >> >> >> In fairness... you should be testing things before you commit them >> >> > >> >> > Of course. I've been hit by this a lot with local builds working, >> but >> >> > rawhide builds that fail (for whatever reason, new rpm, wierd build >> >> deps >> >> > breaking, etc...). >> >> >> >> I have issues, also, where something succeeds in a local build, is >> fine >> >> oin i386 mock, but dies in ppc, x86_64, etc. >> >> >> > >> > So why would you make a change to the spec file, without bumping the >> > release? Also there's an auditing GPL legal reason (IIRC) that we're >> > doing this now. The bottom line is this: >> > >> > Make change to a spec file. >> > >> > Bump release. >> >> Even it there's no successful build? Is the cvs log not retained, and >> useful for auditing purposes? >> >> > Its a simple workflow that provides an audit trail that we believe >> will >> > keep us in compliance with the GPL. force-tag is sort of nice to have >> I >> > guess, but release bumps happen all the time by everyone its not a >> high >> > barrier to get releases out. >> > >> > I'm not sure what else to say, its not going to happen guys unless you >> can >> > come up with a different audit trail that will keep us in compliance >> with >> > the GPL and satisfies legal. >> >> So is using TAG_OPTS=-F make tag a problem? >> > > AFAIK, yes it is. If if is, then can the Makefile be modified to prevent it, so that others who didn't know that stop doing it? > -Mike > -- novus ordo absurdum -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
