Mailinglist Archive: opensuse-gnome (57 mails)
| < Previous | Next > |
Re: [opensuse-gnome] Status of G:F:N merge
- From: Vincent Untz <vuntz@xxxxxxxxxxxx>
- Date: Mon, 2 Feb 2009 05:26:14 +0100
- Message-id: <20090202042614.GC2992@xxxxxxxxx>
Le lundi 02 février 2009, à 14:50 +1100, Magnus Boman a écrit :
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-gnome+help@xxxxxxxxxxxx
| < Previous | Next > |