[OpenWrt-Devel] SVN to GIT transition

[Florian Fainelli]

2015-10-11 14:16 GMT-07:00 Attila Lendvai <attila at 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel