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.