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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
