<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I haven't seen a single instance of somebody doing this, and in my<br>
opinion it would be kind of stupid anyway :)<br>
We don't even advertise the SVN server URL to users anymore for a reason.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And you think users will actually do that? Based on previous experience,<br>
I really don't. The way it's set up right now, people can fork as they<br>
wish and the scripts automatically determining the OpenWrt base version<br>
will just work.<br></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's not about what you theoretically can do, it's about what users will<br>
end up doing.<br></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wow, now you're making it really confusing for everybody involved. Some<br>
changes live in an external git repo, some changes live as patches, and<br>
whenever the external repo changes we're supposed to update the revision<br>
in the OpenWrt tree?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Just in case, my advice here was not to use submodules. It was just a git advice rather than an openwrt git based advice. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I haven't seen any proposal that deals with the revision crafting issue<br>
in a practical and useful way. I also haven't seen many compelling<br>
arguments about what the practical benefit of these changes would be.<br>
<br>
I see repeated claims that assume that having patches in a git repo will<br>
make it easier to upstream stuff, and I just don't believe those claims<br>
without a proper explanation.<br></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Before you try to convince us to change the workflow, I would really<br>
like to see a *detailed* explanation of how this would actually help us.<br>
If you really believe that this would be a good fit, then you will have<br>
to be a lot more specific about the potential benefits.<br></blockquote><div><br></div><div>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:</div><div> - 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.</div><div> - 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.</div><div> - 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.</div><div> - 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.</div><div> - 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.</div><div> - 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>You could of course then use all the tools (if desired) github already has linked.</div></div></div>