GIT development branches for packagers?
dridi.boukelmoune at gmail.com
Wed Jan 15 16:51:06 UTC 2014
On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch <vondruch at redhat.com> wrote:
> Dne 14.1.2014 21:41, Andrew Lutomirski napsal(a):
>> 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
>> - 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.
>> The normal GIT approach would be to develop on another branch and to
>> merge when I want to build a new revision (the Fedora equivalent of
>> tagging a new release). Should Fedora provide branches like
>> master-devel, f20-devel, etc that store pending changes?
>> Am I missing something really obvious here?
> Actually I'd really love to see some possibility for private branches.
> Now, it is possible to push whatever branch (take it literally) you have
> in your local git repo into dist-git, but there is no way how to delete
> it by myself.
> For example, I am using branches to keep my .spec file aligned with
> upstream development and I'd like to share it with other maintainers.
> But this .spec file should never build in Rawhide unless it is approved
> by FESCo.
> Could you please add support for private branches? I.e. the branch which
> starts by private- prefix could be pushed and deleted as well, non ff
> commit should be allowed. Actually, better would be if only master, fxx
> and elx are protected and others are unrestricted, but I am probably
> asking too much.
For private branches I'd rather see something along fas/branch.
With the '/' separator you can glob refspecs, and using your fas as a
prefix could enable automatic acls with less pain on the
infrastructure side (eg. allow anyone to manage and own private
branches at will).
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel