Re: autoqa-0.5.1-1 moved into -testing repository
My confusion was around the commit+cherry-pick order. I wasn't
sure if
it made a difference to commit to the 'release-0.Y' branch first, then
cherry-pick into 'master'. My instinct, based on our previous commit
behavior, was to commit to 'master' first. My thought was that
'master'
should be the first branch to see the changes. But like you said, as
long as the commits live in both, order isn't important?
As long as you make the changes locally and then push both branches simultaneously I
believe there is no difference. There is no connection between the original commit and the
cherry-picked one. You can't tell them apart, tell who's the ancestor and
who's the child. (Maybe just by looking at the commit time).
My thought on the autoqa.spec is that I'm trying to find a way for the
autoqa.spec to live independently in the 'master' and 'release-0.Y'
branches. For example, I'd like for the .spec to be generated, not
hand-crafted. In 'master', the spec would always produce some
pre-release (or git-based) version. While in release, it would produce
a matching released version ... with appropriate %changelogs.
Just a reminder, the specfile's changelog should presumably contain only packaging
changes, and we should have a separate ChangeLog file to describe source code changes.
I'll try to draft a patch soon.
When
comparing package NVR's, the package built in master would always be
newer than what is built in a released branch. Anyway, that's the
idea ... not yet sure how to implement that.
Maybe this situation is caused by the fact that we integrate both source code and
packaging files in a single repository? Because if we only maintain autoqa source code,
and autoqa.spec lives in Fedora Git, that changes the situation, right? You can then
maintain separate spec files for separate autoqa packages (e.g. packages
"autoqa", "autoqa-testing", "autoqa-unstable", etc).