> 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? > -Mike > -- novus ordo absurdum -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
