Le lundi 02 février 2009, à 14:50 +1100, Magnus Boman a écrit :
And also, I'd like to have a discussion about what was good/bad with using G:F:N while Factory was frozen. After all, the merge did take a bit longer than I think anyone expected (I do know that you did a whole lot more than only merging but if there's something we can improve next time around, we should talk about it)
Sure. So, what went wrong, on the review side: + not enough reviewers: - Novell people were too busy - no outsider yet. This can only improve, because we now have people contributing to packaging, and so they will gain experience. + reviewer stupid enough to fix various other things during the review (I upstreamed/removed patches, cleaned up various things, etc.) => this is actually the thing that took most of the time + non-necessary changes in the spec files that make the review harder. Changes like %configure -> %{configure} add to the noise (and I disagree with this change, but that's another topic ;-)). I don't think we should take G:F:N as an opportunity to clean up the packaging since this makes the review task harder. This should instead be done in G:F, when we don't update 100 packages at a time. + patches that were removed from spec file, but not from the build service. Well, not just patches. Files in general. + incomplete .changes. It's important to know when a patch is updated/add/removed, and why. It's also important to know why this thing in the packaging was changed. A good .changes entry is a good way to make the review much faster. (FWIW, I'm in no way doing perfect .changes entry either, but I'm trying to force myself to document everything and avoid vague statements like "Clean up everything" -- something I used to do a lot ;-)) + fwiw, having the upstream changes in .changes helps here. Eg, I can quickly see if upstream had a new feature that requires some new dependency or new flag this way. So, painful for the packager, helpful for the reviewer. + should have had reviews at the beginning: the common mistakes that were done in many packages (don't ask me what now ;-)) could have been avoided if highlighted after the first submissions On the packaging side: + new packages in Factory that broke stuff. There were two main things that usually broke: - Release tag. Not sure we can do anything there, since the Version tag is one line above, so we'll have a conflict. - .changes files. A potential solution here is to use another file for the .changes entry. Like gnome-panel.changes.next. Don't know. The build service could be more helpful there... + anything else? Those are the obvious things. -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-gnome+help@opensuse.org