[packagers] Infrastructure - version control

Yury V. Zaytsev yury at shurup.com
Mon Apr 4 21:57:23 CEST 2011


Hi Karanbir!

On Mon, 2011-04-04 at 15:38 +0100, Karanbir Singh wrote:

> On 04/03/2011 10:03 PM, Yury V. Zaytsev wrote:
> > https://github.com/zyv/rpmforge
> 
> took a while to load, but it got there in the end :)

Yes, it's a bit inconvenient. In my case, if I am on a fast link, the
browser freezes for a few seconds and then the page loads, otherwise it
shows up but the list takes awhile to load.

I traced this back to AJAX mechanism they use to load the commit info
for each particular file or directory. I think this information is not
terribly important for us, and it would be nicer if the page loads
instantaneously.

I have filled a support request with GitHub, hopefully they will be able
to do something about it:

http://support.github.com/discussions/site/3315-disable-fetchnig-commit-info-when-repo-has-x-files

> That is/could be mostly a process thing. eg. if patch submission is via 
> a pull request only, no ACLs needed for anything. A couple of people 
> with 'release' privileges could do the needful.

Agreed. And I am willing to review and grant pull requests for
occasional contributors whenever I have time to do so, as opposed to
granting them access to a restricted portion of the tree...

Actually, I think this would work pretty well with our model, when there
is a (rather small) number of committers that have access to the whole
tree and a number of contributors that issue pull requests or post
format-patches to the mailing list.

Finally, it will streamline the contributions and make them much easier
to accept. Frankly speaking, we are not dealing with contributions very
well nowadays. Often, patches float around the mailing lists for ages
and never get reviewed (so that the contributor has a chance to fix
stuff) and committed.

So, why is that? It turns out that there are objective reasons for it.
I, for instance, spend quite a bit of time taking out SPECs from the
SRPMS that people post on the list, or figuring what the diff that they
posted is made against, or re-request patches in a correct format etc.

And you can't blame the contributors for that because the submission
guidelines are non-existant, many don't even know about our SVN URL,
take the SPECs out of the SRPMS etc.

Compare this with a fork on GitHub and a pull request or a checkout,
commit and format-patch posted to the list... It's a totally different
level of overhead that I would need to deal with while accepting the
contributions.

Ok, I kind of got off-track easily. The thing is, that I don't see
folder-grained ACLs as something that is all so terribly important, but
decided to mention that it *is* possible with git anyway... 

> git will soon let you do sub-tree checkouts :) depth of checkout works 
> now. So you dont really need to checkout the whole tree + history anyway.

GitHub is offering sub-tree svn checkouts (in beta) right now ;-)

> btw, given that hooks can work online/offline as well, I'd vote to leave 
> the tree on github.

Damnit :-) you see already where I'm heading... ;-)
 
-- 
Sincerely yours,
Yury V. Zaytsev




More information about the packagers mailing list