community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Feedback on Flex board report
Date Sat, 27 Apr 2013 16:39:48 GMT
Ross, agreed. A list of potential "gotchas" would be sensible!


On 27 April 2013 17:26, Ross Gardler <rgardler@opendirective.com> wrote:

> Let me repeat again that the value I see in the Flex report is that it
> identifies some issues that projects moving to git should consider and plan
> for. This will make other projects migrations smoother.
>
> Sent from a mobile device, please excuse mistakes and brevity
> On 26 Apr 2013 18:35, "Luciano Resende" <luckbr1975@gmail.com> wrote:
>
>>
>> On Fri, Apr 26, 2013 at 2:17 AM, Ross Gardler <rgardler@opendirective.com
>> > wrote:
>>
>>> I just wanted to thank you for the feedback you provided in your last
>>> board report with respect to your experiences with moving to Git. This
>>> kind of information is really useful to those in other projects. For
>>> the benefit of the archives (and ComDev PMC) I've copied the relevant
>>> section at the end of this mail.
>>>
>>> I'd really like to see this documented in the ComDev project. Perhaps
>>> in the section "For Commtters/PMCs". This could form the start of a
>>> page on best practices for version control which would link out to
>>> appropriate documentation on Git and SVN workflows, review processes
>>> etc.
>>>
>>> If anyone in the Flex community can write up your experiences as
>>> documentation on that site (it is editable by all committers) we'd
>>> really appreciate it.Note, the ComDev site is intended to "signpost"
>>> into more detailed documentation. The idea is not to be fully detailed
>>> but to provide a high level overview linking out to the details. To
>>> this end the content in the board report is at about the right level
>>> for the ComDev site, it just needs a little context padding for the
>>> ComDev site. If you have process documents on your own project pages
>>> please feel free to link to them as appropriate.
>>>
>>> If someone does find the time - thank you in advance. If not, then
>>> thank you for including it in the board report. Hopefully I or another
>>> ComDev memver will find the time to move it into the ComDev site.
>>>
>>> Ross
>>>
>>> Relevant section from board report:
>>>
>>> We moved our code base from SVN to Git in mid-March.  It has been a much
>>> more difficult transition than expected.  Three weeks later, folks are
>>> still
>>> confused about how to use Git as it has many options for performing tasks
>>> that can have significant implications.  Git's database model is not
>>> suited
>>> for partial checkouts like SVN, making the management of our
>>> "whiteboard" (a
>>> playground for committers) much more difficult as you have to download
>>> the
>>> entire whiteboard (currently 245MB) first.  There is discussion of
>>> managing
>>> the whiteboard on GitHub, but others feel that it doesn't conform to the
>>> Apache way.
>>>
>>> The move to Git has slowed contributions from some committers as folks
>>> aren't sure they have the time to learn to use Git and are afraid of
>>> using
>>> the wrong options.  Hopefully, the net benefit promised by the Git
>>> supporters will eventually be realized.
>>>
>>> The move to Git has also broken our release and build scripts and we are
>>> in
>>> the process of fixing them.  We also need to get the Git mirrors working
>>> again, as well as our CI implementation.
>>>
>>>
>>>
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
>>>
>>
>>
>> -1 for using Apache Flex's bad experience, as a concrete example, as this
>> might give the wrong perception about Git at Apache.
>>
>> +1 for documenting most used git and svn workflows used in Apache
>> Projects, this might avoid similar problems in the future.
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>>
>


-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message