[OpenWrt-Devel] SVN to GIT transition

[Javier Domingo Cansino]

>
> 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.
>
I see I have not enough information on what are the common use cases. For
me, these are the following:
 - User clones openwrt master, makes some work on it and has an issue.
 - Company uses openwrt release as base.
 - Company uses openwrt random commit as base.

Supposing these are the use cases you want to support, please expand if
needed, I can develop a mini script that would check upstream for the
latest commit, and give you a version information string like the one I
showed. Please tell if you want any more information there.


> 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 have to agree that I find pretty clean the current method, although it
can be difficult to with it develop, I understand makes it easier to
maintain it.

However, I am not willing to discuss whether to change the current kernel
patch system to a git branch releases based one, because I haven't used it
enough.

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.
>
Let's hope we don't make things worse but different, which might seem worse
at the beginning in comparison to the workflow you have been long
accustomed to.


> We have patchwork for tracking submissions, and people get notified when
> their patches are accepted or rejected.

The interface is not as clean as the github/gitlab one. And people is more
relaxed with responsive and intuitive interfaces.

Less work for the submitter, but more work for testing before
> commit/push => not a good trade-off on my opinion.
>
Let's not make it worse for the tester/committer.

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

I can prepare a tool that just cherry-picks changes from the PR so that you
can test them easily. You can also ask the contributor to change the shape
of the commits, and the tool would then replicate again the changes on top
of HEAD.

For the core repo, I'd rather have higher patch quality instead of more
> contributions.
>
I can't make quality better just with git, but we could introduce travis-ci
for basic testing of PRs, to report basic failures that might have slipped
off the contributor (this would come later).

This way my patch from the other day wouldn't have needed to be reviewed
until check-patch had run on it.


> 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.
>
With the tools I can create I hope it will be easier to do this, also
because issues and PRs have unique IDs, we could refer to them and make
testing much more controlled. For example, using travis-ci for PRs.


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

I agree that the bottlenecks should be reduced. I think I have spotted some
ways we could make a little better these.

I think gitlab/github is a really good choice because if everything in the
development (the repo and the PRs) is done using the same tool, we can have
nice features to help you reduce the bottleneck.

I would love to sort of arrange a trial period to have experience on how
you feel the tools, what command line helpers you would need and overall
feedback on the process to make the tools more adapted to your need.

I believe we should for now concentrate on steps 1-2), git based main repo,
hosted in a service such as gitlab/github.

I can prepare a sample repo where you could interact with a contributor,
not by means of everyone sending stuff to core through there but just a few
during some days.

If you want, before doing this, I can develop the two command lines I spoke
about, so that you can generate the build version info and the
cherrypick/patch checkout tool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20151012/2d0154ad/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel