Conversely, we've had several situations lately where critical UX patches have 
been delayed because it's cumbersome right now for non-committers to contribute 
back to uPortal.

- Jen


On Aug 31, 2011, at 3:12 PM, Cris J Holdorph wrote:

> Call me pessimistic, but...  there seem to be two givens in the world of 
> software that concern me with this change at this time.
> 
> 1) a ".0" release is notoriously not perfect and is usually followed on very 
> quickly by a .1 release shortly after to fix some glaring bug that will 
> prevent most people from using it.
> 
> 2) switching to a new source code control system is a slow process that takes 
> a while to get over all the hurdles of process, development, migration, etc.
> 
> So, there's no guarantee either one of these would be true for uportal, 
> but... if they were.  Then we could be in a situation where we're unable to 
> produce a critically needed 4.0.1 release, because we're not completely up to 
> development speed on git.
> 
> For example, what if there is an import/export bug, you want Drew Wills to 
> fix.  He's the best guy for the job.  If the code was still in svn, he 
> probably still has a checkout of it and he can take a look at it today.  But 
> if the code only exists in git,  he might not have gotten around to doing 
> anything with git yet.  Even the github svn url you can use, would still 
> require him changing his environment.
> 
> My 'vote' was 0.  Basically I'm saying I won't stand in the way of it 
> happening, but I don't believe the time is right to fully support it right 
> now either.
> 
> ---- Cris J H
> 
> On 08/31/2011 02:05 PM, Eric Dalquist wrote:
>> I'm curious as yo why the concern about the closeness to the 4.0
>> release? I was actually thinking that doing the switch as soon as
>> possible after 4.0 would be better as it would give more time for
>> developers to get used to the change before a 4.0.1 is needed.
>> 
>> -Eric
>> 
>> On 8/31/11 3:05 PM, Cris J Holdorph wrote:
>>> +/- 0
>>> 
>>> I think making this change so soon after the uPortal 4.0.0 release, is
>>> a mistake. I think it would be better to let that release simmer for a
>>> while to shake out if there were any major problems.
>>> 
>>> If this vote was to take place in a month, or at least 2 weeks after
>>> some university was running uPortal 4.0.0 in production, then my vote
>>> might be different.
>>> 
>>> ---- Cris J H
>>> 
>>> On 08/31/2011 12:26 PM, Eric Dalquist wrote:
>>>> I'd like to see uPortal's source code moved to git and hosted on GitHub.
>>>> There have been quite a few folks that have been working on uPortal 4,
>>>> uMobile or are otherwise interested that have asked about using git.
>>>> After looking into it a bit more I think it would be a very valuable
>>>> change for uPortal.
>>>> 
>>>> For those not familiar Git is a _distributed_ source control tool. What
>>>> that means is there is no true central repository like there is with
>>>> SVN. Developers don't really checkout some version of the code, they
>>>> clone the entire project when doing work. That doesn't prevent the
>>>> convention of a central repository which is what a site like GitHub
>>>> provides. A place to host a clone of the project that by convention we
>>>> agree is the master copy of the project.
>>>> 
>>>> GitHub adds some very nice social-coding aspects to git. Primarily it
>>>> provides a VERY easy interface that allows anyone to clone a project,
>>>> make changes and commit them to their clone, then make a pull request on
>>>> the master project. Once that has happened a simple click of a button is
>>>> all it takes for any developer with commit access on the master to
>>>> accept the changes and merge them in. This process makes it very easy
>>>> for people without direct commit access to commit changes that are
>>>> reviewed by a core developer before merging in and significantly
>>>> simplifies the work of the core developers.
>>>> 
>>>> When there was first talk among about switching I solicited feedback
>>>> from the Fluid project which recently moved from SVN to Git. I highly
>>>> recommend reading the resulting thread which highlights a lot of the
>>>> pros and cons http://old.nabble.com/Perspectives-on-Git-td31852449.html
>>>> 
>>>> There is an eclipse Git Plugin, a TortiseGit client which is a clone of
>>>> TortiseSVN and I believe most other IDEs have either built in or plugin
>>>> support for git.
>>>> 
>>>> Some other useful links:
>>>> Git for those without Version Control background -
>>>> http://hoth.entp.com/output/git_for_designers.html
>>>> GitHub's wonderful help documentation - http://help.github.com/
>>>> TortiseGit - http://code.google.com/p/tortoisegit/
>>>> 
>>>> Some questions that I can try and answer before they come up:
>>>> - The uPortal code in svn at source.jasig.org would likely be left in
>>>> place, we would just make the entire /uPortal directory read-only
>>>> - We're going to filter out the documentation and website files that
>>>> were included in early versions of uPortal 2 to reduce the project
>>>> repository size.
>>>> 
>>>> Since this is a big change (and since I'm going on vacation for 2 weeks
>>>> starting Friday) I'm planning on leaving this vote open for a while. +1,
>>>> 0, -1 to vote and if you vote -1 you need to include a detailed
>>>> reasoning for your -1 vote.
>>>> 
>>>> -Eric
>>> 
>> 
> 
> -- 
> You are currently subscribed to [email protected] as: 
> [email protected]
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/uportal-dev


-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/uportal-dev

Reply via email to