Res: Open Letter: Why I, Kevin Kofler, am not rerunning for FESCo

[Jeff Spaleta]

On Tue, May 4, 2010 at 8:45 AM, Jesse Keating <jkeating at redhat.com> wrote:
> So I'd love to have multi-level policy, but in my opinion it should get
> harder and harder to push an update as the release gets older, not
> easier.


In general I'm in agreement with this.  But at the same time I'm
concerned that the policy is going to make it more difficult for me to
respond to breakage in my packages created when a maintainer does an
update (mistakenly) that one of my packages depend on.

Not to harp on any of my peers...so apologizes if to anyone I think
I'm picking on in the following case study.

I just went through a round of breakage associated with matplotlib and
numpy caused by other maintainer action in both rawhide and EPEL.  In
rawhide it was really easy for me to get fixes out.  For EPEL, because
of the update policy..it was harder for me...the maintainer who is
trying to react to brokenness created by another maintainer.


The thing I really need help with as a maintainer is help seeing when
a update in testing is a potential impactor for one of the packages I
maintain.  So I can get ahead of any problems and do the testing I
need to do against the update in updates-testing and keep it from
hitting stable until I can spin up versions of my packages that work
with the update.  I don't want to be in a position where I have to
react to breakage. I want to be proactive, but I really need a better
heads up as to when things that impact my packages are in the que for
stable so I can better prioritize my time.


-jef