[users] Version control at RPMForge

[Yury V. Zaytsev]

Hi guys!

I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).

I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.

I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Best,

[Dag Wieers]

Post by Yury V. Zaytsev
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

Yes, I want git too !

Post by Yury V. Zaytsev
For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

[David Hrbáč]

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...

As to me shout out let's move to git solves nothing. We need to bring up
solution which solves the points above. So let's use:
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

Regards,
David Hrb??

[Yury V. Zaytsev]

Post by David Hrbáč
Guys, well, let me repeat myself. I guess RPMForge is near clinical death.

Oh really?! That's totally news to me!!!

Post by David Hrbáč
As to me shout out let's move to git solves nothing. We need to bring
up solution which solves the points above.

Let's see. Am I talking about taking over the universe in this thread?
Not that I can remember of. I created it to the end of discussing a
small isolated issue that I came up with. So please don't hijack it. If
you want to discuss the sorry state of RPMForge, there's another recent
rant thread for this.

The move to git does solve something for me. It makes me wait less time
for the working copy to update and therefore reduces the overhead of
contributing package updates.

It might become a starting point for the migration to Trac by the way.
We have few self-hosted git-integrated Trac environments here and it
works very well to my mind.

Anything else?

[Chris Butler]

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.

In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

[David Hrbáč]

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.
David

[Yury V. Zaytsev]

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.

What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

[Dag Wieers]

Post by Yury V. Zaytsev

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Maybe we should do a fundraiser or look for donations again ?

[Yury V. Zaytsev]

Post by Dag Wieers
Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

OK, I have to admit that I am not totally correct on this. But I would
say that what everybody is waiting for is rather some kind of a formal
"go" signal from you so that we can start assembling the implementation
ideas floating around this list in a new coherent whole and actually get
to implementing it.

Post by Dag Wieers
I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

Well, to my mind, hardware is important but not that much of an issue.
Karanbir offered setting up a new build system quite awhile ago and even
made some progress on this.

He also stated, that buying hardware and installing it at his location
or at any other open source friendly network which is probably not that
hard to find (I need to get in touch with people to back this statement
up) is a much cheaper way of doing it if there's money involved.

Post by Dag Wieers
What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Hmmm, I think this is a good idea. For sure, this will get us on track
much quicker than sporadic critical discussions on the mailing list. At
this point my position is stable enough so that I can attend to a
monthly meeting for discussion, though the time I can commit to actually
implementing something is very limited.

Post by Dag Wieers
Maybe we should do a fundraiser or look for donations again ?

See my next reply to follow...

[Yury V. Zaytsev]

Post by Dag Wieers
Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

OK, I have to admit that I am not totally correct on this. But I would
say that what everybody is waiting for is rather some kind of a formal
"go" signal from you so that we can start assembling the implementation
ideas floating around this list in a new coherent whole and actually get
to implementing it.

Post by Dag Wieers
I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

Well, to my mind, hardware is important but not that much of an issue.
Karanbir offered setting up a new build system quite awhile ago and even
made some progress on this.

He also stated, that buying hardware and installing it at his location
or at any other open source friendly network which is probably not that
hard to find (I need to get in touch with people to back this statement
up) is a much cheaper way of doing it if there's money involved.

Post by Dag Wieers
What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Hmmm, I think this is a good idea. For sure, this will get us on track
much quicker than sporadic critical discussions on the mailing list. At
this point my position is stable enough so that I can attend to a
monthly meeting for discussion, though the time I can commit to actually
implementing something is very limited.

Post by Dag Wieers
Maybe we should do a fundraiser or look for donations again ?

See my next reply to follow...

[Yury V. Zaytsev]

Post by Dag Wieers
Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

OK, I have to admit that I am not totally correct on this. But I would
say that what everybody is waiting for is rather some kind of a formal
"go" signal from you so that we can start assembling the implementation
ideas floating around this list in a new coherent whole and actually get
to implementing it.

Post by Dag Wieers
I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

Well, to my mind, hardware is important but not that much of an issue.
Karanbir offered setting up a new build system quite awhile ago and even
made some progress on this.

He also stated, that buying hardware and installing it at his location
or at any other open source friendly network which is probably not that
hard to find (I need to get in touch with people to back this statement
up) is a much cheaper way of doing it if there's money involved.

Post by Dag Wieers
What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Hmmm, I think this is a good idea. For sure, this will get us on track
much quicker than sporadic critical discussions on the mailing list. At
this point my position is stable enough so that I can attend to a
monthly meeting for discussion, though the time I can commit to actually
implementing something is very limited.

Post by Dag Wieers
Maybe we should do a fundraiser or look for donations again ?

See my next reply to follow...

[David Hrbáč]

Post by Yury V. Zaytsev
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Ok, so because we are not able to move any further we can't even discuss
about it?
DH

[Yury V. Zaytsev]

Post by David Hrbáč
Ok, so because we are not able to move any further we can't even discuss
about it?

I am not in the position to advise people on what and how they should
discuss things on this list, but even though I can't speak for others,
in the ideal world I would definitively want a discussion that brings
people forward.

To take it to the extreme, I can set up a cron script to post a random
reply on this list saying something like "Damn! Dump the things you are
discussing now! There are more important issues out there. The repo is
dead.", but I guess we all agree this is of no use?

[Yury V. Zaytsev]

Post by David Hrbáč
Ok, so because we are not able to move any further we can't even discuss
about it?

I am not in the position to advise people on what and how they should
discuss things on this list, but even though I can't speak for others,
in the ideal world I would definitively want a discussion that brings
people forward.

To take it to the extreme, I can set up a cron script to post a random
reply on this list saying something like "Damn! Dump the things you are
discussing now! There are more important issues out there. The repo is
dead.", but I guess we all agree this is of no use?

[Yury V. Zaytsev]

Post by David Hrbáč
Ok, so because we are not able to move any further we can't even discuss
about it?

I am not in the position to advise people on what and how they should
discuss things on this list, but even though I can't speak for others,
in the ideal world I would definitively want a discussion that brings
people forward.

To take it to the extreme, I can set up a cron script to post a random
reply on this list saying something like "Damn! Dump the things you are
discussing now! There are more important issues out there. The repo is
dead.", but I guess we all agree this is of no use?

[Dag Wieers]

Post by Yury V. Zaytsev

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Maybe we should do a fundraiser or look for donations again ?

[David Hrbáč]

Post by Yury V. Zaytsev
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Ok, so because we are not able to move any further we can't even discuss
about it?
DH

[Dag Wieers]

Post by Yury V. Zaytsev

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Yury, I don't fully agree that things have been discussed to a state that
it is waiting for an implementation. On the other hand nothing is being
lead in a way that we do get forward. Let alone that we have the hardware
we need for doing what would like.

I for one need to get rid of my current buildsystem because it is noisy,
takes room and is no longer on par with current hardware (it's about 6
years old, first generation AMD64). But renting it is the only solution
right now.

What would be good is to have regular meetings, making minutes, tracking
progress and see where we could need help to get forward. All of that is
lacking, and discussing it (even when people are very critical, which I
don't mind) might help to get things back on track.

Maybe we should do a fundraiser or look for donations again ?

[David Hrbáč]

Post by Yury V. Zaytsev
What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

Ok, so because we are not able to move any further we can't even discuss
about it?
DH

[Dag Wieers]

Post by David Hrbáč

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key that
I haven't looked at.

If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.

So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something people
can underwrite again, that they can learn to trust. Whether it be rpmrepo,
RepoForge or both is yet to be seen.

[David Hrbáč]

Post by Dag Wieers
Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key
that I haven't looked at.

I have no objections about it. But there are and were situations when we
need push really quickly package update.

Post by Dag Wieers
If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.
So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something
people can underwrite again, that they can learn to trust. Whether it be
rpmrepo, RepoForge or both is yet to be seen.

rpmrepo is like a Columbo's wife. Everybody's talking about her, no
one's ever seen her. I still think we must go elRepo, Fedora way. Allow
multiple commiters, reviewers, build, and signin infrastructure.
David

[David Hrbáč]

Post by Dag Wieers
Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key
that I haven't looked at.

I have no objections about it. But there are and were situations when we
need push really quickly package update.

Post by Dag Wieers
If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.
So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something
people can underwrite again, that they can learn to trust. Whether it be
rpmrepo, RepoForge or both is yet to be seen.

rpmrepo is like a Columbo's wife. Everybody's talking about her, no
one's ever seen her. I still think we must go elRepo, Fedora way. Allow
multiple commiters, reviewers, build, and signin infrastructure.
David

[David Hrbáč]

Post by Dag Wieers
Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key
that I haven't looked at.

I have no objections about it. But there are and were situations when we
need push really quickly package update.

Post by Dag Wieers
If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.
So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something
people can underwrite again, that they can learn to trust. Whether it be
rpmrepo, RepoForge or both is yet to be seen.

rpmrepo is like a Columbo's wife. Everybody's talking about her, no
one's ever seen her. I still think we must go elRepo, Fedora way. Allow
multiple commiters, reviewers, build, and signin infrastructure.
David

[Yury V. Zaytsev]

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.

What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

[Dag Wieers]

Post by David Hrbáč

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key that
I haven't looked at.

If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.

So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something people
can underwrite again, that they can learn to trust. Whether it be rpmrepo,
RepoForge or both is yet to be seen.

[Yury V. Zaytsev]

Post by David Hrbáč
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

The way out of this is already known and the issue has been beaten to
death in other threads. That is just to have more than one person that
can upload packages to the buildhost. Everybody's working on this at the
pace they can afford.

What else do you want? Can you contribute something to what has already
been discussed or it's just reiterating on the issues without getting
any closer to solving them?

[Dag Wieers]

Post by David Hrbáč

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.

Well, I am unhappy about that to a certain point. Since I am the only
person who can sign it with a key that everyone using RPMforge trusts, I
cannot allow other people to push RPM packages signed by the same key that
I haven't looked at.

If we ever would go to a situation with more than one person signing, I
don't think we can do that using the same key, or even using the same
repository. Because the people giving me that trust did not have any say
in whether they trusted 5 other people.

So for me that is already one item that is not solvable within RPMforge.
That's why it requires a new 'project', a new repository, something people
can underwrite again, that they can learn to trust. Whether it be rpmrepo,
RepoForge or both is yet to be seen.

[David Hrbáč]

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.
David

[David Hrbáč]

Post by Chris Butler

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.
In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

Well,
before point 10, there is point 9."single point of person", sorry Dag
:o) And yes it'sgoot for new contributors. How many new contributors we
have?
I'm fine with process commit-> review -> build, but at rpmforge we have
process: commit->wait for Dag 1-30 days->build. It's something I have
discussed and community with Dag and I guess Dag is unhappy about that.
David

[Dag Wieers]

Post by David Hrbáč

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...
As to me shout out let's move to git solves nothing. We need to bring up
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

David, moving to git solves a very important point for me. An svn up takes
a few minutes. Other operations are fairly slow as well.

We didn't spend any time on reviving RPMforge basicly because rpmrepo was
going to surpasse it. I don't believe in that anymore, more people were
involved, little progress was made. I can't blame anyone because I didn't
contribute myself (although I did state I was not going to be able to help
a lot beyond what I was already doing).

Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

[Yury V. Zaytsev]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

You know, unfortunately I didn't / was unable to follow IRC or private
discussions, so I really have no slightest clue on the politics behind
RPMForge, rpmrepo and whatnot as well what are the reasons why someone
is holding others back. Maybe someone should try to write up a
quasi-neutral recap for the rest of us even if it's gonna hurt? At least
we all can learn something from it.

A recent story comes to my mind where problems have been been kept in a
closed circle for too long and this resulted in open letters, confusion
and FUD.

As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.

Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.

Finally, it will get going somewhere...

[David Hrbáč]

Post by Yury V. Zaytsev
As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.
Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.
Finally, it will get going somewhere...

Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.
David Hrb??

[Karanbir Singh]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Why not just use redmine instead and get the mulitple vcs backend
included right away ?

iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

- KB

[David Hrbáč]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?
iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

I don't want to start the flame, I vote for Trac.
David Hrb??

[Yury V. Zaytsev]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?

I used Trac synonymously to any project management system that
integrates wiki, ticket system, repo browser etc. Trac or Redmine I
don't care, my only consideration is that I used Trac in the past and I
will be unable to help with Redmine.

Once Dag has spoken let's get make a quick poll and get *something*
installed, be it Trac or Redmine.

[David Hrbáč]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?
iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

I don't want to start the flame, I vote for Trac.
David Hrb??

[Yury V. Zaytsev]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?

I used Trac synonymously to any project management system that
integrates wiki, ticket system, repo browser etc. Trac or Redmine I
don't care, my only consideration is that I used Trac in the past and I
will be unable to help with Redmine.

Once Dag has spoken let's get make a quick poll and get *something*
installed, be it Trac or Redmine.

[David Hrbáč]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?
iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

I don't want to start the flame, I vote for Trac.
David Hrb??

[Yury V. Zaytsev]

Post by Karanbir Singh
Why not just use redmine instead and get the mulitple vcs backend
included right away ?

I used Trac synonymously to any project management system that
integrates wiki, ticket system, repo browser etc. Trac or Redmine I
don't care, my only consideration is that I used Trac in the past and I
will be unable to help with Redmine.

Once Dag has spoken let's get make a quick poll and get *something*
installed, be it Trac or Redmine.

[Yury V. Zaytsev]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Again, the question of SCM for the time being is independent of the
project organization issues.

In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

I didn't ask to vote for git as the version control system for whatever
will stem of RPMForge, discuss project management issues, ask for the
opinions on which issues have a priority etc.

Let's keep these things separate for god's sake.

[Karanbir Singh]

Post by Yury V. Zaytsev

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

+1 for that, the last time we tried this : process engineering just got
way too much for something trying to get off the ground. I am all for
kicking things up and getting going.

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

- KB

[David Hrbáč]

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?
David

[Yury V. Zaytsev]

Post by David Hrbáč

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?

In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

[Karanbir Singh]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.

Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

- KB

[David Hrbáč]

Post by Karanbir Singh
I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.
Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.

Well, but Fedora goes still with CVS... :o)
DH

[Karanbir Singh]

Post by David Hrbáč
I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.
Well, but Fedora goes still with CVS... :o)

I dont think reinventing the wheel is good - but I also think finding
the best reasonable fit is a good idea - you need to remember that
Fedora has a large dedicated admin group and they have a policy team
with good segregation between the two. I dont think we have either the
numbers nor the traction to be able to get there right now, so lets
hedge our bets and get in something that works for us now - without
burning too many bridges we might need to cross in the future.

The focus, if there is one - should be on what comes out at the other
end and how we can make it easier for the process to churn its thing.

- KB

[Karanbir Singh]

Post by David Hrbáč
I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.
Well, but Fedora goes still with CVS... :o)

I dont think reinventing the wheel is good - but I also think finding
the best reasonable fit is a good idea - you need to remember that
Fedora has a large dedicated admin group and they have a policy team
with good segregation between the two. I dont think we have either the
numbers nor the traction to be able to get there right now, so lets
hedge our bets and get in something that works for us now - without
burning too many bridges we might need to cross in the future.

The focus, if there is one - should be on what comes out at the other
end and how we can make it easier for the process to churn its thing.

- KB

[Karanbir Singh]

Post by David Hrbáč
I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.
Well, but Fedora goes still with CVS... :o)

I dont think reinventing the wheel is good - but I also think finding
the best reasonable fit is a good idea - you need to remember that
Fedora has a large dedicated admin group and they have a policy team
with good segregation between the two. I dont think we have either the
numbers nor the traction to be able to get there right now, so lets
hedge our bets and get in something that works for us now - without
burning too many bridges we might need to cross in the future.

The focus, if there is one - should be on what comes out at the other
end and how we can make it easier for the process to churn its thing.

- KB

[David Hrbáč]

Post by Karanbir Singh
I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.
Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.

Well, but Fedora goes still with CVS... :o)
DH

[David Hrbáč]

Post by Karanbir Singh
I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.
Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

I don't like reinventing the wheel. That's why I'm talking about Fedora
infrastructure and other relevant projects.

Well, but Fedora goes still with CVS... :o)
DH

[David Hrbáč]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

Basically, rpmforge still uses Dag's build system. There's no roadmap on
new build system yet. Not every build system can handle every VCS. So
could you also investigate/sum up (offline/teoretically) cooperation GIT
vs {Koji,plaque,Dag's BS, etc.}?
Thanks,
David Hrb??

[Karanbir Singh]

Post by David Hrbáč
Basically, rpmforge still uses Dag's build system. There's no roadmap on
new build system yet. Not every build system can handle every VCS. So
could you also investigate/sum up (offline/teoretically) cooperation GIT
vs {Koji,plaque,Dag's BS, etc.}?

I think a separation in the two process's would be good. eg: have a
version control process that outputs srpms

And another process - the buildsystem - that takes the srpms and does
its build. There are a lot of clear wins around not integrating the
version control into the build system

- KB

[Yury V. Zaytsev]

Post by Karanbir Singh
I think a separation in the two process's would be good. eg: have a
version control process that outputs srpms
And another process - the buildsystem - that takes the srpms and does
its build. There are a lot of clear wins around not integrating the
version control into the build system

I definitively agree with this, that's why my first reaction to the
question whether I have considered the integration at all was the
surprise.

I guess we have to decide on the "signing style" first and only then
think on how to implement the actual generation of SRPMs from the VCS
and feeding them into the buildsystem, because all recent SCMs have some
kind of hooks etc.

[Yury V. Zaytsev]

Post by Karanbir Singh
I think a separation in the two process's would be good. eg: have a
version control process that outputs srpms
And another process - the buildsystem - that takes the srpms and does
its build. There are a lot of clear wins around not integrating the
version control into the build system

I definitively agree with this, that's why my first reaction to the
question whether I have considered the integration at all was the
surprise.

I guess we have to decide on the "signing style" first and only then
think on how to implement the actual generation of SRPMs from the VCS
and feeding them into the buildsystem, because all recent SCMs have some
kind of hooks etc.

[Karanbir Singh]

Post by David Hrbáč
Basically, rpmforge still uses Dag's build system. There's no roadmap on
new build system yet. Not every build system can handle every VCS. So
could you also investigate/sum up (offline/teoretically) cooperation GIT
vs {Koji,plaque,Dag's BS, etc.}?

I think a separation in the two process's would be good. eg: have a
version control process that outputs srpms

And another process - the buildsystem - that takes the srpms and does
its build. There are a lot of clear wins around not integrating the
version control into the build system

- KB

[Karanbir Singh]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.

Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

- KB

[David Hrbáč]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

Basically, rpmforge still uses Dag's build system. There's no roadmap on
new build system yet. Not every build system can handle every VCS. So
could you also investigate/sum up (offline/teoretically) cooperation GIT
vs {Koji,plaque,Dag's BS, etc.}?
Thanks,
David Hrb??

[Karanbir Singh]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

I think its worth just going over the list of things that we discussed
for the buildsys rehash tread. Take away points from there that could
be marked against.

Also, Jesse did a fairly comprehensive version control eval for Fedora
sometime back ( maybe 18 months or so ) - many things from there would
still be relevant, so its worth looking over. Although Hg and Git have
both moved fairly rapidly in the last year

- KB

[David Hrbáč]

Post by Yury V. Zaytsev
In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

Basically, rpmforge still uses Dag's build system. There's no roadmap on
new build system yet. Not every build system can handle every VCS. So
could you also investigate/sum up (offline/teoretically) cooperation GIT
vs {Koji,plaque,Dag's BS, etc.}?
Thanks,
David Hrb??

[Yury V. Zaytsev]

Post by David Hrbáč

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?

In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

[Yury V. Zaytsev]

Post by David Hrbáč

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?

In which way it should be build infrastructure oriented? Can you outline
any specific needs that have to be covered?

[David Hrbáč]

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?
David

[David Hrbáč]

Post by Karanbir Singh

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

If you start evaluation, would you mind evaluation also being build
infrastructure oriented?
David

[Karanbir Singh]

Post by Yury V. Zaytsev

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

+1 for that, the last time we tried this : process engineering just got
way too much for something trying to get off the ground. I am all for
kicking things up and getting going.

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

- KB

[Karanbir Singh]

Post by Yury V. Zaytsev

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

+1 for that, the last time we tried this : process engineering just got
way too much for something trying to get off the ground. I am all for
kicking things up and getting going.

Post by Yury V. Zaytsev
In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

So, well what do you need that I could help with ? I've got some scripts
around that I used in the past to convert the entire rpmforge svn into
smaller per-package git repo's etc. Would that help ?

- KB

[Karanbir Singh]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Why not just use redmine instead and get the mulitple vcs backend
included right away ?

iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

- KB

[Yury V. Zaytsev]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Again, the question of SCM for the time being is independent of the
project organization issues.

In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

I didn't ask to vote for git as the version control system for whatever
will stem of RPMForge, discuss project management issues, ask for the
opinions on which issues have a priority etc.

Let's keep these things separate for god's sake.

[Karanbir Singh]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Why not just use redmine instead and get the mulitple vcs backend
included right away ?

iirc, there are people on the list here who have used redmine in the
past ( and also offered to help get it going! )

- KB

[Yury V. Zaytsev]

Post by David Hrbáč
Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.

Again, the question of SCM for the time being is independent of the
project organization issues.

In the first post I suggested MY help in *evaluating* (this means trying
it out and seeing whether it has any compelling advantages / major
disadvantages) the migration to git, ok?

I didn't ask to vote for git as the version control system for whatever
will stem of RPMForge, discuss project management issues, ask for the
opinions on which issues have a priority etc.

Let's keep these things separate for god's sake.

[David Hrbáč]

Post by Yury V. Zaytsev
As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.
Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.
Finally, it will get going somewhere...

Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.
David Hrb??

[David Hrbáč]

Post by Yury V. Zaytsev
As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.
Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.
Finally, it will get going somewhere...

Yep, trac instance, stick with SVN for time being. I'm not going to
waste time again as like with rpmrepo.
David Hrb??

[David Hrbáč]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use
it and since I don't believe rpmrepo is going anywhere I needed a new
domain name, which I registered as repoforge.org (close enough to
RPMforge, and we can keep the rf tag) so we can finally have a proper
name for the repository location, for mirrors, and other infrastructure.

I'm fine with that. And again, I'm prepared to help and even donate VMs.
Regards,
David Hrb??

[Yury V. Zaytsev]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

You know, unfortunately I didn't / was unable to follow IRC or private
discussions, so I really have no slightest clue on the politics behind
RPMForge, rpmrepo and whatnot as well what are the reasons why someone
is holding others back. Maybe someone should try to write up a
quasi-neutral recap for the rest of us even if it's gonna hurt? At least
we all can learn something from it.

A recent story comes to my mind where problems have been been kept in a
closed circle for too long and this resulted in open letters, confusion
and FUD.

As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.

Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.

Finally, it will get going somewhere...

[David Hrbáč]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use
it and since I don't believe rpmrepo is going anywhere I needed a new
domain name, which I registered as repoforge.org (close enough to
RPMforge, and we can keep the rf tag) so we can finally have a proper
name for the repository location, for mirrors, and other infrastructure.

I'm fine with that. And again, I'm prepared to help and even donate VMs.
Regards,
David Hrb??

[Yury V. Zaytsev]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

You know, unfortunately I didn't / was unable to follow IRC or private
discussions, so I really have no slightest clue on the politics behind
RPMForge, rpmrepo and whatnot as well what are the reasons why someone
is holding others back. Maybe someone should try to write up a
quasi-neutral recap for the rest of us even if it's gonna hurt? At least
we all can learn something from it.

A recent story comes to my mind where problems have been been kept in a
closed circle for too long and this resulted in open letters, confusion
and FUD.

As for going forward, let's just make a decision. Dump everything and
start from scratch learning from previous errors? Repoforge? OK with me.
Let's register a domain, set up a KVM instance with Trac to use it as a
wiki / bugzilla and the others will take it from there.

Then we can schedule meetings, post logs on the wiki, announce the
fundraiser, consider the migration to a new buildhost etc.

Finally, it will get going somewhere...

[David Hrbáč]

Post by Dag Wieers
Since Matthias, who owns the rpmforge.net domain doesn't want us to use
it and since I don't believe rpmrepo is going anywhere I needed a new
domain name, which I registered as repoforge.org (close enough to
RPMforge, and we can keep the rf tag) so we can finally have a proper
name for the repository location, for mirrors, and other infrastructure.

I'm fine with that. And again, I'm prepared to help and even donate VMs.
Regards,
David Hrb??

[Yury V. Zaytsev]

Post by David Hrbáč
Guys, well, let me repeat myself. I guess RPMForge is near clinical death.

Oh really?! That's totally news to me!!!

Post by David Hrbáč
As to me shout out let's move to git solves nothing. We need to bring
up solution which solves the points above.

Let's see. Am I talking about taking over the universe in this thread?
Not that I can remember of. I created it to the end of discussing a
small isolated issue that I came up with. So please don't hijack it. If
you want to discuss the sorry state of RPMForge, there's another recent
rant thread for this.

The move to git does solve something for me. It makes me wait less time
for the working copy to update and therefore reduces the overhead of
contributing package updates.

It might become a starting point for the migration to Trac by the way.
We have few self-hosted git-integrated Trac environments here and it
works very well to my mind.

Anything else?

[Chris Butler]

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.

In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

[Dag Wieers]

Post by David Hrbáč

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...
As to me shout out let's move to git solves nothing. We need to bring up
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

David, moving to git solves a very important point for me. An svn up takes
a few minutes. Other operations are fairly slow as well.

We didn't spend any time on reviving RPMforge basicly because rpmrepo was
going to surpasse it. I don't believe in that anymore, more people were
involved, little progress was made. I can't blame anyone because I didn't
contribute myself (although I did state I was not going to be able to help
a lot beyond what I was already doing).

Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

[Yury V. Zaytsev]

Post by David Hrbáč
Guys, well, let me repeat myself. I guess RPMForge is near clinical death.

Oh really?! That's totally news to me!!!

Post by David Hrbáč
As to me shout out let's move to git solves nothing. We need to bring
up solution which solves the points above.

Let's see. Am I talking about taking over the universe in this thread?
Not that I can remember of. I created it to the end of discussing a
small isolated issue that I came up with. So please don't hijack it. If
you want to discuss the sorry state of RPMForge, there's another recent
rant thread for this.

The move to git does solve something for me. It makes me wait less time
for the working copy to update and therefore reduces the overhead of
contributing package updates.

It might become a starting point for the migration to Trac by the way.
We have few self-hosted git-integrated Trac environments here and it
works very well to my mind.

Anything else?

[Chris Butler]

Post by David Hrbáč
10. commit access is fine, but without build trigger etc., totally
useless...

I wouldn't say it's useless.. what's to stop you contributing a new/updated
package to the repo, then pinging someone with build access to review/build
the package? In fact, this is a good way to train up new contributors.

In my other (non-work) life as a Debian developer, we have something similar
to the above for Perl module packaging.

[Dag Wieers]

Post by David Hrbáč

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...
As to me shout out let's move to git solves nothing. We need to bring up
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

David, moving to git solves a very important point for me. An svn up takes
a few minutes. Other operations are fairly slow as well.

We didn't spend any time on reviving RPMforge basicly because rpmrepo was
going to surpasse it. I don't believe in that anymore, more people were
involved, little progress was made. I can't blame anyone because I didn't
contribute myself (although I did state I was not going to be able to help
a lot beyond what I was already doing).

Since Matthias, who owns the rpmforge.net domain doesn't want us to use it
and since I don't believe rpmrepo is going anywhere I needed a new domain
name, which I registered as repoforge.org (close enough to RPMforge, and
we can keep the rf tag) so we can finally have a proper name for the
repository location, for mirrors, and other infrastructure.

[Yury V. Zaytsev]

Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)

There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

Post by Dag Wieers
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

The usage of git highly depends on your workflow, the complexity of
which might range from elementary to extremely complicated. As I
mentioned, if we consider the current usage of svn, a typical git
workflow and the commands that everyone needs to know are summarized
below:

git clone ... # to check out the repository (once)
git pull # to pull and merge latest published changes
git status # to show locally changed files
git add file1 file2 # to add local changes to the commit list
git commit # to commit changes locally
git push # to publish changes online
git checkout file # to discard local changes to a file
git reset --hard # to discard all local changes

No real difference in the operation is expected other than the necessity
to push changes online once they are committed. However, I, of course,
want to hear from others to see whether they follow me or not, that's
why I sent the email out loud.

Post by Dag Wieers
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

A pessimistic estimate for the storage space that a converted git
repository (retaining all of the svn history) might take, considering
the size of my checkout would be in the range of 1 Gb, but most probably
considerably less.

If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

[Karanbir Singh]

Post by Yury V. Zaytsev
If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

If you send me a key and ip list that you will connect from, I can get
you setup with a vm fairly instantly. However, i think we should
consider first talking about exactly what the move to git means, and how
its going to be done.

Just moving the svn tree as-is, into a git repo, isnt going to really
solve too many issues down the road. There would be some level of
flexibility with sub-modules and perhaps external scripts to manage
'sets' of git-repo's; but that then again induces a fairly high (
compared with svn ) level of admin overhead.

- KB

[Tom G. Christensen]

Post by Yury V. Zaytsev
Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)
There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

I promised updates for that, I haven't delivered for RPMforge since the
initial update was never built :(

For those who need it now I keep updated builds here:
http://jupiterrise.com/blog/jrpms/

-tgc

[Karanbir Singh]

Post by Yury V. Zaytsev
If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

If you send me a key and ip list that you will connect from, I can get
you setup with a vm fairly instantly. However, i think we should
consider first talking about exactly what the move to git means, and how
its going to be done.

Just moving the svn tree as-is, into a git repo, isnt going to really
solve too many issues down the road. There would be some level of
flexibility with sub-modules and perhaps external scripts to manage
'sets' of git-repo's; but that then again induces a fairly high (
compared with svn ) level of admin overhead.

- KB

[Tom G. Christensen]

Post by Yury V. Zaytsev
Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)
There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

I promised updates for that, I haven't delivered for RPMforge since the
initial update was never built :(

For those who need it now I keep updated builds here:
http://jupiterrise.com/blog/jrpms/

-tgc

[Karanbir Singh]

Post by Yury V. Zaytsev
If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

If you send me a key and ip list that you will connect from, I can get
you setup with a vm fairly instantly. However, i think we should
consider first talking about exactly what the move to git means, and how
its going to be done.

Just moving the svn tree as-is, into a git repo, isnt going to really
solve too many issues down the road. There would be some level of
flexibility with sub-modules and perhaps external scripts to manage
'sets' of git-repo's; but that then again induces a fairly high (
compared with svn ) level of admin overhead.

- KB

[Tom G. Christensen]

Post by Yury V. Zaytsev
Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)
There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

I promised updates for that, I haven't delivered for RPMforge since the
initial update was never built :(

For those who need it now I keep updated builds here:
http://jupiterrise.com/blog/jrpms/

-tgc

[David Hrbáč]

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...

As to me shout out let's move to git solves nothing. We need to bring up
solution which solves the points above. So let's use:
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

Regards,
David Hrb??

[Yury V. Zaytsev]

Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)

There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

Post by Dag Wieers
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

The usage of git highly depends on your workflow, the complexity of
which might range from elementary to extremely complicated. As I
mentioned, if we consider the current usage of svn, a typical git
workflow and the commands that everyone needs to know are summarized
below:

git clone ... # to check out the repository (once)
git pull # to pull and merge latest published changes
git status # to show locally changed files
git add file1 file2 # to add local changes to the commit list
git commit # to commit changes locally
git push # to publish changes online
git checkout file # to discard local changes to a file
git reset --hard # to discard all local changes

No real difference in the operation is expected other than the necessity
to push changes online once they are committed. However, I, of course,
want to hear from others to see whether they follow me or not, that's
why I sent the email out loud.

Post by Dag Wieers
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

A pessimistic estimate for the storage space that a converted git
repository (retaining all of the svn history) might take, considering
the size of my checkout would be in the range of 1 Gb, but most probably
considerably less.

If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

[David Hrbáč]

Post by Dag Wieers
Yes, I want git too !
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

Guys, well, let me repeat myself. I guess RPMForge is near clinical death.
1. repo is running
2. so huge, without sqlite
3. some packages are broken, huge portion unused/outdated
4. no buglist
5. no web commit viewer
6. no wiki
7. no build access
8. problems with mirrors
9. "single point of person", sorry Dag :o)
10. commit access is fine, but without build trigger etc., totally
useless...
11. ...

As to me shout out let's move to git solves nothing. We need to bring up
solution which solves the points above. So let's use:
1. self-hosted trac environment
2. Google Code
3. http://gitorious.org
4. SourceForge
5. http://github.com/
6. ...

Regards,
David Hrb??

[Yury V. Zaytsev]

Hi!

Post by Dag Wieers
Yes, I want git too !

Well, just to have it is not that much of an issue :-)

There's a sucky but reasonably well-maintained git package at EPEL and a
package that I guess follows Fedora more closely contributed by Tom G.
Christensen. We, or, more specifically, I have to finally review and
build test it, and basically that's it.

Post by Dag Wieers
It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

The usage of git highly depends on your workflow, the complexity of
which might range from elementary to extremely complicated. As I
mentioned, if we consider the current usage of svn, a typical git
workflow and the commands that everyone needs to know are summarized
below:

git clone ... # to check out the repository (once)
git pull # to pull and merge latest published changes
git status # to show locally changed files
git add file1 file2 # to add local changes to the commit list
git commit # to commit changes locally
git push # to publish changes online
git checkout file # to discard local changes to a file
git reset --hard # to discard all local changes

No real difference in the operation is expected other than the necessity
to push changes online once they are committed. However, I, of course,
want to hear from others to see whether they follow me or not, that's
why I sent the email out loud.

Post by Dag Wieers
I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

A pessimistic estimate for the storage space that a converted git
repository (retaining all of the svn history) might take, considering
the size of my checkout would be in the range of 1 Gb, but most probably
considerably less.

If you set up a small KVM host with a minimal install of EL5 or Ubuntu
Lucid or whatnot for me I can play around it and follow up on the
mailing list with the results. One day :-)

[Karanbir Singh]

Post by Yury V. Zaytsev
Hi guys!
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

But you can, with svn, just checkout the bit of tree you want to be
working on and ignore the rest!

Similarly with git-svn you can just work on one set of the tree.

Post by Yury V. Zaytsev
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Hosting it wont be a problem, if we can workout exactly how the tree is
going to be split. Are you proposing that the entire svn repo is
imported into one single git repo ?

I am really not sure how productive that is going to be.

- KB

[Yury V. Zaytsev]

Hi guys!

I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).

I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.

I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Best,

[Dag Wieers]

Post by Yury V. Zaytsev
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

Yes, I want git too !

Post by Yury V. Zaytsev
For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

[Karanbir Singh]

Post by Yury V. Zaytsev
Hi guys!
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

But you can, with svn, just checkout the bit of tree you want to be
working on and ignore the rest!

Similarly with git-svn you can just work on one set of the tree.

Post by Yury V. Zaytsev
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Hosting it wont be a problem, if we can workout exactly how the tree is
going to be split. Are you proposing that the entire svn repo is
imported into one single git repo ?

I am really not sure how productive that is going to be.

- KB

[Yury V. Zaytsev]

Hi guys!

I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).

I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.

I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Best,

[Dag Wieers]

Post by Yury V. Zaytsev
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

Yes, I want git too !

Post by Yury V. Zaytsev
For the reason that we don't have any special SCM workflow other than
just doing svn update / svn commit all the time, I think that the
migration to git will not actually influence anyone in any way other
than use git pull / git commit / git push instead (well, you can create
an alias to merge the latter two into a single command).
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

It shouldn't be hard to move to git, but we have to first make sure that
everyone knows how to use git (I haven't used it myself either) and
convert the current data to git so we retain the versioning history.

I can use the system at Hetzner for this, which is a KVM host with a few
guests. Later we can migrate it to somewhere else.

[Karanbir Singh]

Post by Yury V. Zaytsev
Hi guys!
I just want to share something that came to my mind. I am definitively
tired of waiting for 5-10 minutes for my local svn checkout to update.
By contrast, I've been using git for version control on some other
projects and it's proved to be crazy fast, way much faster the svn in
this respect.

But you can, with svn, just checkout the bit of tree you want to be
working on and ignore the rest!

Similarly with git-svn you can just work on one set of the tree.

Post by Yury V. Zaytsev
I think I can create a git mirror of the current svn repository and
publish it for anyone to use / try to use it with git-svn bridge for
some time. If it proves itself drastically quicker than svn maybe we can
consider a migration.
I don't have a host (big enough) for it though ATM. If anyone is willing
to provide me with a small VM to this end this would be very welcome.

Hosting it wont be a problem, if we can workout exactly how the tree is
going to be split. Are you proposing that the entire svn repo is
imported into one single git repo ?

I am really not sure how productive that is going to be.

- KB