On 2019-01-07 08:51, Alex Harui wrote:
The workflow I envision is this:

1.  RM runs Jenkins job on builds@ to create release branch, generate artifacts 
, tag the repo, push artifacts to Nexus staging and dist.a.o/dev/Royale
2.  RM downloads artifacts to verify them, adds PGP signature and calls for vote
3.  PMC downloads artifacts, verifies that the source packages matches the tag 
and performs other checks required by ASF release policy.

This roughly matches the vision I have for log4net, a subproject of the apache logging pmc. log4net targets several .net frameworks (.net 2.0, .net 3.5, .net 4.0, .net 4.0 cp, .net 4.5, netstandard 1.3, mono 2.0, mono 3.5) and shall run on both linux and windows operating systems. Requiring a developer to arrange at least four machines to maintain the source code is off the table. Further the onboarding procedure for new committers shall be as painless as possible. Otherwise it makes it just harder to grow the community. So far we managed to build and test the source code using jenkins on a sensible array of environments. I was able to implement that pipeline because I had to stay in bed for two months to heal some wounds. During this period I was able to work on this for an hour or two each day. Currently we do have a release branch and the binaries were built by jenkins. We currently lack the human resources to test these binaries, even though I have great confidence that the binaries work. If we had ready-to-use environments it would be a great addition to the project. It would allow us to continue with step 2 of the above workflow. I do however have no idea how this could be achieved. Docker could be a piece of the puzzle, but not for the ancient .net frameworks mentioned earlier. Last but not least I do hope that the efforts put into the building and testing automation attracts new developers and allows the project to continue existing. The alternative is stagnation and becoming obsolete over time.

Reply via email to