[OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel