[Camps-users] 2 Hackathon branches, need 1 location

Brian J. Miller brian at endpoint.com
Tue Jan 12 18:53:12 UTC 2010


Jon Jensen wrote:
> On Tue, 12 Jan 2010, Brian J. Miller wrote:
> 
>>>> Just figured it might help, I had a brian_workup branch which I can 
>>>> merge/rebase the work from the others into and use, but maintaining 
>>>> multiple branches that no one knows which will become the "master" 
>>>> seems less than desirable to me. Someone new to the project (unlikely 
>>>> I know) wouldn't know whether 'endpoint_hackathon', 'new_hackathon' 
>>>> (whatever that is...other than the most advanced branch), or 
>>>> 'brian_workup' is the desired location to do active development not 
>>>> intended for 3.x master.
> 
> Well, that actually reflects reality. There is no clear roadmap for what 
> 4.0 will look like, so there's no one branch we can ask people to 
> contribute to.
> 

Ah. Okay. Thought we'd established that a while ago when all the 
development occurred.

>>>> Additionally I'd expect if we are going to have a bunch of development 
>>>> branches, at some point (actually at various points) I'd expect us to 
>>>> want to have a central place to merge to so that work can be shared 
>>>> amongst the branches but ultimately such that the history is clean (or 
>>>> at least that is what I understood to be the general attitude).
> 
> I think most of what's on the various development branches can simply be 
> thrown away once there's a clear direction for 4.0. They're experiments 
> and unless someone finds something of value in them to rescue, they can 
> just go away eventually.
> 

Then can we discuss clear direction for 4.0 or is that just considered 
pointless now? Experiments that actually do work and could provide the 
basis for 4.x strike me as a heckuva lot further down that path than we 
otherwise are so I don't see the point in throwing the lot out the 
window just to start over again, to my knowledge nothing has 
fundamentally changed.

>>> Ultimately, I would think we would be best-served by establishing a 
>>> mirror on Github, thus enabling branching to happen at the fork level 
>>> without having to clutter the primary repository with varying lines of 
>>> development.
>> Not sure I follow the "mirror" thing. The camps repo is already on git 
>> hub or is there something more specific I'm not following? Either way 
>> until the new development became master you'd need a branch in the 
>> github mirror where the development could be shared amongst repos 
>> (forks) no?
> 
> I think Ethan is saying: Given that all the development branches were 
> experiments that didn't go anywhere, maybe we should be putting all such 
> experimentation up on GitHub under the author's own account, and only 
> worrying about where it would go in the central repo once it's determined 
> we're actually going to use it in some real version of camps. Otherwise, 
> it can live & die on GitHub and save the trouble of these conversations.
> 
> I agree with him, but since you, Brian, already have stuff on a branch on 
> the central repo, I don't care either way.
> 

Um... okay. I'll just do what I want and we'll see if it leads anywhere. 
If it is a giant waste of time, then, well, no ones feelings will be 
hurt I'll just be out the time.

Just doing my best to have *something* happen with this project.

B

-- 
Brian J. Miller
End Point Corp.
brian at endpoint.com
W: 704-376-8292


More information about the Camps-users mailing list