On 2015-10-12 15:09, Javier Domingo Cansino wrote: > 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 haven't seen a single instance of somebody doing this, and in my opinion it would be kind of stupid anyway :) We don't even advertise the SVN server URL to users anymore for a reason.
> 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 you think users will actually do that? Based on previous experience, I really don't. The way it's set up right now, people can fork as they wish and the scripts automatically determining the OpenWrt base version will just work. > 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. It's not about what you theoretically can do, it's about what users will end up doing. > 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). Wow, now you're making it really confusing for everybody involved. Some changes live in an external git repo, some changes live as patches, and whenever the external repo changes we're supposed to update the revision in the OpenWrt tree? > 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). I haven't seen any proposal that deals with the revision crafting issue in a practical and useful way. I also haven't seen many compelling arguments about what the practical benefit of these changes would be. I see repeated claims that assume that having patches in a git repo will make it easier to upstream stuff, and I just don't believe those claims without a proper explanation. > 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. Before you try to convince us to change the workflow, I would really like to see a *detailed* explanation of how this would actually help us. If you really believe that this would be a good fit, then you will have to be a lot more specific about the potential benefits. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
