On 2015-10-12 14:29, Javier Domingo Cansino wrote: > While it works fine for packages, I don't think the pull request stuff > is very usable for OpenWrt core, which has a more centralized > development model. > One reason why we haven't moved the main repo to git yet is that we lose > the advantage of having revision numbers that propagate to the firmware, > even with builds from a forked repository where some commits have been > added on top. > If we do everything in git, we either have to constantly remember to tag > revisions, or we will lose valuable information when users report bugs > with forked repos. > I also happen to like linear history very much, and SVN enforces that ;) > > You can enforce linear history by denying history rewrites. It's what > they call now protected branches (IIRC), and I think you can really > enforce that. Also, you can create hooks to check for tagging info etc. > > I don't fully understand the 'remember to tag revision' thing. Right now, the revision number (r<something>) is really useful to figure out what particular openwrt version is being used, when people report bugs. The commit hash cannot be used as a replacement, since it might be one that isn't present in the official repo. When using tags as a starting point (via git describe), somebody has to create those tags, which is cumbersome (and would mean adding lots of useless ones).
> I still believe for our maintenance process it's a bad idea to maintain > the kernel as a separate git repository. With generic changes, it's easy > to lose track of what patch has been applied in which branch, and > syncing them can be annoying with rebases. > Also, pulling changes is going to be confusing for users as well, since > we will have to constantly rebase branches. > > > What I had in mind for the kernel consisted on some similar workflow to > the one gitlab uses for their stable branches. You have a branch for > each maintained kernel release, and you have all the commit's > cherry-picked from the master. Well, we have per-target kernel patches. Patches from different targets might conflict with each other, or might break unrelated targets. Dealing with that would mean either carefully reviewing every single target patch to avoid negative side effects for other targets, or maintaining one branch per target. For both variants, the amount of extra work this creates in my opinion vastly outweighs the benefits of using git for the kernel tree. > Of course, you can always use rebase and apply all the patches in order. > It is possible to have scripts that actually make sure every patch is > applied, letting you substract patch lists, etc. If we keep rebasing, people get confused when working on the tree and running git pull. > Making maintainable the support for several different versions of > kernel, each one on it's branch, forking from the official repo. I'm open to changing my mind if I see some compelling arguments, but right now I believe the extra maintenance cost vastly outweighs the potential benefits. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel