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 before I > could push in my changes. That communication failure might have been partly > my fault but IMHO the job of a release manager is to communicate with all > the maintainers if everything is in place for a release. > > Now you state it as a problem that you need a lot of people, but you need to > communicate with them anyway. Yes, the tagging and releasing should be > scripted but planning a release will require humans. > > Like Eric I think we should start by documenting. Right now it's a huge > black box for most people, let's start there.
The process is pretty well documented, http://projects.theforeman.org/projects/foreman/wiki/Release_Process contains everything that has to be done step by step > > On Wed, Sep 27, 2017 at 09:19:10PM -0400, Eric D Helms wrote: > > 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 are some tasks that should be > > done by a human. The tedious, repetitive bits we should automate. The > > aspects that require some human foresight, approval or double checking of > > we should either require a releaser to "yes" to a job over or to perform > > semi-automated in that the user uses tooling but ultimately has input. For > > example, cherry picking should be 90% automated but 10% human input to > > ensure nothing seems off since our issue-to-change is not flawless. > > > > While we have some automation already in place, from my experience I would > > recommend one of the following approaches. > > > > 1) create a flow chart of every action that has to happen using something > > like plantuml with parallel actions where possible > > 2) Create a new release job, starting either from the beginning or the end > > of the process and add each next step to it > > > > > > Eric > > > > On Wed, Sep 27, 2017 at 10:46 AM, Daniel Lobato Garcia <[email protected]> > > 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=0x7A92D6DD38D6DE30 > > > 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 [email protected]. > > > 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 [email protected]. > > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
