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

[Jesse Keating]

On Tue, 2010-05-04 at 09:07 -0800, Jeff Spaleta wrote:
> 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

If the breakage was in the form of broken deps, the original update
would not have been allowed out in the first place.  The maintainer
would have had to contact all the folks with packages that would break
and get them to coordinate the update.

If the breakage was more of a functional break and not a dep break,
that's where automated testing comes in, and we grow the automated
functional testing of updates so that if an update comes along we can
detect the breakage and alert both parties.

The solution to "shit went out and broke my stuff" isn't to make it
easier to put shit out, it's to make it harder to put /broken/ shit out
in the first place.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100504/878f5fe9/attachment.bin