On Fri, Oct 29, 2010 at 07:01:49AM -0400, Eric Sparks Christensen wrote:
> While you're thoughts are certainly right, I'd tend to
say that they're
> not relevant for the review as the review is for the fedora packages and
> it needs to be checked to work against what is currently in fedora.
While I might agree that they aren't relevant for the review
(the
package meets current standards) I think we are just trying to figure
out a way to make this a smooth transition and remedy a problem that
was identified during the review. But like Paul said, it's completely
up to the packager. If you want to maintain several packages of the
same software then that is your decision.
I guess I'm just frustrated by the fact that a pretty simple review
takes that long even for a project where there are multiple people
interested in moving it forward.
Don't get me wrong - discussing drupal vs. drupal6 was important (hell -
I even stared the discussion) but now that we have come to an agreement
I guess that moving a little faster would be helpful in staying focused
on the issue at hand.
I'll try to do the rename-reviews that Jon has posted over the weekend.
> As for the fedora/rhel-conditional - I'm not sure if it's
still
> neccessary to keep specs in sync across releases now that we can use
> the wonders of git and it's merges but that's up for the packager to
> decide and also not relevant in a fedora review request.
Agreed. However these were problems that were identified during
review. Had it been my package I would have wanted assistance on
making my package as fluid as possible so I wouldn't have to remember
that I have five different SPECs for the same package that all have to
be individually changed when an update is presented. Again, I believe
this to be up to the packager to accept the recommendations or not.
Flexifilter has already been approved so this isn't going to affect
the status of that package, just trying to making maintenance easier.
My thoughts on having a single spec for multiple branches are that this
is in general a pretty ugly hack as it means that we either cannot use
new rpm/buildsystem features in newer branches or need to add lots of
if/else statements around their use.
Now that git has arrived it is perfectly reasonable to have a
full-featured current spec in master, have a slightly different spec in
EL-5 and still merge changes from master down to EL-5 even though EL-5
is different in some places.
So:
master has "Requires: drupal6"
f-14 has "Requires: drupal"
el-5 has "Requires: drupal6"
If that is in git then it would still be possible, to update master to a
new package-release, and merge the "new version"-changes down through to
el-5 without loosing the changed "Requires" line. So the need for "one
spec fits all" went down a lot with the move from cvs to git.
--
sven === jabber/xmpp: sven(a)lankes.net