> > 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). > The tags would be the major versions and RCs. I don't believe other tags should be used.
Apart from that, I understand that if someone cloned the SVN repo (full svn history), created it's own server, and developed on top of a given revision X, the same problem would arise. I don't find this as a valid argument because that's up to the user. Either you fork from official owrt and note down the commit you forked in to give as a reference, or you provide full access to your source code, where you can actually see when it forked through git merge-base --fork-point. And of course, you can always automatically generate with help from git-describe a relative revision from the fork-point. Anyway, it would be up to the forkers to decide whether they want to rebase their tree or merge your tree. 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. > > I believe that we could find a mix between per kernel version patches and per target patches. Probably the best would be to treat the openwrt kernel as a project forking from linux-stable (I believe it's the tarballs you are currently using), and use that owrt kernel as a base to apply the per target patches (at the end, each target has it's own specific patches). I find it as repackaging the same project with different patches to add functionality. 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. > My proposal of steps to migrate to git would be. 1) openwrt to git, maintaining even the workflow as it is, giving time to deal with all the differences to svn (such as the relative revision crafting etc). Once everyone is comfortable with the git based hosting, I would go for 2) adapting the workflow to the tools git provides. We would be talking there about how merge requests are handled, web interfaces, etc. Finally, I would go for step 3) check how we can improve the owrt-kernel relationship. Of course, the 3rd step, if based in my idea, doesn't need to be done before 1/2. Also, steps 1,2 can be done at once.
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
