Re: GIT development branches for packagers?
Kevin Fenzi wrote: There's happily no danger of running out of integers. Well, isn't there some technical limit? Does rpmvercmp work on arbitrarily long integers or is it limited to something like 4294967295? And is there some character limit on the Release tag? :-) (Now, to be fair, I don't think any of that would ever be an issue in practice.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
Dne 15.1.2014 18:12, Richard W.M. Jones napsal(a): On Wed, Jan 15, 2014 at 02:16:29PM +0100, Vít Ondruch wrote: 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. [...] Isn't it already possible to add branches? eg the kernel seems to have a whole lot of private-looking branches: http://pkgs.fedoraproject.org/cgit/kernel.git/refs/ Rich. Yes, as I said in the quote, you can just *add* branches, you cannot remove them, you cannot force them ... Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
Dne 15.1.2014 17:51, Dridi Boukelmoune napsal(a): On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch vondr...@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 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 Yes, that is a good idea, why not? Anything would help :) Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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
Re: GIT development branches for packagers?
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. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch vondr...@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 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
On Wed, Jan 15, 2014 at 02:16:29PM +0100, Vít Ondruch wrote: 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. [...] Isn't it already possible to add branches? eg the kernel seems to have a whole lot of private-looking branches: http://pkgs.fedoraproject.org/cgit/kernel.git/refs/ Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
/me wants the ability to push force on *private* branches 2014/1/15 Dridi Boukelmoune dridi.boukelmo...@gmail.com On Wed, Jan 15, 2014 at 2:16 PM, Vít Ondruch vondr...@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 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
GIT development branches for packagers?
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
On 14/01/14 20:41, 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. - 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? Committing spec changes without a subsequent build is a perfectly reasonable thing to do. When doing spec clean-up, I would normally bump the Release tag and add a changelog entry. This is essentially what happens when packages are being reviewed for inclusion in Fedora. -- Jamie Nguyen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
On Tue, 14 Jan 2014 12:41:42 -0800 Andrew Lutomirski l...@mit.edu 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: Sure. Note that you are welcome to build a new rawhide build at any time, so even if it's not that big a change, it's not a problem to do a build to just make sure everything is well, etc. - A provenpackager could kick off a rebuild for whatever reason (e.g. dependency soname bump). That will (I think) inadvertently include my changes. Yep. They would. But is that a problem? - 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. I would add a changelog entry and bump the release. There's happily no danger of running out of integers. 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? No. You could work in some local branch and merge back to Fedora, but in practice if you are the maintainer there shouldn't be much need... Am I missing something really obvious here? Not sure. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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. - 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
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. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GIT development branches for packagers?
Hi, On Tue, Jan 14, 2014 at 12:41:42PM -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? 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? You already have that branch: it is your local repo :-) Nobody forces you to push your changes before you are ready to do a build. And you can use remote branches as well; you just need to pass --dist XY to fedpkg for all operations, as it will not be able to recognize the release from your branch name. E.g.: git checkout -b f20-devel git push origin f20-devel:f20-devel # ... changes ... fedpkg --dist f20 local # ... check it builds ... git commit -am '...' git push D. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
