Clarify releasing under Apache rules

[apetro]

This is nuanced and is going to need Committer follow-up on uportal-dev@ after merge.

• Adds releasing page, noting that we've adopted Apache rules and linking them for releases.
• Raises awareness of in-progress project name change.
• Tweaks Apereo Incubation badge to the new preferred badge implementation.

Not my intention: add a lot of painful friction to releasing.

My intention: more open source project "legitimacy" through following the process and policies we are trying to adopt.

So, specifically, what I think needs to happen is:

• In general, more talking about uPortal-home release engineering on uportal-dev@.
• In specific, a vote of the Committers authorizing at least @vertein and perhaps all Committers to execute releases as needed using their best judgement. We're not yet ready for a PMC vote with 72 hours to gel for every release. And that rigor is not yet justified. The Committers explicitly authorizing release engineers lends legitimacy to the thing we've actually been doing and realistically will continue to do for now.
• Openness to revisiting this to be less wild west about releasing when more care becomes more feasible and more justified.

---

Contributor License Agreement adherence:

• This Contribution is under the terms of Individual Contributor License Agreements (and also Corporate Contributor License Agreements to the extent applicable) appearing in the Apereo CLA roster.

[ChristianMurphy]

Generally looks good. 👍

The committer rules section referred to is confusing me though.

• Which Apache rules are being followed? (a link would help)
• Could some clarification on "culture" be added?
• What modification have been made?

[ChristianMurphy]

Any chance of CLA hub being used?

[apetro]

Chance? Sure.

Cf. thoughts about partially adopting cla-assistant.io. On skim looks like CLAHub and cla-assistant.io are similar. I think one hangup is concern that click-through ICLA agreement is not sufficient. So there might have to be a layer of indirection where a Contributor doesn't agree to the ICLA via cla-assistant.io, rather they confirm that they've jumped through the real Apereo CLA-signing hoops, and do that confirmation via cla-assistant.io. So the end result of nice marking on the Pull Request still happens, but there's some wrinkles in the implementation and particularly the opportunity for Contributors to incorrectly affirm their having jumped through hoops they haven't fully jumped through.

Personally, I'd love to see Apereo consider navigating the available policy tradeoffs differently.

If you'd like to help iterate Apereo licensing policy recommendations, please do prevail upon the uPortal project, say, to nominate you to the re-forming Licensing Group.

[ChristianMurphy]

Cf. thoughts about partially adopting cla-assistant.io. On skim looks like CLAHub and cla-assistant.io are similar

Which tool is less important than automating the process.

concern that click-through ICLA agreement is not sufficient

I'm getting "You must be a member of this group to view and participate in it. Membership is by invitation only.", but I trust that there are exciting things being discussed.

[ChristianMurphy]

What adaptations have been made?

[apetro]

Whatever necessary or pragmatic local adaptations we need to make. :)

I think it's simultaneously true that

• we're trying to become a more mature open source software project
• we see in Apache some rules and culture and having-it-all-together-ness worth emulating
• there's some interpretation needed in adapting this, because Apereo isn't Apache
• figuring this out is messy.

Apache release rules formally would require a PMC vote, would require the release binaries being available to the PMC for review before public release, would require +1 voters to actually verify those binaries, would require a bunch of vigor that we're not prepared to live up to at this point. So this documentation is an attempt to acknowledge that reality.

Saying that one has a given policy or practice and then not actually having that policy or practice is poisonous, is erosive. Trying to avoid that particular sin and create some runway for figuring this all out.

[ChristianMurphy]

I agree with your pragmatic approach to leverage only the rules that make sense for the community.

My concern is leaving it at "necessary or pragmatic local adaptations" will start to build up a list of unspoken and unwritten rules that the community follows.
uPortal has build up some documentation debt in the area of unwritten rules, the lack of knowledge transfer can create a barrier to entry for interested developers.

uPortal Home has the opportunity to avoid documentation debt in this area entirely, since the practice are still being established.

• there's some interpretation needed in adapting this, because Apereo isn't Apache
• figuring this out is messy.

I agree, having small things, like where the process has deviated can help the community interact better.

[apetro]

Indeed. Unwritten "necessary or pragmatic local adaptations" to rules is obnoxious and totally unacceptable. It's just that it's less obnoxious than any of the immediately feasible alternatives. I don't know how to write down all the adaptations at this point, because I don't know what all they are yet.

I agree about the value in paying down process documentation debt. Let's continue to identify and chase down actionable steps on this through the incubation process. Governance is an item on the incubation checklist, e.g. I'd readily agree that where we're at on figuring this out doesn't meet the Incubation exit threshold.

[ChristianMurphy]

I don't know how to write down all the adaptations at this point, because I don't know what all they are yet.

Fair enough

[ChristianMurphy]

Maybe combine "Integration with uPortal" and "Developing" into a "External Resource" section?