(replies inline)
A friendly reminder from one of the JEP Editors, please keep the discussion on
this mailing list thread about the document.
At this stage of the game the only changes/edits on the pull request will
likely be copy edits rather than structure edits. By the end of the day I will
likely give this a number, and merge this as a `Draft` into repository, so this
PR is not a great place for design discussion :)
use the list, luke.
>
> Thank you everyone!
>
> 2018-03-20 23:21 GMT+01:00 Baptiste Mathus <
m...@batmat.net>:
>
> > Hello everyone,
> >
> > Sorry for the time it took to get back here. I think I finally addressed
> > all comments.
> >
> >
https://github.com/batmat/jep/pull/1 is ready for another round of
> > comments.
> >
> > I hope that no big thing surfaces again, though obviously there will be
> > issues discovered later, but I feel like we have been thinking about it
> > enough to be able to move forward.
> >
> > Thanks a lot.
> >
> > 2018-03-16 16:10 GMT+01:00 Jesse Glick <
jgl...@cloudbees.com>:
> >
> >> On Wed, Mar 14, 2018 at 1:55 PM, R. Tyler Croy <
ty...@monkeypox.org>
> >> wrote:
> >> > core and plugin upgrades can result in
> >> > modification of config.xml and other object-serialized-files on disk
> >> when an
> >> > upgrade occurs.
> >>
> >> Does happen, but rarely. In most cases, format changes take effect on
> >> disk only when a `Saveable` object is in fact saved for some other
> >> reason???a *Save* button in the UI, for example.
> >>
> >> > This means an upgrade of Jenkins Essentials has a very real potential
> >> to cause
> >> > irreversible modifications to files on disk which prevent a safe
> >> rollback.
> >>
> >> This is true.
> >>
> >> > "bricking" a Jenkins Essentials instance is a severe failure for the
> >> project
> >>
> >> This is what needs to be defined much more carefully. What would cause
> >> an installation to be ???bricked???, exactly? Years of work by core devs
> >> (see JIRA issues with label `robustness`) have solved most cases where
> >> Jenkins would fail to start or be used in a basic capacity merely due
> >> to unreadable configuration files. You might get *Discard Old Data*
> >> warnings, of course, but these are not fatal.
> >>
> >> > we need to prevent against irreversible modifications to files causing
> >> > runtime failures
> >>
> >> That is a much broader requirement, at least if ???runtime failures???
> >> could be interpreted as things like ???the deployment stage in all my
> >> pipelines started failing???, and it is not clear to me that the
> >> proposal as it stands comes close to satisfying it.
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Jenkins Developers" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an
> >> email to
jenkinsci-de...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5mWyWAhktJW%3DiiQqfHGe8PYYnggz1p7KTZF7%3DjB7Q4dA%40mail.gmail.com.