[OpenWrt-Devel] SVN to GIT transition

[Felix Fietkau]

On 2015-10-12 16:20, Javier Domingo Cansino wrote:
>     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.
> 
> 
> This was a way to demonstrate that the forking point is not actually a
> problem SVN solves. Not having a similar revision number that collides
> with the one used in official repo is now sustained by the fact that you
> are the only ones using SVN.
Please don't try to argue with me based on unlikely hypothetical
scenarios of what somebody could do (but never does). I'm interested in
stuff that works in practice.

>     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.
> 
> That's the work that needs to be done, although there are plenty forks
> over there with a solution to that. I have seen them at least, but I
> can't provide code :(, so if someone has a solution that can share,
> shall intervene here.
I have yet to see an approach for this that actually works and deals
with all the common scenarios where people fork OpenWrt and make a few
local changes.

>     It's not about what you theoretically can do, it's about what users will
>     end up doing.
> 
> That doesn't affect your workflow. At the end you will have the same
> problems as you have now because people is already using git to interact
> with openwrt. They provide a forking base, and there you go.
What users end up doing DOES affect our workflow. If asking users to
provide version information from stuff running on their routers gets
more complicated because local commits might obscure the revision hash,
then that creates more work for us devs.

>     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 am really sorry but I haven't worked enough with the kernel part as to
> say how maintainable would this solution be. I was just giving another
> alternative to submodules.
> 
> Just in case, my advice here was not to use submodules. It was just a
> git advice rather than an openwrt git based advice. 
And I've actually given much thought to the cost and benefits of our
current workflow vs doing it in git. My main problem is not with the
part of submodules vs external stuff, it's with the workflow of
maintaining our kernel changes in a git repo directly instead of having
patches.

>     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.
> 
> I find this paragraph confusing because I don't really know if you are
> referring to the kernel in openwrt, or to openwrt as a whole.
This was referring to having the openwrt kernel stuff in git.

> In the first case, I just want to say that it is possible to work with
> submodules, but it costs you brain-cpu to do it correctly most of the
> times. That's why my advice against submodules. I can further expand if
> someone wants to know which solutions I have seen correctly working.
> 
> In the second case, from what I do, I would find much easier to have a
> git based openwrt, not for git itself (I am already using it), but for
> the tools (step 2) and workflows you can have. I expand this below.
>  
> 
>     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.
> 
> 
> The benefits of the openwrt git based developing are the next ones,
> based on previous experience, using Github as a model, similar applies
> to Gitlab:
>  - Easier to get started with openwrt trivial contributions. If I find a
> typo, I can directly from the web interface fork, change and PR to the
> main repo.
Typo fixes are the least relevant changes. Making it easier to do that
kind of change is not a priority, especially if other things are made worse.

>  - Easier tracking of the status of my patch, the issues I have
> submitted and the pending work. This is mostly because UIs/workflows are
> pretty complete.
We have patchwork for tracking submissions, and people get notified when
their patches are accepted or rejected.

>  - Easier way to update my patch, less noise to the list. I always get
> it wrong, and resubmitting when it is just some formatting issues is far
> less noisy. With github/gitlab, I just have to checkout the branch I am
> sending my patch from and do whatever I need to make it
> openwrt-contribution-guidelines compliant.
Less work for the submitter, but more work for testing before
commit/push => not a good trade-off on my opinion.

>  - Review of my patches. I can actually track if I have done everything
> needed to get my patch accepted. Past day I submitted a simple patch to
> libubox and I forgot to reorder variable declarations. Also, more clear,
> non mailbox dependant patch review, In a glance I can see my patch, the
> comments it has, and the conversation about specific lines, even if I am
> not suscribed.
I personally find the pull request workflow very cumbersome. With what
we have now, I can just 'git am' the ones that look sane, do a final
test build + review, and then 'git svn dcommit' the result.
With pull requests, I'd have to take those in a private branch or
something, then run git pull on my local machine before being able to
test stuff. Also, this will spam the repo history with annoying merge
commits unless I do a rebase myself.

>  - More user friendly. I know this might not be important for some
> people, but most of the users out there willing to help, although not
> excelent devs, may be able to help if they have tons of tutorials on how
> to use the web interface.
For the core repo, I'd rather have higher patch quality instead of more
contributions.

>  - Of course, you still can do everything as you already do, you
> checkout the branch from the PR and commit it manually, and
> github/gitlab will detect you merged that commit and will close the PR.
> 
> As you see, these are mostly user experience improvements. Maybe for you
> make no difference at all while core developing, but I find those
> benefits really worthy. I have seen others state some of them too.
The main bottleneck in core development is not users submitting patches,
it's patch review and especially testing. In my opinion your suggestions
make that part harder.

> Just to finish, I think this conversion from svn to git doesn't have as
> main objective to make your life as core devs easier although it will
> probably do (I understand you are now accustomed to the current
> workflow), but to make life of users/contributors easier.
The work done by core devs is the main bottleneck, so I care about that
a lot more than making the life of drive-by contributors easier.

- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel