On Jan 16, 2014 10:19 AM, "Andrew Lutomirski" <l...@mit.edu> wrote: > > On Thu, Jan 16, 2014 at 10:15 AM, Adam Williamson <awill...@redhat.com> wrote: > > On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote: > >> On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote: > >> > On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson < awill...@redhat.com> wrote: > >> > > On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote: > >> > >> I have some trivial cleanups I want to make to a package a maintain. > >> > >> These cleanups are trivial enough that I don't think they're worth a > >> > >> new build. Should I commit them to the master branch? If so, I can > >> > >> imagine a couple of issues: > >> > >> > >> > >> - A provenpackager could kick off a rebuild for whatever reason (e.g. > >> > >> dependency soname bump). That will (I think) inadvertently include my > >> > >> changes. > >> > > > >> > > Yes, this will happen. Why do you think it's a problem, though? If your > >> > > changes are correct but you just don't think it's worth doing a new > >> > > build simply for them, why is it a problem if they get pulled in when > >> > > someone does another build for some *other* (presumably appropriate) > >> > > reason? It would seem like that's just what you'd want to happen. > >> > > >> > Depends how well I've tested. I'd like to imagine that I never commit > >> > anything broken anywhere, but this is empirically incorrect -- I break > >> > development branches on a semi-regular basis. I guess I'll just have > >> > to be more cautious w/ Fedora :) > >> > > >> > > > >> > >> - I need to think about whether to add a changelog entry or not. If > >> > >> not, those changes might be included silently. If yes, then I need to > >> > >> think about what to do about the revision number. > >> > > > >> > > One thing I've seen done is to add the line that actually describes the > >> > > change, above the last date/builder/NEVR line, *without* adding a new > >> > > line identifying the new build, date and builder. That way when someone > >> > > comes along and does a new build, they ought to see what should happen - > >> > > they should roll your partial entry into the entry they add for the > >> > > build. > >> > > >> > That would work. > >> > >> I'd recommend rather the approach suggested by Kevin. Bump the release > >> and include a regular changelog entry. Just do not build. There is no > >> rule that all changeloged entries must be really built. > > > > I have found this kind of phantom release a bit annoying in some really > > esoteric situations - when the changelog indicates that there was, say, > > a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of > > the time it's not going to be a problem, yeah. > > I can imagine this annoying anyone who does a mass rebuilt or a > similar set of rebuilds that aren't intended (by the one doing the > rebuilds) to change anything other than dependencies and, say, the > compiler version. Sure, this *shouldn't* cause a problem if everyone > is appropriately careful, but I'm hesitant to trust things that > transparently deploy code when no has has explicitly asked for a > change to be deployed. >
Yeah, I wouldn't trust my un built changes either :-). But I think I'd go with another of Kevin's options - go ahead and build in rawhide. There's really no downside to getting your this type of change out there sooner rather than later. -Toshio
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
