[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] docs/process/xen-release-management: Lesson to learn

Julien Grall writes ("Re: [Xen-devel] [PATCH] 
docs/process/xen-release-management: Lesson to learn"):
> While I understand this was not ideal, I still think it was the best 
> solution we had at that time. I would be interested to know what you 
> would have chosen with the situation we had.
>       - Would you have released without the XSAs?
>       - When would you have released Xen?

I don't have all the information necessary to make that decision.  I
might have tried to avoid getting into this situation by rejecting
patches earlier, or indeed waited until much later, or I might have
decided to do as you did by deliberately breaching this guideline.

I would like to repeat some of my previous posting since it seems to
me that you haven't addressed it.

> > I guess I'm being quite selfish here.  I'm usually the release
> > technician.  Doing release preparation at the last minute and in
> > strange ways means lots of opportunity for me to make mistakes.
> > 
> > I would like to put something in the release checklist that stops
> > people putting me in a difficult position where I am (a) likely to
> > make mistakes (b) those mistakes will be embarrassing.
> > 
> > Putting this in the release checklist doesn't mean that it always has
> > to be followed, of course.  Checklists are not rules; they are
> > guidelines.
> > 
> > But if this guideline is violated, and as a result I mess something up
> > due to having to do a lot of complicated, ad-hoc, un-qa-able, work,
> > all in a hurry, then it would be nice if it were obvious that the
> > cause of the trouble was the decision to take this risk, rather than
> > my carelessness or lack of attention to detail.
> > 
> > As it happens this last December we lucked out.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.