Re: GIT development branches for packagers?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <awilliam@xxxxxxxxxx> 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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux