[OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> 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.

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.

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.


> 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.


> 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.

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.
 - 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.
 - 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.
 - 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.
 - 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.
 - 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.

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.

You could of course then use all the tools (if desired) github already has
linked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20151012/3bed9045/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel