Re: drop inheritance at f19 branch point?
Dne 25.1.2013 00:02, Kevin Fenzi napsal(a): On Thu, 24 Jan 2013 15:09:57 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 24.1.2013 14:40, Bruno Wolff III napsal(a): On Thu, Jan 24, 2013 at 13:06:21 +0100, Vít Ondruch vondr...@redhat.com wrote: It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. Every time you don't do an update in rawhide and rely on inheritence, the changes that go out to updates-testing don't go to rawhide, leaving rawhide behind the previous release. That is not failure of inheritance Actually, the true is that the tag should inherit from updates-testing. I already questioned this behavior before, unfortunately can't remember where and why :/ Yeah, the problem with inheriting from updates-testing is that updates-testing can 'go back'. You could have a bad updates-testing build and unpush it and it goes away. So don't inherit it but let bodhi tag it not just fnn-updates-testing but also fnn+ Users who have it installed have to figure this out and manually downgrade. That is not true, since broken build will be always replaced by newer one. This applies especially for rawhide. Additionally, things that land in rawhide land in the buildroot, so, updates-testing branched updates could break the rawhide buildroot, or cause problems for rawhide built packages, then disappear. This would be solved by two tags mentioned above. Vít Rawhide doesn't go back in versions ever, so this would break that. You could argue that if it's something updates-testing people can do, rawhide people could too, but I fear if we changed that policy people would abuse it in rawhide. So, I for one wouldn't want to change the rawhide policy there. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, Jan 26, 2013 at 20:27:55 -0700, Orion Poplawski or...@cora.nwra.com wrote: Doing more than one asks in certain situations sounds bad, but how about: fn: fedpkg build --and-newer Does: fedpkg build loop: fedpkg switch-branch fn+1 (or master) git merge fn git push fedpkg build goto loop: unless at master It could also take --nowait. If there was an error at any point it would abort (assuming git gives some non-zero return codes). I prefer to do my updates starting at master and working backwards. I am not sure what the split is for this amoung our developers. It would be nice to have a check that the merges are all fast forwards. If not, I am not sure you want this happening automatically. This is likely to drag change log entries along that don't apply, that might on rare occasions cause some confusion. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, 26 Jan 2013 23:34:57 -0500 Ben Boeckel maths...@gmail.com wrote: On Sat, Jan 26, 2013 at 19:48:25 -0700, Kevin Fenzi wrote: Seems complex. For the logic, the delay part, or a likely implementation? Yes. ;) Would it run on the client or on the server side? I was thinking server side at first, but maybe we could have fedpkg detect this and ask if it's wanted when the build is requested (possibly with a per-package and global setting)? That sounds really busy... fedpkg build Do you want to also build this for $branch ? If I did, wouldn't I? It also seems... unexpected. You ask for a build, but it does commits and builds behind your back? As written above, it wouldn't write any new commits (--ff-only should enforce that). It would only update branches and request builds along with a notice of intent. Sure, it doesn't commit that was a poor phrasing. It however does merge and build things you didn't ask it to build. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, 26 Jan 2013 20:27:55 -0700 Orion Poplawski or...@cora.nwra.com wrote: Doing more than one asks in certain situations sounds bad, but how about: fn: fedpkg build --and-newer Does: fedpkg build loop: fedpkg switch-branch fn+1 (or master) git merge fn git push fedpkg build goto loop: unless at master It could also take --nowait. If there was an error at any point it would abort (assuming git gives some non-zero return codes). Sure, might work. I'm not a fedpkg maintainer, so it would fall on them if they would accept this or want to work on it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, 26 Jan 2013 05:49:25 + (UTC)
Ben Boeckel maths...@gmail.com wrote:
Looking at this, how about a simple rule about what makes a fedpkg
build cascade up: While the next higher branch has the same version,
but older pre-dist release number, merge --ff-only and trigger a
build if one is not created within an hour of the current build
completing. With this, a bump in the form %{?dist}.1 wouldn't trigger
a build (since this implies that it's a release-specific fix) and a
build on fX won't trigger an fX+1 build if there's a version gap
between them.
Seems complex. Would it run on the client or on the server side?
It also seems... unexpected. You ask for a build, but it does commits
and builds behind your back?
Sending an email halfway between the end of the build and automation
of intent would probably be useful. If the next higher branch is
updated manually and no build appears, this could be interpreted as a
I know what I'm doing indication and cancel the automation.
Thoughts?
That would need some kind of queue...
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On 01/25/2013 10:49 PM, Ben Boeckel wrote:
Looking at this, how about a simple rule about what makes a fedpkg build
cascade up: While the next higher branch has the same version, but older
pre-dist release number, merge --ff-only and trigger a build if one is
not created within an hour of the current build completing. With this, a
bump in the form %{?dist}.1 wouldn't trigger a build (since this implies
that it's a release-specific fix) and a build on fX won't trigger an
fX+1 build if there's a version gap between them.
Sending an email halfway between the end of the build and automation of
intent would probably be useful. If the next higher branch is updated
manually and no build appears, this could be interpreted as a I know
what I'm doing indication and cancel the automation.
Thoughts?
Doing more than one asks in certain situations sounds bad, but how about:
fn: fedpkg build --and-newer
Does:
fedpkg build
loop:
fedpkg switch-branch fn+1 (or master)
git merge fn
git push
fedpkg build
goto loop: unless at master
It could also take --nowait. If there was an error at any point it
would abort (assuming git gives some non-zero return codes).
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, Jan 26, 2013 at 19:48:25 -0700, Kevin Fenzi wrote: Seems complex. For the logic, the delay part, or a likely implementation? Would it run on the client or on the server side? I was thinking server side at first, but maybe we could have fedpkg detect this and ask if it's wanted when the build is requested (possibly with a per-package and global setting)? It also seems... unexpected. You ask for a build, but it does commits and builds behind your back? As written above, it wouldn't write any new commits (--ff-only should enforce that). It would only update branches and request builds along with a notice of intent. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24 Jan, 2013 at 02:41:50 GMT, Kevin Fenzi wrote:
% bodhi -L systemd
f16-updates systemd-37-25.fc16
f16-updates-candidate systemd-37-25.fc16
f16-updates-testing systemd-37-25.fc16
f17-updates-candidate systemd-44-22.fc17
f17-updates-testing systemd-44-23.fc17
f17-updates systemd-44-23.fc17
f18-updates-testing systemd-195-15.fc18
f18-updates systemd-197-1.fc18.1
f18-updates-candidate systemd-195-14.fc18
Looking at this, how about a simple rule about what makes a fedpkg build
cascade up: While the next higher branch has the same version, but older
pre-dist release number, merge --ff-only and trigger a build if one is
not created within an hour of the current build completing. With this, a
bump in the form %{?dist}.1 wouldn't trigger a build (since this implies
that it's a release-specific fix) and a build on fX won't trigger an
fX+1 build if there's a version gap between them.
Sending an email halfway between the end of the build and automation of
intent would probably be useful. If the next higher branch is updated
manually and no build appears, this could be interpreted as a I know
what I'm doing indication and cancel the automation.
Thoughts?
--Ben
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24 Jan 2013 04:31:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: You know, I really dislike packaging things. I love hacking. If I package something then that's an ugly side effect of what I really want to do. And thus I'd spend as little time on packaging as I can. Ask for help with the packaging. Do what most upstream devs do. Write code. -- Regards, Frank ln -s http//www.frankly3d.com http://www.frankly3d.eu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Dne 23.1.2013 22:38, Lennart Poettering napsal(a): On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. After branching I usually focus pretty much exclusively on the distribution that is about to get finished, and you can be sure I am not interested at all in continously having to update that other distro that I don't use, that barely anybody uses at that time as well. If you really turn off inheritance that basically means you can be sure that Rawhide doesn't get updated systemd packages at all anymore... I very much agree with this. I'd propose instead that mass branching goes away entirely, and the master branch too. Instead, people focus developing on the branch f19, and then branch that off to f20 when they are ready to, or actually have to make a change that they wouldn't apply to f19. Then 6 months later when they think that their f20 package is in a good shape for release and it is time to work on Fedora 21, they fork f21 off f20 and so on. That places the focus on polishing, and requires manual branching when people want to make non-polishing changes, and that's good that way. The only way mass-branching would then happen is on gcc rebuilds, but the branching is merely a side effect then. Rawhide would always contain the packages from the newest branch in the repo. And I disagree with this proposal. It is mixed for me. Sometimes, I'd like to update in Rawhide, especially if the freeze is taking long, while in other cases, I need to do some bugfix in my packages which is found during testing and needs to be applied to both branches. In this case, the inheritance saves my work, while disabling the inheritance would always duplicate my work. So the current state is ideal from my POV. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, Jan 24, 2013 at 10:38:00AM +0100, Vít Ondruch wrote: And I disagree with this proposal. It is mixed for me. Sometimes, I'd like to update in Rawhide, especially if the freeze is taking long, while in other cases, I need to do some bugfix in my packages which is found during testing and needs to be applied to both branches. In this case, the inheritance saves my work, while disabling the inheritance would always duplicate my work. So the current state is ideal from my POV. It doesn't duplicate your work, although it increases it a little. If you keep the history of master and the fX branches consistent, and use 'fedpkg clone -B', then what you actually have to do is: - make the change in package/master - fedpkg push fedpkg build --nowait - cd ../f18 - git pull ../master - fedpkg push fedpkg build --nowait The only extra work here is an extra pull and build. The flip side of this is that when you *don't* build in Rawhide you potentially push work and breakage to somebody else. Your package may not build in Rawhide, leaving someone else to find that out when they try to rebuild it or do a mass rebuild. And inheritance sometimes doesn't work or does something unexpected, and others have to pick up the pieces. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Dne 24.1.2013 11:22, Richard W.M. Jones napsal(a): On Thu, Jan 24, 2013 at 10:38:00AM +0100, Vít Ondruch wrote: And I disagree with this proposal. It is mixed for me. Sometimes, I'd like to update in Rawhide, especially if the freeze is taking long, while in other cases, I need to do some bugfix in my packages which is found during testing and needs to be applied to both branches. In this case, the inheritance saves my work, while disabling the inheritance would always duplicate my work. So the current state is ideal from my POV. It doesn't duplicate your work, although it increases it a little. If you keep the history of master and the fX branches consistent, and use 'fedpkg clone -B', then what you actually have to do is: - make the change in package/master - fedpkg push fedpkg build --nowait - cd ../f18 - git pull ../master - fedpkg push fedpkg build --nowait The only extra work here is an extra pull and build. I know. The flip side of this is that when you *don't* build in Rawhide you potentially push work and breakage to somebody else. Your package may not build in Rawhide, leaving someone else to find that out when they try to rebuild it or do a mass rebuild. And inheritance sometimes doesn't work or does something unexpected, and others have to pick up the pieces. It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On 01/24/2013 04:31 AM, Lennart Poettering wrote: On Thu, 24.01.13 03:54, Till Maas (opensou...@till.name) wrote: On Wed, Jan 23, 2013 at 10:38:30PM +0100, Lennart Poettering wrote: On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. Except that doing an update for rawhide does cost nearly nothing compared to the other branches (no bodhi update needs to be created). If you just update the master branch you can easily let the computer do all the work to also build for e.g. f18: for b in master f18; do fedpkg switch-branch $b; git merge master; git push; fedpkg build --nowait; done Let's not forget that that's hardly a fun line to type and remember, and I have to keep in mind how branches are set up (i.e. what is branched and what is not) and that information is coded in that line, so it's not the total nobrainer, I actually have to think each time... You know, I really dislike packaging things. I love hacking. If I package something then that's an ugly side effect of what I really want to do. And thus I'd spend as little time on packaging as I can. Don't make it any harder, by forcing me to remember, adjust and issue arcane command lines each time. Updating packages isn't fun. Instead of making this less work for humans, and more for computers you are doing just the opposite and leave more the humans and less to computers. Lennart The question was if maintainers would like to see a build by someone else if they don't want to or forgot to build it in master ;-) I guess you are fine with that. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, Jan 24, 2013 at 13:06:21 +0100, Vít Ondruch vondr...@redhat.com wrote: It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. Every time you don't do an update in rawhide and rely on inheritence, the changes that go out to updates-testing don't go to rawhide, leaving rawhide behind the previous release. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, Jan 24, 2013 at 01:06:21PM +0100, Vít Ondruch wrote: Dne 24.1.2013 11:22, Richard W.M. Jones napsal(a): The flip side of this is that when you *don't* build in Rawhide you potentially push work and breakage to somebody else. Your package may not build in Rawhide, leaving someone else to find that out when they try to rebuild it or do a mass rebuild. And inheritance sometimes doesn't work or does something unexpected, and others have to pick up the pieces. It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. In the sense that it's better for the maintainer to fix the Rawhide build rather than someone else much later on, I think we agree. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Dne 24.1.2013 14:40, Bruno Wolff III napsal(a): On Thu, Jan 24, 2013 at 13:06:21 +0100, Vít Ondruch vondr...@redhat.com wrote: It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. Every time you don't do an update in rawhide and rely on inheritence, the changes that go out to updates-testing don't go to rawhide, leaving rawhide behind the previous release. That is not failure of inheritance Actually, the true is that the tag should inherit from updates-testing. I already questioned this behavior before, unfortunately can't remember where and why :/ Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24.01.13 08:27, Frank Murphy (frankl...@gmail.com) wrote: On Thu, 24 Jan 2013 04:31:03 +0100 Lennart Poettering mzerq...@0pointer.de wrote: You know, I really dislike packaging things. I love hacking. If I package something then that's an ugly side effect of what I really want to do. And thus I'd spend as little time on packaging as I can. Ask for help with the packaging. Do what most upstream devs do. Write code. Right, because packagers are a dime a dozen and like to be on call all the time so that if I want an update I can have one within 15min, right? The thing is that the build in koji is actually relevant to my workflow. I want to know if it worked, and I tend to look at the compile output of the builds quite frequently, for example to check if the archs i don't work on myself work on compiled correctly or if there is any compile spew... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24.01.13 10:22, Richard W.M. Jones (rjo...@redhat.com) wrote: On Thu, Jan 24, 2013 at 10:38:00AM +0100, Vít Ondruch wrote: And I disagree with this proposal. It is mixed for me. Sometimes, I'd like to update in Rawhide, especially if the freeze is taking long, while in other cases, I need to do some bugfix in my packages which is found during testing and needs to be applied to both branches. In this case, the inheritance saves my work, while disabling the inheritance would always duplicate my work. So the current state is ideal from my POV. It doesn't duplicate your work, although it increases it a little. If you keep the history of master and the fX branches consistent, and use 'fedpkg clone -B', then what you actually have to do is: - make the change in package/master - fedpkg push fedpkg build --nowait - cd ../f18 - git pull ../master - fedpkg push fedpkg build --nowait The --nowait doesn't really work. I do care if the build I did finished successfully. With the lines above you kinda suggest that people shouldn't care about build results... Just updating my spec file and issuing a build request in fire and forget doesn't work. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, Jan 24, 2013 at 06:07:08PM +0100, Lennart Poettering wrote: On Thu, 24.01.13 10:22, Richard W.M. Jones (rjo...@redhat.com) wrote: On Thu, Jan 24, 2013 at 10:38:00AM +0100, Vít Ondruch wrote: And I disagree with this proposal. It is mixed for me. Sometimes, I'd like to update in Rawhide, especially if the freeze is taking long, while in other cases, I need to do some bugfix in my packages which is found during testing and needs to be applied to both branches. In this case, the inheritance saves my work, while disabling the inheritance would always duplicate my work. So the current state is ideal from my POV. It doesn't duplicate your work, although it increases it a little. If you keep the history of master and the fX branches consistent, and use 'fedpkg clone -B', then what you actually have to do is: - make the change in package/master - fedpkg push fedpkg build --nowait - cd ../f18 - git pull ../master - fedpkg push fedpkg build --nowait The --nowait doesn't really work. I do care if the build I did finished successfully. With the lines above you kinda suggest that people shouldn't care about build results... Just updating my spec file and issuing a build request in fire and forget doesn't work. It sends you an email when it's done. 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
Re: drop inheritance at f19 branch point?
On Thu, 24 Jan 2013 15:09:57 +0100 Vít Ondruch vondr...@redhat.com wrote: Dne 24.1.2013 14:40, Bruno Wolff III napsal(a): On Thu, Jan 24, 2013 at 13:06:21 +0100, Vít Ondruch vondr...@redhat.com wrote: It definitely depends on package. I should be the one who knows about my packages the best if there is some breaking potential. Every time you don't do an update in rawhide and rely on inheritence, the changes that go out to updates-testing don't go to rawhide, leaving rawhide behind the previous release. That is not failure of inheritance Actually, the true is that the tag should inherit from updates-testing. I already questioned this behavior before, unfortunately can't remember where and why :/ Yeah, the problem with inheriting from updates-testing is that updates-testing can 'go back'. You could have a bad updates-testing build and unpush it and it goes away. Users who have it installed have to figure this out and manually downgrade. Additionally, things that land in rawhide land in the buildroot, so, updates-testing branched updates could break the rawhide buildroot, or cause problems for rawhide built packages, then disappear. Rawhide doesn't go back in versions ever, so this would break that. You could argue that if it's something updates-testing people can do, rawhide people could too, but I fear if we changed that policy people would abuse it in rawhide. So, I for one wouldn't want to change the rawhide policy there. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
drop inheritance at f19 branch point?
I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. After branching I usually focus pretty much exclusively on the distribution that is about to get finished, and you can be sure I am not interested at all in continously having to update that other distro that I don't use, that barely anybody uses at that time as well. If you really turn off inheritance that basically means you can be sure that Rawhide doesn't get updated systemd packages at all anymore... I'd propose instead that mass branching goes away entirely, and the master branch too. Instead, people focus developing on the branch f19, and then branch that off to f20 when they are ready to, or actually have to make a change that they wouldn't apply to f19. Then 6 months later when they think that their f20 package is in a good shape for release and it is time to work on Fedora 21, they fork f21 off f20 and so on. That places the focus on polishing, and requires manual branching when people want to make non-polishing changes, and that's good that way. The only way mass-branching would then happen is on gcc rebuilds, but the branching is merely a side effect then. Rawhide would always contain the packages from the newest branch in the repo. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, Jan 23, 2013 at 10:20 PM, Kevin Fenzi ke...@scrye.com wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? This causes more problems (and work!) to solve some corner cases so please don't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, Jan 23, 2013 at 22:38:30 +0100, Lennart Poettering mzerq...@0pointer.de wrote: Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. What if there were was an automated process that did the rawhide build? I'd propose instead that mass branching goes away entirely, and the master branch too. Instead, people focus developing on the branch f19, and then branch that off to f20 when they are ready to, or actually have to make a change that they wouldn't apply to f19. Then 6 months later when they think that their f20 package is in a good shape for release and it is time to work on Fedora 21, they fork f21 off f20 and so on. That places the focus on polishing, and requires manual branching when people want to make non-polishing changes, and that's good that way. The only way mass-branching would then happen is on gcc rebuilds, but the branching is merely a side effect then. Rawhide would always contain the packages from the newest branch in the repo. This is kind of how things work now at a repo level. There are a couple of problems though. Sometimes the changes have ripple effects and other packages also need to get rebuilt for rawhide. The other is that fixes in updates-testing aren't inherited into rawhide. During freezes this can leave rawhide broken for a long time. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Bruno Wolff III br...@wolff.to writes: On Wed, Jan 23, 2013 at 22:38:30 +0100, Lennart Poettering mzerq...@0pointer.de wrote: I'd propose instead that mass branching goes away entirely, and the master branch too. This is kind of how things work now at a repo level. There are a couple of problems though. Sometimes the changes have ripple effects and other packages also need to get rebuilt for rawhide. The other is that fixes in updates-testing aren't inherited into rawhide. During freezes this can leave rawhide broken for a long time. There's a pretty fundamental reason why Lennart's proposal doesn't work: even if a given package is source-wise identical between F-n and F-n+1, that doesn't mean it would be binary-identical. Either the packages it depends on or the build toolchain might well have changed since F-n was split off. IMO, maintainers who abdicate their responsibility to rebuild in rawhide are being unhelpful to the rest of the project, first by possibly supplying incompatible old packages and second by not exercising the rawhide build environment. Is it really so painful to launch an extra fedpkg build in the master branch? If you're keeping master and the newest release branch in exact sync, it's surely trivial to script something that will duplicate your commits in one branch into the other and then launch the extra build. Fire-and-forget once a day or whatever, and everyone's happy. (Of course, if the rebuild in master fails, then you have more work to do ... but it's work you'd have had to face up to soon anyway.) regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, 23.01.13 20:59, Tom Lane (t...@redhat.com) wrote: Bruno Wolff III br...@wolff.to writes: On Wed, Jan 23, 2013 at 22:38:30 +0100, Lennart Poettering mzerq...@0pointer.de wrote: I'd propose instead that mass branching goes away entirely, and the master branch too. This is kind of how things work now at a repo level. There are a couple of problems though. Sometimes the changes have ripple effects and other packages also need to get rebuilt for rawhide. The other is that fixes in updates-testing aren't inherited into rawhide. During freezes this can leave rawhide broken for a long time. There's a pretty fundamental reason why Lennart's proposal doesn't work: even if a given package is source-wise identical between F-n and F-n+1, that doesn't mean it would be binary-identical. Either the packages it depends on or the build toolchain might well have changed since F-n was split off. Well, I fully acknowledge that haveing the same sources for the distros should not imply to have the same binaries. However, that's really something to solve on the build scripts level. Or in other words, as soon as I type fedpkg build my package should be built on all newer distributions too (except of course there's an explicit branch for that). For a very static package this would even allow people to never bother with branching again. You could stay forever on your old branch, and with a single fedpkg built you could update the three supported distros all at once. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24 Jan 2013 03:22:18 +0100 Lennart Poettering mzerq...@0pointer.de wrote: Well, I fully acknowledge that haveing the same sources for the distros should not imply to have the same binaries. However, that's really something to solve on the build scripts level. Or in other words, as soon as I type fedpkg build my package should be built on all newer distributions too (except of course there's an explicit branch for that). Except thats almost never what you want. ;) To use systemd as an example: % bodhi -L systemd f16-updates systemd-37-25.fc16 f16-updates-candidate systemd-37-25.fc16 f16-updates-testing systemd-37-25.fc16 f17-updates-candidate systemd-44-22.fc17 f17-updates-testing systemd-44-23.fc17 f17-updates systemd-44-23.fc17 f18-updates-testing systemd-195-15.fc18 f18-updates systemd-197-1.fc18.1 f18-updates-candidate systemd-195-14.fc18 The common case here in f16 and f17 (and often f18, but not right now since you are pushing 197 there too) is that you only want to build for the branch you want to build for. The branched/rawhide case is the exception that happens for 1/2 or so of the time, and only affects those two branches. For a very static package this would even allow people to never bother with branching again. You could stay forever on your old branch, and with a single fedpkg built you could update the three supported distros all at once. There's a lot of logistical issues with that. I understand where you are coming from conceptually, but we don't have anything that would behave like that right now, nor do I think we have people interested in redoing all of our setup for this. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Wed, Jan 23, 2013 at 10:38:30PM +0100, Lennart Poettering wrote: On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. Except that doing an update for rawhide does cost nearly nothing compared to the other branches (no bodhi update needs to be created). If you just update the master branch you can easily let the computer do all the work to also build for e.g. f18: for b in master f18; do fedpkg switch-branch $b; git merge master; git push; fedpkg build --nowait; done Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Thu, 24.01.13 03:54, Till Maas (opensou...@till.name) wrote: On Wed, Jan 23, 2013 at 10:38:30PM +0100, Lennart Poettering wrote: On Wed, 23.01.13 14:20, Kevin Fenzi (ke...@scrye.com) wrote: I know we have discussed this before, but I've filed a FESCo ticket to ask them one way or another about the issue: https://fedorahosted.org/fesco/ticket/1005 Feedback welcome. If you are a maintainer who doesn't have a minute to do a rawhide build during the branched cycle, would you be open to someone else doing those builds for you? Oh, yeah, let's make it even more work to update a package. Because we have so much free time, let's let humans do what computers could do better. Except that doing an update for rawhide does cost nearly nothing compared to the other branches (no bodhi update needs to be created). If you just update the master branch you can easily let the computer do all the work to also build for e.g. f18: for b in master f18; do fedpkg switch-branch $b; git merge master; git push; fedpkg build --nowait; done Let's not forget that that's hardly a fun line to type and remember, and I have to keep in mind how branches are set up (i.e. what is branched and what is not) and that information is coded in that line, so it's not the total nobrainer, I actually have to think each time... You know, I really dislike packaging things. I love hacking. If I package something then that's an ugly side effect of what I really want to do. And thus I'd spend as little time on packaging as I can. Don't make it any harder, by forcing me to remember, adjust and issue arcane command lines each time. Updating packages isn't fun. Instead of making this less work for humans, and more for computers you are doing just the opposite and leave more the humans and less to computers. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
Kevin Fenzi píše v St 23. 01. 2013 v 19:41 -0700: On Thu, 24 Jan 2013 03:22:18 +0100 Lennart Poettering mzerq...@0pointer.de wrote: Well, I fully acknowledge that haveing the same sources for the distros should not imply to have the same binaries. However, that's really something to solve on the build scripts level. Or in other words, as soon as I type fedpkg build my package should be built on all newer distributions too (except of course there's an explicit branch for that). Except thats almost never what you want. ;) To use systemd as an example: % bodhi -L systemd f18-updates-testing systemd-195-15.fc18 f18-updates systemd-197-1.fc18.1 f18-updates-candidate systemd-195-14.fc18 the updates-testing vs. updates problem exists in more packages ( can be in hundreds), it probably again a bodhi issue, when there were multiple updates created during the final freeze period and only the latest one was tagged as 0-day update and the older ones were not untagged Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
