2015-10-11 14:16 GMT-07:00 Attila Lendvai <att...@lendvai.name>: >> Just my 2-cents >> >> IF it isn't BROKEN....please DON'T fix it. > > > the question here is: how much time coders (maintainers, contributors, > and users) would spare if the administration was shifted to a > different infrastructure. > > i cannot grow to like git (i still prefer darcs), but github simply > provides so many extra goodies around git, and with such a smooth > learning curve, that i think it's very much worth taking that road. > > i think it'd also be worth having a separate kernel fork (repo) as > a git submodule under the openwrt git repo. it could have branches for > the corresponding openwrt branches, and with its separate commit > history it would make comparison with the mainline kernel way much > simpler than it is today.
One of the complaints OpenWrt receives a lot (aside from pushing the actual kernel changes upstream) is that the patches are a combination of patches applied to the kernel, and files being directly copied into the Linux sources as-is. Although this model is not ideal for some people, it still provides some maintenance benefit since there is only one set of files to target multiple Linux versions. If we are to move to an OpenWrt branch of the Linux kernel, which is per-version of Linux (e.g: v4.1-openwrt), this creates a maintenance difficulty for these shared files/drivers (across multiple Linux versions), because each Linux kernel branch needs to be updated. Are we going to expect e.g: v4.1-openwrt git history never to be rewritten when changes to existing patches are made (look at the Raspberry Pi kernels, this is awful)? How can we guarantee that the same fix is easily applied throughout multiple branches? Do we also want to start maintaining per-platform branches built on top of v4.1-openwrt, e.g: v4.1-openwrt-ar71xx etc.? The idealistic answer would of course be: well, get your damn Linux changes upstream, bite the bullet now, but in few releases, you will get most of your patches and platforms supported, so this will just be ancient history. We all know this is not happening overnight, and working with the upstream Linux community can be challenging for different reasons so we still need something that is able to cope with the fast paced embedded market with 10+ new devices everyday with just one tiny GPIO variation, without rocking the entire way existing platforms are supported. > > potentially the same for some other projects as well, e.g. the > toolchain repos? Yes potentially, but then, this is a shortcut we can take just because we are natively using git, and not another SCM, and git submodules are possible. It could become a support/maintenance nightmare if everybody wants to start using custom snapshots all over the place. > > >> Regarding downstream forks, would using Git also make it easier for >> people like project turris to push appropriate changes back into >> OpenWrt proper? > > > git checkout -b fixing-this-and-that > gitk [and cherrypick or tailor the branch with the gui as needed] > git push > go to github.com and create a pull request > > the whole process can be shorter than 5 minutes, and after that anyone > can go and browse it among the open pull requests. We are talking about something slightly different here, because OpenWrt would switch to git does not mean that it needs to completely moves away from being self-hosted, and moved to github. I understand and value the benefits of github and its tools, and tend not to think that self-hosting makes much sense these days, but others may see things differently. -- Florian _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
