+1 on not doing a release just for the sake of it. Sometimes it's needed
but most of the time it's not. See the differences between 1.15.0 and
1.15.4:
https://github.com/theforeman/foreman-installer/compare/1.15.0...1.15.4
On Thu, Sep 28, 2017 at 07:57:34PM -0400, Eric D Helms wrote:
Related to Dmitri's point, and I've thrown this question out with Katello
releases at least every other release, do all the components that are
currently released "together" need to be so these days? That is to say, can
any of the "versioned together components" be released more independently
but within the version stream? For example, say we are approaching 1.17
release, that is a good time to cut puppet releases, installer and
potentially smart proxy but do they need to be released together? Does
Foreman 1.17.1 necessitate a 1.17.1 installer? Or reverse it, does an
installer update have to wait on a Foreman 1.17.1 release?
Katello used to do this practice with a lot of repositories (e.g.
katello-agent, katello-selinux) and were at times releasing projects "just
because" without any real changes. After moving away from that, to let
katello-agent, katello-selinux and hammer-cli-katello more independently
release the process got a lot simpler. Further, I'd argue that each project
got a bit more focused and more thought put into maintenance and release.
Food for thought and discussion.
E
On Thu, Sep 28, 2017 at 2:29 PM, Dmitri Dolguikh <witlessb...@gmail.com>
wrote:
Why not distribute the release process? Each component can have (probably
already does) multiple maintainers who are capable of doing most of the
leg-work. The role of the release nanny then becomes coordinating the
effort, making public announcements and such. Such an approach would help
avoid overly broad permissions too.
-d
On Thu, Sep 28, 2017 at 3:23 AM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:
To release a gem to rubygems I'd recommend looking at how voxpupuli
implemented this using Travis[1]. The same can be done for puppet[2]. That
means you can push a tag to git and the release is there.
There are also tools that help you bump. For puppet there is
puppet-blacksmith[3]. How to do annotated tags is in my notes[3]. A more
generic script is bump2version[5] and I'm sure there are similar tools in
the ruby world.
IMHO these tools should be suggested in the plugin templates.
[1]: https://github.com/voxpupuli/modulesync/blob/e53079030501756
fc4111511fb9b6a239ffcb2a3/.travis.yml#L18-L27
[2]: https://github.com/voxpupuli/puppet-nginx/blob/fc363114e509f
439b51ea22723a996ffca8a107d/.travis.yml#L48-L58
[3]: https://github.com/voxpupuli/puppet-blacksmith
[4]: http://pad-katello.rhcloud.com/p/releasing-modules
[5]: https://github.com/c4urself/bump2version
On Wed, Sep 27, 2017 at 08:08:46AM -0700, Daniel Lobato wrote:
For foreman-docker I had a process:
https://github.com/theforeman/foreman-docker/blob/master/rel
ease/RELEASE.md
https://github.com/theforeman/foreman-docker/blob/master/rel
ease/rollout-release
which I planned to implement in all theforeman org plugins ideally.
It didn't happen but it's a similar thing.
On Wednesday, September 27, 2017 at 4:56:51 PM UTC+2, Timo Goebel wrote:
... isn‘t continuous delivery old these days? Why aren‘t we doing it?
I vote in favor of automating this. This ensures predictable results and
hopefully makes this process easier. To be honest: The current process
scares me.
Same for plugin releases. They also are way too manual right now.
Timo
> On 27. Sep 2017, at 16:46, Daniel Lobato Garcia <elob...@gmail.com
<javascript:>> wrote:
>
> Hi devs,
>
> After a few releases, and now that I'm trying to help someone else to
> take over in case it's needed, I found a roadblock.
>
> Whoever is doing the release, needs to have **many** permissions.
>
> Otherwise, it doesn't make much sense for a person to take over
release
> responsibilities. For example, if Ondrej has to do 1.15.5, he would
need
> the following permissions (see at the end of the email).
>
> Of course there are alternatives:
>
> 1 is to have the release nanny be supervised by people who have
'earned'
> these permissions. This is a bad idea because some of the tasks just
> cannot be 'supervised'. The nanny would have to ask someone to tag
> repositories, modify jenkins jobs, upload GPG signatures, post to the
> mailing list, tag new builds in Koji...
>
> 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and
> make it a real pipeline from 0 to release completed. At this moment,
> releases that are not the first RC1 are mostly automated by
> https://github.com/dlobatog/foreman_release and
> https://github.com/theforeman/tool_belt.
>
> My proposal is to go forward with 2. Give Jenkins permissions to do
all
> of the actions needed, and whoever is the release nanny, ideally only
> has to make sure all of the steps are moving forward. If something
> breaks, figure out how to fix it for the next release.
>
> This would mean making a few extra jobs before and after the current
> release pipeline. In my opinion, it's the way to go to ensure anyone
can
> take over this responsibility.
>
> At this moment, we are in a situation where only people who
> mostly have permissions everywhere can successfully do a release
without
> asking many people for favors.
>
> Personally if we complete this, I see it as a big win as it would
dwarf
> our bus factor for release managers & allow us to release at any pace
we
> desire (right now it's slow because we can't truly release things from
> one day to the next due to the work involved).
>
> Thoughts?
>
> Here's the list of permissions:
>
> ----------------
>
> Github:
> - Push in foreman, foreman-selinux, foreman-installer,
> smart-proxy, foreman-infra, foreman-packaging
>
> Transifex -
> - Allow to change the auto-update URL to point to latest -stable
> branch
>
> Redmine -
> - Create new "Found in Release" version
>
> Jenkins -
> - Modify jobs
> - Run jobs
>
> Koji -
> - Create tags
> - SSH access to update the mash scripts
> - Create packages
> - Tag builds
>
> Repository servers
> - ssh in deb.theforeman.org
> - ssh in yum.theforeman.org
>
> Announcements -
> - Post to foreman-announce
> - Merge access in theforeman.org
> - Change IRC message
> - Publish in Twitter, G+
>
> ---------------
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D
6DE30
> Keybase: https://keybase.io/elobato
>
> --
> You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Eric D. Helms
Red Hat Engineering
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
