Deep Freeze coming for Fedora 7 (and cvs branching coming too)

[Jeremy Katz]

On Thu, 2007-05-17 at 08:46 +0200, Ralf Corsepius wrote:
> On Tue, 2007-05-15 at 15:51 -0400, Christopher Blizzard wrote:
> > I've been following this thread pretty casually.  So here are my
> > thoughts:
> 
> > 4. We want to make sure that there's _some_ comment about why an update
> > happens that end users might understand.
> a) This comment already is supposed to be in an rpm.spec's changelog.
> 
> And similarly to "make clog", I don't see any reason why it can't
> automatically be derived from there.

I think everyone has been violently agreeing that we could take some
steps to pre-populate with things like this.  And we will.  Just because
it's not there at first doesn't mean it can't happen or won't ever
happen or anything like that.  There are just reality constraints around
time that can't be changed which dictate when it will happen.

> b) At least wrt. my packages, probably 90% of all "updates" are either
> addressing packaging issues or "trivial" upstream updates.
> 
> I really don't see much reason why comments about them would be useful.

Highlight reasons that the update is useful!  Obviously there's
something that makes it so that you think it's useful, otherwise you
wouldn't be doing the change.  

Fixing packaging issues that's going to solve a user visible problem,
let it be known.  On the other hand, if it's an "update" purely to fix
aesthetic things in the spec file and that don't have any sort of
functional impact, then maybe it's worth rethinking whether doing a
build and push is worth it -- everyone who has the package installed
will have to download the new one.  That doesn't come for free. 

If it's a "trivial" upstream update, there still had to be a reason for
upstream to do the release.  As an upstream developer, one of the things
I hate the most is doing releases of software just because there's so
much involved.  So there's always something that's compelling enough to
be release-worthy... that's exactly what's worth communicating.

I know that it's a little bit more to do to get a new package out, but
so are a lot of the things which have changed over time with Fedora.  I
mean, I miss the days when I could just take a piece of software, throw
together a package and voila, it ended up in rawhide.  But the value in
the review process is that it provides consistency and structure to
ensure that everyone is doing things with the same frame of mind, etc
and thus improving the quality of our packages so that our users get a
better experience.  The same idea is true here.  

All that said, there's definitely some room in most (if not all) of our
current tools and workflows to improve them and make things easier.  And
it's something that I hope we can continue to look at and improve both
to lower the bar for new contributors and make the lives of contributors
who maintain 50+ packages.  But we have to make sure that when we do so,
we don't do it at the expense of our users.  

Jeremy