On Tue, Sep 09, 2008 at 08:53:03PM -0500, Dennis Gilmore wrote: >On Tuesday 09 September 2008 08:21:30 pm Josh Boyer wrote: >> On Tue, Sep 09, 2008 at 05:31:35PM -0500, Dennis Gilmore wrote: >> >> Because that's what the kernel uses and why they don't need force-tag. >> >> And even that doesn't completely eliminate the need for force-tag, >> >> because the mistake could be somewhere other than the specfile, e.g. a >> >> patch you forgot to cvs add. >> > >> >which is why I want make tag to check that all patches and sources are >> >commited to cvs before doing the tag. >> >> That's pretty hard to enforce and it should be run by FESCo before being >> implemented because it impacts the work flow of our packagers. > >checking that the patches and sources referenced in the spec file are checked >into cvs? it will not effect workflow other than making sure that everything is >commited. How exactly do you plan on doing that? In my off-the-top-of-my-head guestimation, you'd have to: 1) Make sure <package>.spec is committed and there are no local changes 2) Parse <package>.spec file to determine PatchNN and SourceNN filenames. 3) Taking into account that we use a lookaside-cache, make sure that all patches and sources are in CVS and are not locally modified. 4) Do the tag. That seems pretty involved. I can't see another valid way to do it though. You don't want to just blindly say something like "if a file that ends in .patch isn't added to CVS, fail the tag" because not all patches end in .patch or .diff and it's still valid to have un-added and un-committed patches in a local CVS checkout while doing a tag if they aren't listed in the SPEC file. There could be even cases where it's valid to have a modified patch file that isn't committed while doing the tag. So yes, I think you need to outline your plan and how you're going to accomplish what you are trying and run it past FESCo before making the change. It may be that we just say "sure, sounds great." It may be that FESCo says "hm. We need to change XX or YY." Either way, it has impacts to packagers and it needs to be run past FESCo. josh -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
