On Wed, 2008-02-27 at 16:15 -0600, Matt Domsch wrote:
On Tue, Feb 26, 2008 at 06:33:12PM -0600, Dennis Gilmore wrote:
> Ive considered the idea of having a web app to make srpms on demand
> for people also. It would most likely be needed there also. But it
> doesnt help with the historical data we dont have.
I started the 'correspondingsource' project on
fedorahosted.org today
exactly for such a webapp.
We have just over 85k tags for all the packages in CVS; some going
back to 2004, some only to the F7 days. Not sure yet how much history
was lost during the Core import.
We've talked about "immutable tags" before. While that would be nice,
I'd be fine with having koji add a tag in its own namespace, either
at package checkout pre-build, or on succcessful build, either way is
fine by me. These tags would not be the same tags as 'make tag'
creates, so users can force-tag if they really feel the need, but we
would more than strongly discourage force tagging on the koji
namespace tags.
I'm not really comfortable having an automated system (Koji) modifying
the SCM. Giving the Koji builders credentials to modify the SCM in a
secure way (without making those credentials available to the world)
might be tricky. It also dramatically increases the risk in the event
that a builder is compromised. Right now all Koji access to the SCM is
read-only, and it should probably stay that way.
I think immutable tags are the answer here. We already kind of assume
tags don't change once they're built, we might as well enforce it. I
know force-tag is convenient, but how much harder is it really to bump
the revision number instead?