On 09/28, Ewoud Kohl van Wijngaarden wrote:
> While I agree we should automate a lot, I agree with Eric. Doing a Foreman
> release should involve a human to keep the end-to-end quality. Just giving
> permissions is wrong.
>
> For example in Foreman 1.15.5 the installer was tagged and released befor
+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
IMHO that's another (better?) way of phrasing the point I made about
relasing being about communication in another email.
On Thu, Sep 28, 2017 at 11:29:36AM -0700, Dmitri Dolguikh wrote:
Why not distribute the release process? Each component can have (probably
already does) multiple maintainers
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 w
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 ove
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
While I agree we should automate a lot, I agree with Eric. Doing a
Foreman release should involve a human to keep the end-to-end quality.
Just giving permissions is wrong.
For example in Foreman 1.15.5 the installer was tagged and released
before I could push in my changes. That communication
There are two considerations that I'd like to put forth as we think about
this:
1) Instead of adding jobs, we re-think and re-write the release job in
Pipeline syntax similar to my starter here --
https://github.com/theforeman/foreman-infra/pull/323
2) We don't automate all the things as there a
Hello
I like 2. At the same time, if it takes more then few weeks, I'd say let's
just give the release person all permission that are required. If we agree
that the person should do the release (in the worst case, we can do the
nomination process), we should make it as easy as possible for them
On 27. Sep 2017, at 16:46, Daniel Lobato Garcia
> > wrote:
> >
> > 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/d
... 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
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 examp
12 matches
Mail list logo
