On Thu, Jul 09, 2015 at 07:42:08AM -0400, Josh Boyer wrote: > On Thu, Jun 25, 2015 at 12:02 PM, Josh Boyer <jwbo...@fedoraproject.org> > 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.
Hi Josh, Thanks for the effort! Sad to hear it isn't working out, but I understand your reasons. While it is still fresh in your mind, can I ask a few questions for curiousity. Not that submodules is a good solution (from what I hear) but would a solution like that (if made easier) work for those fedora scripts? The idea would be a rebase and a single commit on top to add the submodule-like directory/area that pulls in a separate tree full of those changes? This would sidestep the rebase growing larger over time, sort of (one initial commit, but a growing set of commits brought in later??). It might address the 'sneaky' changes problem too. The only thing it doesn't handle is the extra Fedora kernel patches themselves that is carried (but I think you have that minimized and under control anyway). I don't expect you to hold your breathe for that solution to arise, but if it did, would it help do you think? Cheers, Don > > 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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/kernel _______________________________________________ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
