On Thu, Jun 25, 2015 at 12:02 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: >> Will the exploded tree go away if we don't change to this model? Also >> unclear. I'd hesitantly say it would stick around, but it might >> change in the way it is created and published. >> >> I'm sure there will be more questions, so please ask away. Looking >> forward to hearing other's thoughts. > > So. Given that it has been a week and we've heard nothing back, I'm > going to assume that either nobody cares how we maintain our tree > (which tbh is a fair point of view), or all of this sounds great to > everyone. > > So here is our plan going forward. We need a place to try this out to > make sure it is actually a net positive for us. We intend to drive > the master branch in pkg-git (rawhide) using the tree and scripts for > the 4.2 merge window. What that means for other people is basically > this: The team and I were discussing this topic yesterday, and it really isn't working as we'd hoped. The exploded tree is great for rebasing patches. It's trivial and integrated into the workflow just fine. However, taking that source code and producing an RPM is pretty cumbersome now. The scripts work, but they can be fragile in certain places. It's also still double commits in the long run, one in pkg-git and another in the exploded tree for all the junk that is needed for tracking and updating pkg-git. Over time, a 'git rebase' call will take forever as those commits pile up because they're never going upstream. Thorsten and Peter also pointed out that changes "sneak" into pkg-git and only are mentioned in the RPM changelog, not as separate commits. So going from exploded tree -> kernel.spec just isn't paying off. In the spirit of fail fast, we're probably going to scrap this experiment in the next few days. However, we still want the exploded tree available so we're going to look at making it easier to go from kernel.spec -> exploded tree. Primarily, we are likely going to change how we apply patches in the spec file to use git-am. What does this mean for contributors? a) Your patch _must_ conform to something git-am accepts. Ironically, git-show does not produce such a patch so if you are using a git tree to create a patch, use git format-patch. Plain diff won't work either. It needs a From: a Date: and a Subject: at a minimum. b) The spec will undergo some surgery and you will no longer need to specify an ApplyPatch line. This means the order of patch applications is determined by the order they are listed in the PatchXXX section. Do not change this order randomly. c) 'fedpkg prep' time on a fresh tree will take a bit longer. Subsequent 'fedpkg prep' runs will be faster, but still a bit slower than today's method. Creating the initial git tree is somewhat time consuming. Still, we're talking on the order of just over a minute for a fresh tree, and about 40 seconds for subsequent runs. This is not world ending. This will be tried in rawhide to start. Aside from the above changes, the workflow will go back to what we had for years. I'll look at creating the exploded tree on the side and it shouldn't impact anyone aside from the above requirements. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
