<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 have yet to see an approach for this that actually works and deals<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
with all the common scenarios where people fork OpenWrt and make a few<br>
local changes.<br></blockquote><div><div>I see I have not enough information on what are the common use cases. For me, these are the following:</div></div><div> - User clones openwrt master, makes some work on it and has an issue.</div><div> - Company uses openwrt release as base.</div><div> - Company uses openwrt random commit as base.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And I've actually given much thought to the cost and benefits of our<br>
current workflow vs doing it in git. My main problem is not with the<br>
part of submodules vs external stuff, it's with the workflow of<br>
maintaining our kernel changes in a git repo directly instead of having<br>
patches.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Typo fixes are the least relevant changes. Making it easier to do that<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
kind of change is not a priority, especially if other things are made worse.<br></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have patchwork for tracking submissions, and people get notified when<br>
their patches are accepted or rejected.</blockquote><div>The interface is not as clean as the github/gitlab one. And people is more relaxed with responsive and intuitive interfaces.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Less work for the submitter, but more work for testing before<br>
commit/push => not a good trade-off on my opinion.<br></blockquote><div>Let's not make it worse for the tester/committer.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I personally find the pull request workflow very cumbersome. With what<br>
we have now, I can just 'git am' the ones that look sane, do a final<br>
test build + review, and then 'git svn dcommit' the result.<br>
With pull requests, I'd have to take those in a private branch or<br>
something, then run git pull on my local machine before being able to<br>
test stuff. Also, this will spam the repo history with annoying merge<br>
commits unless I do a rebase myself.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the core repo, I'd rather have higher patch quality instead of more<br>
contributions.<br></blockquote><div>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).</div><div><br></div><div>This way my patch from the other day wouldn't have needed to be reviewed until check-patch had run on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The main bottleneck in core development is not users submitting patches,<br>
it's patch review and especially testing. In my opinion your suggestions<br>
make that part harder.<br></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The work done by core devs is the main bottleneck, so I care about that<br>
a lot more than making the life of drive-by contributors easier.<br></blockquote><div><br></div><div>I agree that the bottlenecks should be reduced. I think I have spotted some ways we could make a little better these.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I believe we should for now concentrate on steps 1-2), git based main repo, hosted in a service such as gitlab/github.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>