On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch <vondruch@xxxxxxxxxx> 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 >> changes. >> - 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? >> >> --Andy > > 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). Dridi > Vít > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
