FreeIPA release - better automation of wiki updates

[Martin Kosek]

Hi all,

I was thinking about improvements to FreeIPA release processes and
related wiki updates. Relevant changes and upgrades to the wiki and it's
plugins [1] that I did recently will may enable us to leverage some of
the new functionality to fully automate the wiki updates.

If I check the release instructions [2] I see lot of manual steps that
prolong the release procedure. I think these could be improved to not
make wiki the bottleneck of full release automation:

1) Downloads - add pointer to new tarball
I would propose moving this information to release page, along with
information/link how we sign the release (or use signature as only mean
of verifying the release). Downloads page could then for example just
simply list links to the 5 most recent releases, utilizing the updated
plugin [3].

This means that the page would *not be changed* during release.

2) Main_Page - add info on new release
This document could again just list most recent 5 releases with [3],
filtered by category. We just need to make sure the Release pages have
some category assigned, which can be done easily if related template
{{ReleaseDate|YYY-MM-DD}} is used on every release (it was missed couple
last releases).

3) News - add similar info as on Main_Page
I see this page is now even obsolete, so we just remove it from [2]

4) Roadmap - add info on new release, check if Roadmap is up to date
This is still valid, but not may be a requirement for the release
person, this is just something we need to do when opening new milestones
or updating the upstream course.

5) Documentation - update links and version numbers
I am actually not sure what version numbers are meant here.

6) Build - update COPR repositories if new ones are introduced or old
abandoned
Same as 4) - something to be done when a new milestone is done,
especially if the release is a major release.


Summary: I think that if we leverage the new wiki capabilities and
changes proposed in this mail, the wiki changes for releasing a minor
FreeIPA release may be just creating the single release page and all
other pages should update automatically themselves.

[1] https://github.com/freeipa/freeipa-wiki
[2] https://www.freeipa.org/page/Release#Wiki_pages_to_be_updated
[3] https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia)

-- 
Martin Kosek <mkosek(a)redhat.com&gt;
Manager, Software Engineering - Identity Management Team
Red Hat, Inc.

[Alexander Bokovoy]

On pe, 08 joulu 2017, Martin Kosek via FreeIPA-devel wrote:
> Hi all,
>
> I was thinking about improvements to FreeIPA release processes and
> related wiki updates. Relevant changes and upgrades to the wiki and it's
> plugins [1] that I did recently will may enable us to leverage some of
> the new functionality to fully automate the wiki updates.
>
> If I check the release instructions [2] I see lot of manual steps that
> prolong the release procedure. I think these could be improved to not
> make wiki the bottleneck of full release automation:
>
> 1) Downloads - add pointer to new tarball
> I would propose moving this information to release page, along with
> information/link how we sign the release (or use signature as only mean
> of verifying the release). Downloads page could then for example just
> simply list links to the 5 most recent releases, utilizing the updated
> plugin [3].
>
> This means that the page would *not be changed* during release. 
Yep, that would be
good to automatically manage.


> 2) Main_Page - add info on new release
> This document could again just list most recent 5 releases with [3],
> filtered by category. We just need to make sure the Release pages have
> some category assigned, which can be done easily if related template
> {{ReleaseDate|YYY-MM-DD}} is used on every release (it was missed couple
> last releases). 
+1

> 3) News - add similar info as on Main_Page
> I see this page is now even obsolete, so we just remove it from [2] 
+1

> 4) Roadmap - add info on new release, check if Roadmap is up to date
> This is still valid, but not may be a requirement for the release
> person, this is just something we need to do when opening new milestones
> or updating the upstream course. 
We already link to pagure roadmap there. Changing
roadmap is not
typically a part of a release, especially a minor one. We don't have
much of information that changes on the page so perhaps we can have it
in the list of requirements to consider whether Roadmap page needs
updates but not a mandatory item.

> 5) Documentation - update links and version numbers
> I am actually not sure what version numbers are meant here. 
Perhaps it is about
major release changes. Though Red Hat's
documentation is indexed by RHEL release so if we get a bump in the
release, we probably need to update links.

> 6) Build - update COPR repositories if new ones are introduced or old
> abandoned
> Same as 4) - something to be done when a new milestone is done,
> especially if the release is a major release. 
+1

> Summary: I think that if we leverage the new wiki capabilities and
> changes proposed in this mail, the wiki changes for releasing a minor
> FreeIPA release may be just creating the single release page and all
> other pages should update automatically themselves.
>
> [1] https://github.com/freeipa/freeipa-wiki
> [2] https://www.freeipa.org/page/Release#Wiki_pages_to_be_updated
> [3] https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia) 
-- 
/ Alexander Bokovoy

[Petr Vobornik]

On Fri, Dec 8, 2017 at 4:14 PM, Alexander Bokovoy <abokovoy(a)redhat.com&gt; wrote:
>  On pe, 08 joulu 2017, Martin Kosek via FreeIPA-devel wrote:
> >
> > Hi all,
> >
> > I was thinking about improvements to FreeIPA release processes and
> > related wiki updates. Relevant changes and upgrades to the wiki and it's
> > plugins [1] that I did recently will may enable us to leverage some of
> > the new functionality to fully automate the wiki updates.
> >
> > If I check the release instructions [2] I see lot of manual steps that
> > prolong the release procedure. I think these could be improved to not
> > make wiki the bottleneck of full release automation:
> >
> > 1) Downloads - add pointer to new tarball
> > I would propose moving this information to release page, along with
> > information/link how we sign the release (or use signature as only mean
> > of verifying the release). Downloads page could then for example just
> > simply list links to the 5 most recent releases, utilizing the updated
> > plugin [3].
> >
> > This means that the page would *not be changed* during release.
>
>  Yep, that would be good to automatically manage. 
Or we can simply point to releases folder on pagure which contains
both signatures and the tarballs.

http://releases.pagure.org/freeipa/

> > 2) Main_Page - add info on new release
> > This document could again just list most recent 5 releases with [3],
> > filtered by category. We just need to make sure the Release pages have
> > some category assigned, which can be done easily if related template
> > {{ReleaseDate|YYY-MM-DD}} is used on every release (it was missed couple
> > last releases).
>
>  +1 
+1
> > 3) News - add similar info as on Main_Page
> > I see this page is now even obsolete, so we just remove it from [2]
>
>  +1 
+1
> > 4) Roadmap - add info on new release, check if Roadmap is up to date
> > This is still valid, but not may be a requirement for the release
> > person, this is just something we need to do when opening new milestones
> > or updating the upstream course.
>
>  We already link to pagure roadmap there. Changing roadmap is not
>  typically a part of a release, especially a minor one. We don't have
>  much of information that changes on the page so perhaps we can have it
>  in the list of requirements to consider whether Roadmap page needs
>  updates but not a mandatory item. 
There isn't usually much to update.

> > 5) Documentation - update links and version numbers
> > I am actually not sure what version numbers are meant here.
>
>  Perhaps it is about major release changes. Though Red Hat's
>  documentation is indexed by RHEL release so if we get a bump in the
>  release, we probably need to update links. 
Right, but it is not triggered by upstream release but rather RHEL
release. So IMO this step can be removed.

> > 6) Build - update COPR repositories if new ones are introduced or old
> > abandoned
> > Same as 4) - something to be done when a new milestone is done,
> > especially if the release is a major release.
>
>  +1 
+1

> >
> > Summary: I think that if we leverage the new wiki capabilities and
> > changes proposed in this mail, the wiki changes for releasing a minor
> > FreeIPA release may be just creating the single release page and all
> > other pages should update automatically themselves.
> >
> > [1] https://github.com/freeipa/freeipa-wiki
> > [2] https://www.freeipa.org/page/Release#Wiki_pages_to_be_updated
> > [3] https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia)
>
>
>  --
>  / Alexander Bokovoy 


-- 
Petr Vobornik

[Martin Kosek]

On 12/12/2017 03:45 PM, Petr Vobornik wrote:
>  On Fri, Dec 8, 2017 at 4:14 PM, Alexander Bokovoy
> <abokovoy(a)redhat.com&gt; wrote:
> > On pe, 08 joulu 2017, Martin Kosek via FreeIPA-devel wrote: 
...
> >> Summary: I think that if we leverage the new wiki
> capabilities and
> >> changes proposed in this mail, the wiki changes for releasing a minor
> >> FreeIPA release may be just creating the single release page and all
> >> other pages should update automatically themselves.
> >>
> >> [1] https://github.com/freeipa/freeipa-wiki
> >> [2] https://www.freeipa.org/page/Release#Wiki_pages_to_be_updated
> >> [3] https://www.mediawiki.org/wiki/Extension:DynamicPageList_(Wikimedia) 
Thanks for all the suggestions guys! I went ahead and implemented this
release process simplifications, factoring information from you in.

Most impacted pages:
https://www.freeipa.org/page/Downloads (feel free to adjust, that page
underwent a rewrite)
https://www.freeipa.org/page/Main_Page (dynamic list of recent releases)

Links and resources related to this change also listed in
https://github.com/freeipa/freeipa-wiki/issues/6

Questions or feedback welcome.

HTH!
Martin