:thumbsup:

+1

+1

+1

+1

You make it sound like creating private branches is somewhat common in your workflow, which worries me a little. Could you provide an example or two where it was impossible to include the changes required by Modularity in the master branch?

+1

@psabata Let's have a look at automake:

$ dnf repoquery --requires --srpm --resolve automake
autoconf-0:2.69-24.fc26.noarch
automake-0:1.15-9.fc26.noarch
bison-0:3.0.4-6.fc26.x86_64
cscope-0:15.8b-4.fc26.x86_64
dejagnu-1:1.6-2.fc26.noarch
emacs-1:25.2-0.1.rc2.fc26.x86_64
expect-0:5.45-25.fc27.x86_64
flex-0:2.6.1-3.fc26.x86_64
gcc-gfortran-0:7.0.1-0.14.fc27.i686
gcc-gfortran-0:7.0.1-0.14.fc27.x86_64
gcc-objc++-0:7.0.1-0.14.fc27.x86_64
gcc-objc-0:7.0.1-0.14.fc27.x86_64
gettext-devel-0:0.19.8.1-9.fc27.i686
gettext-devel-0:0.19.8.1-9.fc27.x86_64
help2man-0:1.47.4-2.fc26.noarch
imake-0:1.0.7-7.fc26.x86_64
java-1.8.0-openjdk-devel-1:1.8.0.121-11.b14.fc27.x86_64
libtool-0:2.4.6-17.fc26.x86_64
lzip-0:1.18-2.fc26.x86_64
ncompress-0:4.2.4.4-7.fc26.x86_64
perl-Thread-Queue-0:3.12-1.fc26.noarch
perl-generators-0:1.10-2.fc26.noarch
perl-macros-4:5.24.1-391.fc27.x86_64
python2-docutils-0:0.13.1-4.fc26.noarch
python2-virtualenv-0:15.0.3-6.fc26.noarch
sharutils-0:4.15.2-5.fc26.x86_64
texinfo-tex-0:6.3-3.fc27.x86_64
texlive-dvips-6:svn41149-34.fc27.1.noarch
vala-0:0.36.1-1.fc27.i686
vala-0:0.36.1-1.fc27.x86_64

automake requires automake to build itself by default. And tons of other dependencies which we don't have right now. I spoke to maintainer and he added new bcond to specfile to disable test suite which resulted into fewer build dependencies. So we were able to bootstrap it -- create a build of automake which didn't require automake to build itself. As soon as we have all build dependencies available, we will be able to do a full build of automake. At the same time we still need to have the bootstrap workflow in-place (so we don't need to solve the same problem in future).

I assume that your response will be: you can do two commits to master branch where one sets bootstrapping macros and the other unsets them (this is what we did in golang). Some maintainers don't want such commits in their dist-git repositories. The other thing is that atm it's not easy to use custom dist-git environment to do modular builds. The easiest solution is to use the production one. The point here is that changes in specfile are usually not correct in first iteration (we had to do 3 iterations with golang). Again: the easiest workflow here is to create a private branch in production dist-git, iterate and as soon as everything works, cooperate with maintainer on merging the changes back to master. And this is what my plan is.

@ttomecek Okay, thank you. This is acceptable. I was concerned you were creating unmaintained forks and building Boltron from those. If it's just for temporary development work with a plan to merge it into master at some point, that's fine.

Anyway, +1.

ok, it's been a week and I see 7 +1s and 0 -1's so this request is approved.

Please use your powers wisely. :ramen: