Incompatibility of OpenUru.org and H-uru CWE repositories

[rarified]

Ok folks, we're veering off topic again. I think concerns with an individuals behavior should be presented in a PM to JW, Mac, or myself. Remember, OpenUru.org is not another forum; problems the happened there will hopefully stay there.

My own digression: You and others are right, we have built a goober without a manual to describe how to use the goober. It is a common fault of engineering oriented people; the feeling that something should be obvious to use once it's assembled. An assumption of familiarity with systems and processes is one cause. Another is the consequence of depending on volunteer work, which almost never can adhere to a schedule. But that doesn't mean either that the goober, nor the planning around it is fatally flawed.

I started to construct a reply to Hoikas' technical suggestions, but succumbing to one of my own weaknesses, it grew into a monster post that needs to be trimmed down. I'll continue to work on it, but the synopsis is:

Ease of use (which really was more repository management). Fork/clone and branch are both workable paradigms. Using branches for tracking divergent functionality does not dimiinish the viability of a Mercurial repository as a true distributed VCS. The single repository can be cloned and each clone is as autonomous as a clone taken from a single-function repository. Using either branches or forks creates complexity when it comes to transferring content from one thread to the other. I'm not deaf to either paradigm, and have been trying variations of each in the background to get a feel for how it could be used, and how it could be described in a process document.

I'm not familiar with gitorious, and at this moment I probably shouldn't take time to investigate it. If you had a particular function in mind that it provides could you drop a couple of lines about what that function is, and why you feel it's needed? That helps me get a better understanding of your needs.

When you talk about "pull requests" are you talking about the current requirement for a Foundry account to be able to pull or clone from OpenUru? I expect to resolve that, but can't put an exact time on it. If "pull request" means something else to you, could you elaborate a bit?

Don't make the Atlassian tools mandatory I understand the items you mention, but I'm not sure I see an obvious alternative. We went through evaluations of several simpler trackers, and there were always something that wasn't functional, a way to handle an example situation, or an administrative load (including the need to customize the tool) that eventually caused us to stop consideration of those tools. Propose one or more you would like to see.

Do some work yourselves I'd love to. I don't think the only contribution I can make is assembling tools, although that is something I'm pretty good at, and it needs doing. But I too am a volunteer and have to place priority on professional and some personal tasks, which makes it hard to often commit to a timetable for Uru. I'm on vacation as I type this, and recharging still takes precedence. Which is why you see the "grand ideas" pop out at times, only to be met with a long period of inactivity.

_R

[JWPlatt]

When you talk about "pull requests" are you talking about the current requirement for a Foundry account to be able to pull or clone from OpenUru? I expect to resolve that, but can't put an exact time on it. If "pull request" means something else to you, could you elaborate a bit?

Just to facilitate on this a bit, I suspect all we have to do is look at how github or Bitbucket works with clone tracking and pull requests. I think they are precisely what Adam has in mind - not so much the anonymous access, though that is important too. I suspect a Bitbucket mirror would be useful to both these purposes, which is something Branan also asked about.

[Hoikas]

When you talk about "pull requests" are you talking about the current requirement for a Foundry account to be able to pull or clone from OpenUru? I expect to resolve that, but can't put an exact time on it. If "pull request" means something else to you, could you elaborate a bit?

Just to facilitate on this a bit, I suspect all we have to do is look at how github or Bitbucket works with clone tracking and pull requests. I think they are precisely what Adam has in mind - not so much the anonymous access, though that is important too. I suspect a Bitbucket mirror would be useful to both these purposes, which is something Branan also asked about.

I was about to respond to rarified's post, then I read this. So I'll put a big, hearty "THIS" here.

I'm not familiar with gitorious, and at this moment I probably shouldn't take time to investigate it. If you had a particular function in mind that it provides could you drop a couple of lines about what that function is, and why you feel it's needed? That helps me get a better understanding of your needs.

Probably not, it can be a bit disconcerting if you're not used to the typical "fork and pull" DVCS workflow. What I really like from github, gitorious, bit bucket, etc. are the pull requests. Only trusted developers have commit access to the main repository, everyone else (and even those trusted developers in most cases) will fork their own copy of the repository. The new fork is hosted on the same site and the DVCS is able to track history of where the fork diverged. After our hypothetical developer is done with his contribution, (s)he will issue a "pull request," which says "I'm done coding! Review my code and merge it if you like it!" In the DVCS workflow, branches are most useful in personal forks where you might be working on more than one feature.

Github has a nice help article on Pull Requests if you have a little spare time.

Don't make the Atlassian tools mandatory I understand the items you mention, but I'm not sure I see an obvious alternative. We went through evaluations of several simpler trackers, and there were always something that wasn't functional, a way to handle an example situation, or an administrative load (including the need to customize the tool) that eventually caused us to stop consideration of those tools. Propose one or more you would like to see.

Unfortunately, I don't see an alternative. Gitorious probably has a nice issue tracker, but it's a bit late in the ball game for that. I wouldn't want you to throw away all the hard work you guys did to get the licenses. This was mostly a personal preference.

Do some work yourselves I'd love to. I don't think the only contribution I can make is assembling tools, although that is something I'm pretty good at, and it needs doing. But I too am a volunteer and have to place priority on professional and some personal tasks, which makes it hard to often commit to a timetable for Uru. I'm on vacation as I type this, and recharging still takes precedence. Which is why you see the "grand ideas" pop out at times, only to be met with a long period of inactivity.

I can understand parts of what you're saying (I'm not in the professional world quite yet). I do all the administration tasks at the GoW, and they can get time consuming and annoying. After you're done fixing the site, you really don't want to code. Still, I want to see some more not me, branan, Zrax, or Paradox contributions. Developers aren't running like mad to contribute to CWE, so we're going to have to pull a lot of weight, unfortunately. I say in our IRC channel "I wish there were 50 more of branan/myself/Zrax/whoever is doing the most awesome stuff. Think how much stuff we could get done!"

I *think* I responded to everything and hopefully made sense. Please let me know if I missed something

EDIT: Wow, I managed to put something that belonged at the end of the post in the middle.

[JWPlatt]

This is very useful. We'll be with you shortly (OU time), probably under a new topic, so hang in there. Again, this is more rarified's domain, but your second suggestion - ease of use - has swayed my thinking toward at least one of your preferences in the recommendations I'll make. I was already with you on others.

Thanks.