i''ve understood the principle to have 2 versioning system but now i would like to help the project growing (and have a full-working version to use) so follow me... http://github.com/mapstraction/mxn is this the right git repos i have to use to send you the changes i could make?? if no... can you point me to the right repos? if yes... this repos lacks of a lot of changes in svn! is there a way to have a git copy that has all the new features in the svn one?? i could also make a fork and put all the files from the svn that are newer and then commit... but it seems to me a so ugly solution!! -- ----------- Tafuni Vito vito at vitotafuni.com --------------------------------------------- "Verba volant, scripta manent... data corrupted" -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/987ee95f/attachment.htm>
I feel that having multiple repositories is a huge PITA and very confusing. Development vs stable code bases is what branches are for a within repository, E.g., we''d have a stable branch for every major version, tags for each release, with active development taking place in either trunk or a major version dev branch. If we''re going to use Google Code, lets dive in and use it, actively using the wiki, issue queue, mailing list, granting other developers rights, etc. Otherwise, lets switch to Git and GitHub. The advantages of the latter are the ability for developers w/o commit access to fork the project, still make incremental commits, and then submit more complete changes back to the master repo, which can be accepted in whole or in part. I think Git is better for a project like this, but understand there may be momentum with Google Code. My 2 cents. On May 25, 2010, at 10:53 AM, Vito Tafuni wrote:> i''ve understood the principle to have 2 versioning system > but now i would like to help the project growing (and have a full-working version to use)Lev Tsypin _____________________ Level Online Strategy, LLC 503.342.8044 levelos.com | twitter.com/levelos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/3408765e/attachment.htm>
agree 100%. pick one and let''s go with it. two solutions means chaos. 2010/5/25 Lev Tsypin <lev at levelos.com>> I feel that having multiple repositories is a huge PITA and very confusing. > Development vs stable code bases is what branches are for a within > repository, E.g., we''d have a stable branch for every major version, tags > for each release, with active development taking place in either trunk or a > major version dev branch. If we''re going to use Google Code, lets dive in > and use it, actively using the wiki, issue queue, mailing list, granting > other developers rights, etc. Otherwise, lets switch to Git and GitHub. The > advantages of the latter are the ability for developers w/o commit access to > fork the project, still make incremental commits, and then submit more > complete changes back to the master repo, which can be accepted in whole or > in part. I think Git is better for a project like this, but understand there > may be momentum with Google Code. My 2 cents. > > On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: > > i''ve understood the principle to have 2 versioning system > but now i would like to help the project growing (and have a full-working > version to use) > > > Lev Tsypin > _____________________ > Level Online Strategy, LLC > 503.342.8044 > levelos.com | twitter.com/levelos > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/7b1dc16d/attachment.htm>
I agree too.
It''s necessary choose one and give complete docummentation.
Everybody should be able to collaborate without these misunderstandings.
--
Saludos,
Pablo L?pez Escob?s
2010/5/25 Ed Freyfogle <edf at sloan.mit.edu>
> agree 100%. pick one and let''s go with it. two solutions means
chaos.
>
>
> 2010/5/25 Lev Tsypin <lev at levelos.com>
>
>> I feel that having multiple repositories is a huge PITA and very
>> confusing. Development vs stable code bases is what branches are for a
>> within repository, E.g., we''d have a stable branch for every
major version,
>> tags for each release, with active development taking place in either
trunk
>> or a major version dev branch. If we''re going to use Google
Code, lets dive
>> in and use it, actively using the wiki, issue queue, mailing list,
granting
>> other developers rights, etc. Otherwise, lets switch to Git and GitHub.
The
>> advantages of the latter are the ability for developers w/o commit
access to
>> fork the project, still make incremental commits, and then submit more
>> complete changes back to the master repo, which can be accepted in
whole or
>> in part. I think Git is better for a project like this, but understand
there
>> may be momentum with Google Code. My 2 cents.
>>
>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote:
>>
>> i''ve understood the principle to have 2 versioning system
>> but now i would like to help the project growing (and have a
full-working
>> version to use)
>>
>>
>> Lev Tsypin
>> _____________________
>> Level Online Strategy, LLC
>> 503.342.8044
>> levelos.com | twitter.com/levelos
>>
>>
>> _______________________________________________
>> Mapstraction mailing list
>> Mapstraction at lists.mapstraction.com
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>
>>
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/f39f1945/attachment-0001.htm>
agree 200% but at the moment the problem is: i want to contribute but i don''t want to work on an old version!!! so... ok for 2 versioning... but i think that "last version on svn" <= "last version on git" and not viceversa because (let me pass this comparison with debian) i think git is the unstable version (or experimental) and svn the testing one ready to use for who doesn''t want to bother with problems. so i refer back the question: can i have an update git version or i have to manually merge my fork with the last svn?? -- ----------- Tafuni Vito vito at vitotafuni.com --------------------------------------------- "Verba volant, scripta manent... data corrupted" 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com>> I agree too. > > It''s necessary choose one and give complete docummentation. > > Everybody should be able to collaborate without these misunderstandings. > > -- > Saludos, > Pablo L?pez Escob?s > > > 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> > > agree 100%. pick one and let''s go with it. two solutions means chaos. >> >> >> 2010/5/25 Lev Tsypin <lev at levelos.com> >> >>> I feel that having multiple repositories is a huge PITA and very >>> confusing. Development vs stable code bases is what branches are for a >>> within repository, E.g., we''d have a stable branch for every major version, >>> tags for each release, with active development taking place in either trunk >>> or a major version dev branch. If we''re going to use Google Code, lets dive >>> in and use it, actively using the wiki, issue queue, mailing list, granting >>> other developers rights, etc. Otherwise, lets switch to Git and GitHub. The >>> advantages of the latter are the ability for developers w/o commit access to >>> fork the project, still make incremental commits, and then submit more >>> complete changes back to the master repo, which can be accepted in whole or >>> in part. I think Git is better for a project like this, but understand there >>> may be momentum with Google Code. My 2 cents. >>> >>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >>> >>> i''ve understood the principle to have 2 versioning system >>> but now i would like to help the project growing (and have a full-working >>> version to use) >>> >>> >>> Lev Tsypin >>> _____________________ >>> Level Online Strategy, LLC >>> 503.342.8044 >>> levelos.com | twitter.com/levelos >>> >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/3b9c95c1/attachment.htm>
I hope i''ve made it the right way... i created a fork on github, changed the svn more recent files and than commited with some changes i''ve talked about today (microsoft & googlev3) i''ve made a pull request too -- ----------- Tafuni Vito vito at vitotafuni.com --------------------------------------------- "Verba volant, scripta manent... data corrupted" 2010/5/25 Vito Tafuni <vito at vitotafuni.com>> agree 200% > > but at the moment the problem is: > i want to contribute but i don''t want to work on an old version!!! > > so... ok for 2 versioning... but i think that "last version on svn" <> "last version on git" and not viceversa > > because (let me pass this comparison with debian) i think git is the > unstable version (or experimental) and svn the testing one ready to use for > who doesn''t want to bother with problems. > > > so i refer back the question: can i have an update git version or i have to > manually merge my fork with the last svn?? > > > > -- > ----------- > Tafuni Vito > vito at vitotafuni.com > --------------------------------------------- > "Verba volant, scripta manent... data corrupted" > > > 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> > > I agree too. >> >> It''s necessary choose one and give complete docummentation. >> >> Everybody should be able to collaborate without these misunderstandings. >> >> -- >> Saludos, >> Pablo L?pez Escob?s >> >> >> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> >> >> agree 100%. pick one and let''s go with it. two solutions means chaos. >>> >>> >>> 2010/5/25 Lev Tsypin <lev at levelos.com> >>> >>>> I feel that having multiple repositories is a huge PITA and very >>>> confusing. Development vs stable code bases is what branches are for a >>>> within repository, E.g., we''d have a stable branch for every major version, >>>> tags for each release, with active development taking place in either trunk >>>> or a major version dev branch. If we''re going to use Google Code, lets dive >>>> in and use it, actively using the wiki, issue queue, mailing list, granting >>>> other developers rights, etc. Otherwise, lets switch to Git and GitHub. The >>>> advantages of the latter are the ability for developers w/o commit access to >>>> fork the project, still make incremental commits, and then submit more >>>> complete changes back to the master repo, which can be accepted in whole or >>>> in part. I think Git is better for a project like this, but understand there >>>> may be momentum with Google Code. My 2 cents. >>>> >>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >>>> >>>> i''ve understood the principle to have 2 versioning system >>>> but now i would like to help the project growing (and have a >>>> full-working version to use) >>>> >>>> >>>> Lev Tsypin >>>> _____________________ >>>> Level Online Strategy, LLC >>>> 503.342.8044 >>>> levelos.com | twitter.com/levelos >>>> >>>> >>>> _______________________________________________ >>>> Mapstraction mailing list >>>> Mapstraction at lists.mapstraction.com >>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>>> >>>> >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100525/696b0242/attachment.htm>
Ok - sorry again for the confusion here. The Github repository was never meant to try and be a parallel repository but since we were using Git internally and for several collaborative projects, I put a copy up. I added notes in a README as a very first pass: http://github.com/mapstraction/mxn And I also updated the description at the top. I''d like to discuss using Git as the repository - but only after discussion/consensus. But lets separate that from this. If people would prefer, I can "hide" the MXN project on Github if the README and description aren''t sufficient. I''m curious to hear how people found it (for example, are people browsing Github more often now?) Andrew On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> wrote:> I hope i''ve made it the right way... > > i created a fork on github, changed the svn more recent files > and than commited with some changes i''ve talked about today (microsoft & > googlev3) > > i''ve made a pull request too > > > > > -- > ----------- > Tafuni Vito > vito at vitotafuni.com > --------------------------------------------- > "Verba volant, scripta manent... data corrupted" > > > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> >> >> agree 200% >> >> but at the moment the problem is: >> i want to contribute but i don''t want to work on an old version!!! >> >> so... ok for 2 versioning... but i think that "last version on svn" <>> "last version on git" and not viceversa >> >> because (let me pass this comparison with debian) i think git is the >> unstable version (or experimental) and svn the testing one ready to use for >> who doesn''t want to bother with problems. >> >> >> so i refer back the question: can i have an update git version or i have >> to manually merge my fork with the last svn?? >> >> >> -- >> ----------- >> Tafuni Vito >> vito at vitotafuni.com >> --------------------------------------------- >> "Verba volant, scripta manent... data corrupted" >> >> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> >>> >>> I agree too. >>> >>> It''s necessary choose one and give complete docummentation. >>> >>> Everybody should be able to collaborate without these misunderstandings. >>> >>> -- >>> Saludos, >>> ??????? Pablo L?pez Escob?s >>> >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> >>>> >>>> agree 100%. pick one and let''s go with it. two solutions means chaos. >>>> >>>> >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> >>>>> >>>>> I feel that having multiple repositories is a huge PITA and very >>>>> confusing. Development vs stable code bases is what branches are for a >>>>> within repository, E.g., we''d have a stable branch for every major version, >>>>> tags for each release, with active development taking place in either trunk >>>>> or a major version dev branch. If we''re going to use Google Code, lets dive >>>>> in and use it, actively using the wiki, issue queue, mailing list, granting >>>>> other developers rights, etc. Otherwise, lets switch to Git and GitHub. The >>>>> advantages of the latter are the ability for developers w/o commit access to >>>>> fork the project, still make incremental commits, and then submit more >>>>> complete changes back to the master repo, which can be accepted in whole or >>>>> in part. I think Git is better for a project like this, but understand there >>>>> may be momentum with Google Code. My 2 cents. >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >>>>> >>>>> i''ve understood the principle to have 2 versioning system >>>>> but now i would like to help the project growing (and have a >>>>> full-working version to use) >>>>> >>>>> Lev Tsypin >>>>> _____________________ >>>>> Level Online Strategy, LLC >>>>> 503.342.8044 >>>>> levelos.com | twitter.com/levelos >>>>> >>>>> _______________________________________________ >>>>> Mapstraction mailing list >>>>> Mapstraction at lists.mapstraction.com >>>>> >>>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Mapstraction mailing list >>>> Mapstraction at lists.mapstraction.com >>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>>> >>> >>> >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-- Andrew Turner mobile: 248.982.3609 andrew at fortiusone.com http://highearthorbit.com http://geocommons.com Helping build the Geospatial Web Introduction to Neogeography - http://oreilly.com/catalog/neogeography
I found the Mapstraction v2 library at Git through your blog ( http://highearthorbit.com/mapstraction-updates/), where we I read: "In order to start promoting the new API and encouraging developers to come> and help out, we put the source code and tickets<http://code.google.com/p/mapstraction/issues/>into a Google > Code project <http://code.google.com/p/mapstraction/>. Although, being > Subversion, you still have to submit patches to get changes accepted for > now. So I personally suggest working from the Github version<http://github.com/mapstraction/mxn>, > which will be kept up to speed with git-svn, and then you can submit patches > from here to push into the ?official? subversion repository." >The main drawback of the SVN repository is that few people can access it. I think that work with Git is more appropriate, but maintainers should up to date the master fork from all the pull requests. If we continue as at present, there will be patches in the Git repository for months, but not added to the main repository. I.E. : The microsoft provider click event patch -- Saludos, Pablo L?pez Escob?s 2010/5/26 Andrew Turner <andrew at highearthorbit.com>> Ok - sorry again for the confusion here. The Github repository was > never meant to try and be a parallel repository but since we were > using Git internally and for several collaborative projects, I put a > copy up. > > I added notes in a README as a very first pass: > http://github.com/mapstraction/mxn > > And I also updated the description at the top. > > I''d like to discuss using Git as the repository - but only after > discussion/consensus. But lets separate that from this. > > If people would prefer, I can "hide" the MXN project on Github if the > README and description aren''t sufficient. I''m curious to hear how > people found it (for example, are people browsing Github more often > now?) > > Andrew > > On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> wrote: > > I hope i''ve made it the right way... > > > > i created a fork on github, changed the svn more recent files > > and than commited with some changes i''ve talked about today (microsoft & > > googlev3) > > > > i''ve made a pull request too > > > > > > > > > > -- > > ----------- > > Tafuni Vito > > vito at vitotafuni.com > > --------------------------------------------- > > "Verba volant, scripta manent... data corrupted" > > > > > > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> > >> > >> agree 200% > >> > >> but at the moment the problem is: > >> i want to contribute but i don''t want to work on an old version!!! > >> > >> so... ok for 2 versioning... but i think that "last version on svn" <> >> "last version on git" and not viceversa > >> > >> because (let me pass this comparison with debian) i think git is the > >> unstable version (or experimental) and svn the testing one ready to use > for > >> who doesn''t want to bother with problems. > >> > >> > >> so i refer back the question: can i have an update git version or i have > >> to manually merge my fork with the last svn?? > >> > >> > >> -- > >> ----------- > >> Tafuni Vito > >> vito at vitotafuni.com > >> --------------------------------------------- > >> "Verba volant, scripta manent... data corrupted" > >> > >> > >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> > >>> > >>> I agree too. > >>> > >>> It''s necessary choose one and give complete docummentation. > >>> > >>> Everybody should be able to collaborate without these > misunderstandings. > >>> > >>> -- > >>> Saludos, > >>> Pablo L?pez Escob?s > >>> > >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> > >>>> > >>>> agree 100%. pick one and let''s go with it. two solutions means chaos. > >>>> > >>>> > >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> > >>>>> > >>>>> I feel that having multiple repositories is a huge PITA and very > >>>>> confusing. Development vs stable code bases is what branches are for > a > >>>>> within repository, E.g., we''d have a stable branch for every major > version, > >>>>> tags for each release, with active development taking place in either > trunk > >>>>> or a major version dev branch. If we''re going to use Google Code, > lets dive > >>>>> in and use it, actively using the wiki, issue queue, mailing list, > granting > >>>>> other developers rights, etc. Otherwise, lets switch to Git and > GitHub. The > >>>>> advantages of the latter are the ability for developers w/o commit > access to > >>>>> fork the project, still make incremental commits, and then submit > more > >>>>> complete changes back to the master repo, which can be accepted in > whole or > >>>>> in part. I think Git is better for a project like this, but > understand there > >>>>> may be momentum with Google Code. My 2 cents. > >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: > >>>>> > >>>>> i''ve understood the principle to have 2 versioning system > >>>>> but now i would like to help the project growing (and have a > >>>>> full-working version to use) > >>>>> > >>>>> Lev Tsypin > >>>>> _____________________ > >>>>> Level Online Strategy, LLC > >>>>> 503.342.8044 > >>>>> levelos.com | twitter.com/levelos > >>>>> > >>>>> _______________________________________________ > >>>>> Mapstraction mailing list > >>>>> Mapstraction at lists.mapstraction.com > >>>>> > >>>>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mapstraction mailing list > >>>> Mapstraction at lists.mapstraction.com > >>>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Mapstraction mailing list > >>> Mapstraction at lists.mapstraction.com > >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> > >> > > > > > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > > > > > -- > Andrew Turner > mobile: 248.982.3609 > andrew at fortiusone.com > http://highearthorbit.com > > http://geocommons.com Helping build the Geospatial Web > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100526/2db3e144/attachment.htm>
I agree with both Andrew and Pablo: 1. we have to use one versioning system 2. critical changes made on that system need to be available for new developers (and users) asap last time i used a versioning system it was cvs so choosing between svn or git is not the problem for me... even if git seems to be more appropriate for collaborative development @Andrew: ok let''s use svn! but... how can i be a committer on google code repos?? i need the changes i''ve made because i''m working on a project (i think a lot of people would like the click event to fire correctly!) but i would like to update my local repository with new code developed by others too (and not to be alone on my fork, losting a lot of interesting new features!!) sorry for my english... i hope you understand my point of view -Vito- -- ----------- Tafuni Vito vito at vitotafuni.com --------------------------------------------- "Verba volant, scripta manent... data corrupted" 2010/5/26 Pablo L?pez Escob?s <plopesc at gmail.com>> I found the Mapstraction v2 library at Git through your blog ( > http://highearthorbit.com/mapstraction-updates/), where we I read: > > "In order to start promoting the new API and encouraging developers to come >> and help out, we put the source code and tickets<http://code.google.com/p/mapstraction/issues/>into a Google >> Code project <http://code.google.com/p/mapstraction/>. Although, being >> Subversion, you still have to submit patches to get changes accepted for >> now. So I personally suggest working from the Github version<http://github.com/mapstraction/mxn>, >> which will be kept up to speed with git-svn, and then you can submit patches >> from here to push into the ?official? subversion repository." >> > > The main drawback of the SVN repository is that few people can access it. I > think that work with Git is more appropriate, but maintainers should up to > date the master fork from all the pull requests. > > If we continue as at present, there will be patches in the Git repository > for months, but not added to the main repository. I.E. : The microsoft > provider click event patch > > -- > Saludos, > Pablo L?pez Escob?s > > > 2010/5/26 Andrew Turner <andrew at highearthorbit.com> > > Ok - sorry again for the confusion here. The Github repository was >> never meant to try and be a parallel repository but since we were >> using Git internally and for several collaborative projects, I put a >> copy up. >> >> I added notes in a README as a very first pass: >> http://github.com/mapstraction/mxn >> >> And I also updated the description at the top. >> >> I''d like to discuss using Git as the repository - but only after >> discussion/consensus. But lets separate that from this. >> >> If people would prefer, I can "hide" the MXN project on Github if the >> README and description aren''t sufficient. I''m curious to hear how >> people found it (for example, are people browsing Github more often >> now?) >> >> Andrew >> >> On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> wrote: >> > I hope i''ve made it the right way... >> > >> > i created a fork on github, changed the svn more recent files >> > and than commited with some changes i''ve talked about today (microsoft & >> > googlev3) >> > >> > i''ve made a pull request too >> > >> > >> > >> > >> > -- >> > ----------- >> > Tafuni Vito >> > vito at vitotafuni.com >> > --------------------------------------------- >> > "Verba volant, scripta manent... data corrupted" >> > >> > >> > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> >> >> >> >> agree 200% >> >> >> >> but at the moment the problem is: >> >> i want to contribute but i don''t want to work on an old version!!! >> >> >> >> so... ok for 2 versioning... but i think that "last version on svn" <>> >> "last version on git" and not viceversa >> >> >> >> because (let me pass this comparison with debian) i think git is the >> >> unstable version (or experimental) and svn the testing one ready to use >> for >> >> who doesn''t want to bother with problems. >> >> >> >> >> >> so i refer back the question: can i have an update git version or i >> have >> >> to manually merge my fork with the last svn?? >> >> >> >> >> >> -- >> >> ----------- >> >> Tafuni Vito >> >> vito at vitotafuni.com >> >> --------------------------------------------- >> >> "Verba volant, scripta manent... data corrupted" >> >> >> >> >> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> >> >>> >> >>> I agree too. >> >>> >> >>> It''s necessary choose one and give complete docummentation. >> >>> >> >>> Everybody should be able to collaborate without these >> misunderstandings. >> >>> >> >>> -- >> >>> Saludos, >> >>> Pablo L?pez Escob?s >> >>> >> >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> >> >>>> >> >>>> agree 100%. pick one and let''s go with it. two solutions means chaos. >> >>>> >> >>>> >> >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> >> >>>>> >> >>>>> I feel that having multiple repositories is a huge PITA and very >> >>>>> confusing. Development vs stable code bases is what branches are for >> a >> >>>>> within repository, E.g., we''d have a stable branch for every major >> version, >> >>>>> tags for each release, with active development taking place in >> either trunk >> >>>>> or a major version dev branch. If we''re going to use Google Code, >> lets dive >> >>>>> in and use it, actively using the wiki, issue queue, mailing list, >> granting >> >>>>> other developers rights, etc. Otherwise, lets switch to Git and >> GitHub. The >> >>>>> advantages of the latter are the ability for developers w/o commit >> access to >> >>>>> fork the project, still make incremental commits, and then submit >> more >> >>>>> complete changes back to the master repo, which can be accepted in >> whole or >> >>>>> in part. I think Git is better for a project like this, but >> understand there >> >>>>> may be momentum with Google Code. My 2 cents. >> >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >> >>>>> >> >>>>> i''ve understood the principle to have 2 versioning system >> >>>>> but now i would like to help the project growing (and have a >> >>>>> full-working version to use) >> >>>>> >> >>>>> Lev Tsypin >> >>>>> _____________________ >> >>>>> Level Online Strategy, LLC >> >>>>> 503.342.8044 >> >>>>> levelos.com | twitter.com/levelos >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Mapstraction mailing list >> >>>>> Mapstraction at lists.mapstraction.com >> >>>>> >> >>>>> >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Mapstraction mailing list >> >>>> Mapstraction at lists.mapstraction.com >> >>>> >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Mapstraction mailing list >> >>> Mapstraction at lists.mapstraction.com >> >>> >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >>> >> >> >> > >> > >> > _______________________________________________ >> > Mapstraction mailing list >> > Mapstraction at lists.mapstraction.com >> > >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > >> > >> >> >> >> -- >> Andrew Turner >> mobile: 248.982.3609 >> andrew at fortiusone.com >> http://highearthorbit.com >> >> http://geocommons.com Helping build the Geospatial Web >> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100526/e2ef6d98/attachment-0001.htm>
So this is the crux of the problem for me - there are many contributors and will be many more! However SVN is overly restricting & hierarchical. Do we give anyone SVN access? Only after you''ve submitted so many patches? that requires a developer to manually bring patches into SVN all the time until people are trusted enough to push into the official SVN. Should we give anyone access to SVN that asks but only link to tagged releases and make it very clear that the SVN is very volatile? My preference would be to use Github, give a few of the core devs commit access to the Mapstraction user and let new contributes make their forks and pull requests that can be vetted and merged into the Mapstraction user with tests and verification. But I also have not had the bandwidth lately to support the project and fortunately there have been awesome developers such as Derek, Ed, Rob and many more that have. So while I prefer Git - it really resides on them currently to authorize who should get SVN access and pull in patches if that''s the path we continue to stay on. Let me know and I will take down the Github version. Andrew On Wed, May 26, 2010 at 3:55 AM, Vito Tafuni <vito at vitotafuni.com> wrote:> I agree with both Andrew and Pablo: > 1. we have to use one versioning system > 2. critical changes made on that system need to be available for new > developers (and users) asap > > last time i used a versioning system it was cvs so choosing between svn or > git is not the problem for me... even if git seems to be more appropriate > for collaborative development > > @Andrew: ok let''s use svn! but... how can i be a committer on google code > repos?? i need the changes i''ve made because i''m working on a project (i > think a lot of people would like the click event to fire correctly!) but i > would like to update my local repository with new code developed by others > too (and not to be alone on my fork, losting a lot of interesting new > features!!) > > > sorry for my english... i hope you understand my point of view > > -Vito- > > > -- > ----------- > Tafuni Vito > vito at vitotafuni.com > --------------------------------------------- > "Verba volant, scripta manent... data corrupted" > > > 2010/5/26 Pablo L?pez Escob?s <plopesc at gmail.com> >> >> I found the Mapstraction v2 library at Git through your blog >> (http://highearthorbit.com/mapstraction-updates/), where we I read: >> >>> "In order to start promoting the new API and encouraging developers to >>> come and help out, we put the source code and tickets into a Google Code >>> project. Although, being Subversion, you still have to submit patches to get >>> changes accepted for now. So I personally suggest working from the Github >>> version, which will be kept up to speed with git-svn, and then you can >>> submit patches from here to push into the ?official? subversion repository." >> >> The main drawback of the SVN repository is that few people can access it. >> I think that work with Git is more appropriate, but maintainers should up to >> date the master fork from all the pull requests. >> >> If we continue as at present, there will be patches in the Git repository >> for months, but not added to the main repository. I.E. : The microsoft >> provider click event patch >> -- >> Saludos, >> ??????? Pablo L?pez Escob?s >> >> 2010/5/26 Andrew Turner <andrew at highearthorbit.com> >>> >>> Ok - sorry again for the confusion here. The Github repository was >>> never meant to try and be a parallel repository but since we were >>> using Git internally and for several collaborative projects, I put a >>> copy up. >>> >>> I added notes in a README as a very first pass: >>> http://github.com/mapstraction/mxn >>> >>> And I also updated the description at the top. >>> >>> I''d like to discuss using Git as the repository - but only after >>> discussion/consensus. But lets separate that from this. >>> >>> If people would prefer, I can "hide" the MXN project on Github if the >>> README and description aren''t sufficient. I''m curious to hear how >>> people found it (for example, are people browsing Github more often >>> now?) >>> >>> Andrew >>> >>> On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> wrote: >>> > I hope i''ve made it the right way... >>> > >>> > i created a fork on github, changed the svn more recent files >>> > and than commited with some changes i''ve talked about today (microsoft >>> > & >>> > googlev3) >>> > >>> > i''ve made a pull request too >>> > >>> > >>> > >>> > >>> > -- >>> > ----------- >>> > Tafuni Vito >>> > vito at vitotafuni.com >>> > --------------------------------------------- >>> > "Verba volant, scripta manent... data corrupted" >>> > >>> > >>> > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> >>> >> >>> >> agree 200% >>> >> >>> >> but at the moment the problem is: >>> >> i want to contribute but i don''t want to work on an old version!!! >>> >> >>> >> so... ok for 2 versioning... but i think that "last version on svn" <>>> >> "last version on git" and not viceversa >>> >> >>> >> because (let me pass this comparison with debian) i think git is the >>> >> unstable version (or experimental) and svn the testing one ready to >>> >> use for >>> >> who doesn''t want to bother with problems. >>> >> >>> >> >>> >> so i refer back the question: can i have an update git version or i >>> >> have >>> >> to manually merge my fork with the last svn?? >>> >> >>> >> >>> >> -- >>> >> ----------- >>> >> Tafuni Vito >>> >> vito at vitotafuni.com >>> >> --------------------------------------------- >>> >> "Verba volant, scripta manent... data corrupted" >>> >> >>> >> >>> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> >>> >>> >>> >>> I agree too. >>> >>> >>> >>> It''s necessary choose one and give complete docummentation. >>> >>> >>> >>> Everybody should be able to collaborate without these >>> >>> misunderstandings. >>> >>> >>> >>> -- >>> >>> Saludos, >>> >>> ??????? Pablo L?pez Escob?s >>> >>> >>> >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> >>> >>>> >>> >>>> agree 100%. pick one and let''s go with it. two solutions means >>> >>>> chaos. >>> >>>> >>> >>>> >>> >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> >>> >>>>> >>> >>>>> I feel that having multiple repositories is a huge PITA and very >>> >>>>> confusing. Development vs stable code bases is what branches are >>> >>>>> for a >>> >>>>> within repository, E.g., we''d have a stable branch for every major >>> >>>>> version, >>> >>>>> tags for each release, with active development taking place in >>> >>>>> either trunk >>> >>>>> or a major version dev branch. If we''re going to use Google Code, >>> >>>>> lets dive >>> >>>>> in and use it, actively using the wiki, issue queue, mailing list, >>> >>>>> granting >>> >>>>> other developers rights, etc. Otherwise, lets switch to Git and >>> >>>>> GitHub. The >>> >>>>> advantages of the latter are the ability for developers w/o commit >>> >>>>> access to >>> >>>>> fork the project, still make incremental commits, and then submit >>> >>>>> more >>> >>>>> complete changes back to the master repo, which can be accepted in >>> >>>>> whole or >>> >>>>> in part. I think Git is better for a project like this, but >>> >>>>> understand there >>> >>>>> may be momentum with Google Code. My 2 cents. >>> >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >>> >>>>> >>> >>>>> i''ve understood the principle to have 2 versioning system >>> >>>>> but now i would like to help the project growing (and have a >>> >>>>> full-working version to use) >>> >>>>> >>> >>>>> Lev Tsypin >>> >>>>> _____________________ >>> >>>>> Level Online Strategy, LLC >>> >>>>> 503.342.8044 >>> >>>>> levelos.com | twitter.com/levelos >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Mapstraction mailing list >>> >>>>> Mapstraction at lists.mapstraction.com >>> >>>>> >>> >>>>> >>> >>>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> Mapstraction mailing list >>> >>>> Mapstraction at lists.mapstraction.com >>> >>>> >>> >>>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Mapstraction mailing list >>> >>> Mapstraction at lists.mapstraction.com >>> >>> >>> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Mapstraction mailing list >>> > Mapstraction at lists.mapstraction.com >>> > >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> > >>> > >>> >>> >>> >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>> andrew at fortiusone.com >>> http://highearthorbit.com >>> >>> http://geocommons.com ? ? ? ? ? Helping build the Geospatial Web >>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> > > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-- Andrew Turner mobile: 248.982.3609 andrew at fortiusone.com http://highearthorbit.com http://geocommons.com Helping build the Geospatial Web Introduction to Neogeography - http://oreilly.com/catalog/neogeography
I''m happy to move to Github. I''m also happy to migrate all the existing issues across to the Github repository and to either delete the Google Code one or put big messages in there saying it''s moved. Andrew, is the Github version synced up with SVN now? If so I''ll see about locking Google Code to stop further commits. I''ll also migrate all the items across from issue tracking however my net connection at home has been down for three days now so I may not be able to work on it until next week. Github seems much better from a people taking forks and submitting patches back without needing permissions on the master repository - I''m sorry I didn''t just trust your judgement when we set it up now. Derek On 28 May 2010 03:41, Andrew Turner <andrew at highearthorbit.com> wrote:> So this is the crux of the problem for me - there are many > contributors and will be many more! > > However SVN is overly restricting & hierarchical. Do we give anyone > SVN access? Only after you''ve submitted so many patches? that requires > a developer to manually bring patches into SVN all the time until > people are trusted enough to push into the official SVN. Should we > give anyone access to SVN that asks but only link to tagged releases > and make it very clear that the SVN is very volatile? > > My preference would be to use Github, give a few of the core devs > commit access to the Mapstraction user and let new contributes make > their forks and pull requests that can be vetted and merged into the > Mapstraction user with tests and verification. > > But I also have not had the bandwidth lately to support the project > and fortunately there have been awesome developers such as Derek, Ed, > Rob and many more that have. So while I prefer Git - it really resides > on them currently to authorize who should get SVN access and pull in > patches if that''s the path we continue to stay on. > > Let me know and I will take down the Github version. > Andrew > > > On Wed, May 26, 2010 at 3:55 AM, Vito Tafuni <vito at vitotafuni.com> wrote: > > I agree with both Andrew and Pablo: > > 1. we have to use one versioning system > > 2. critical changes made on that system need to be available for new > > developers (and users) asap > > > > last time i used a versioning system it was cvs so choosing between svn > or > > git is not the problem for me... even if git seems to be more appropriate > > for collaborative development > > > > @Andrew: ok let''s use svn! but... how can i be a committer on google code > > repos?? i need the changes i''ve made because i''m working on a project (i > > think a lot of people would like the click event to fire correctly!) but > i > > would like to update my local repository with new code developed by > others > > too (and not to be alone on my fork, losting a lot of interesting new > > features!!) > > > > > > sorry for my english... i hope you understand my point of view > > > > -Vito- > > > > > > -- > > ----------- > > Tafuni Vito > > vito at vitotafuni.com > > --------------------------------------------- > > "Verba volant, scripta manent... data corrupted" > > > > > > 2010/5/26 Pablo L?pez Escob?s <plopesc at gmail.com> > >> > >> I found the Mapstraction v2 library at Git through your blog > >> (http://highearthorbit.com/mapstraction-updates/), where we I read: > >> > >>> "In order to start promoting the new API and encouraging developers to > >>> come and help out, we put the source code and tickets into a Google > Code > >>> project. Although, being Subversion, you still have to submit patches > to get > >>> changes accepted for now. So I personally suggest working from the > Github > >>> version, which will be kept up to speed with git-svn, and then you can > >>> submit patches from here to push into the ?official? subversion > repository." > >> > >> The main drawback of the SVN repository is that few people can access > it. > >> I think that work with Git is more appropriate, but maintainers should > up to > >> date the master fork from all the pull requests. > >> > >> If we continue as at present, there will be patches in the Git > repository > >> for months, but not added to the main repository. I.E. : The microsoft > >> provider click event patch > >> -- > >> Saludos, > >> Pablo L?pez Escob?s > >> > >> 2010/5/26 Andrew Turner <andrew at highearthorbit.com> > >>> > >>> Ok - sorry again for the confusion here. The Github repository was > >>> never meant to try and be a parallel repository but since we were > >>> using Git internally and for several collaborative projects, I put a > >>> copy up. > >>> > >>> I added notes in a README as a very first pass: > >>> http://github.com/mapstraction/mxn > >>> > >>> And I also updated the description at the top. > >>> > >>> I''d like to discuss using Git as the repository - but only after > >>> discussion/consensus. But lets separate that from this. > >>> > >>> If people would prefer, I can "hide" the MXN project on Github if the > >>> README and description aren''t sufficient. I''m curious to hear how > >>> people found it (for example, are people browsing Github more often > >>> now?) > >>> > >>> Andrew > >>> > >>> On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> > wrote: > >>> > I hope i''ve made it the right way... > >>> > > >>> > i created a fork on github, changed the svn more recent files > >>> > and than commited with some changes i''ve talked about today > (microsoft > >>> > & > >>> > googlev3) > >>> > > >>> > i''ve made a pull request too > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > ----------- > >>> > Tafuni Vito > >>> > vito at vitotafuni.com > >>> > --------------------------------------------- > >>> > "Verba volant, scripta manent... data corrupted" > >>> > > >>> > > >>> > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> > >>> >> > >>> >> agree 200% > >>> >> > >>> >> but at the moment the problem is: > >>> >> i want to contribute but i don''t want to work on an old version!!! > >>> >> > >>> >> so... ok for 2 versioning... but i think that "last version on svn" > <> >>> >> "last version on git" and not viceversa > >>> >> > >>> >> because (let me pass this comparison with debian) i think git is the > >>> >> unstable version (or experimental) and svn the testing one ready to > >>> >> use for > >>> >> who doesn''t want to bother with problems. > >>> >> > >>> >> > >>> >> so i refer back the question: can i have an update git version or i > >>> >> have > >>> >> to manually merge my fork with the last svn?? > >>> >> > >>> >> > >>> >> -- > >>> >> ----------- > >>> >> Tafuni Vito > >>> >> vito at vitotafuni.com > >>> >> --------------------------------------------- > >>> >> "Verba volant, scripta manent... data corrupted" > >>> >> > >>> >> > >>> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> > >>> >>> > >>> >>> I agree too. > >>> >>> > >>> >>> It''s necessary choose one and give complete docummentation. > >>> >>> > >>> >>> Everybody should be able to collaborate without these > >>> >>> misunderstandings. > >>> >>> > >>> >>> -- > >>> >>> Saludos, > >>> >>> Pablo L?pez Escob?s > >>> >>> > >>> >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> > >>> >>>> > >>> >>>> agree 100%. pick one and let''s go with it. two solutions means > >>> >>>> chaos. > >>> >>>> > >>> >>>> > >>> >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> > >>> >>>>> > >>> >>>>> I feel that having multiple repositories is a huge PITA and very > >>> >>>>> confusing. Development vs stable code bases is what branches are > >>> >>>>> for a > >>> >>>>> within repository, E.g., we''d have a stable branch for every > major > >>> >>>>> version, > >>> >>>>> tags for each release, with active development taking place in > >>> >>>>> either trunk > >>> >>>>> or a major version dev branch. If we''re going to use Google Code, > >>> >>>>> lets dive > >>> >>>>> in and use it, actively using the wiki, issue queue, mailing > list, > >>> >>>>> granting > >>> >>>>> other developers rights, etc. Otherwise, lets switch to Git and > >>> >>>>> GitHub. The > >>> >>>>> advantages of the latter are the ability for developers w/o > commit > >>> >>>>> access to > >>> >>>>> fork the project, still make incremental commits, and then submit > >>> >>>>> more > >>> >>>>> complete changes back to the master repo, which can be accepted > in > >>> >>>>> whole or > >>> >>>>> in part. I think Git is better for a project like this, but > >>> >>>>> understand there > >>> >>>>> may be momentum with Google Code. My 2 cents. > >>> >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: > >>> >>>>> > >>> >>>>> i''ve understood the principle to have 2 versioning system > >>> >>>>> but now i would like to help the project growing (and have a > >>> >>>>> full-working version to use) > >>> >>>>> > >>> >>>>> Lev Tsypin > >>> >>>>> _____________________ > >>> >>>>> Level Online Strategy, LLC > >>> >>>>> 503.342.8044 > >>> >>>>> levelos.com | twitter.com/levelos > >>> >>>>> > >>> >>>>> _______________________________________________ > >>> >>>>> Mapstraction mailing list > >>> >>>>> Mapstraction at lists.mapstraction.com > >>> >>>>> > >>> >>>>> > >>> >>>>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> >>>>> > >>> >>>> > >>> >>>> > >>> >>>> _______________________________________________ > >>> >>>> Mapstraction mailing list > >>> >>>> Mapstraction at lists.mapstraction.com > >>> >>>> > >>> >>>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> >>>> > >>> >>> > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Mapstraction mailing list > >>> >>> Mapstraction at lists.mapstraction.com > >>> >>> > >>> >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> >>> > >>> >> > >>> > > >>> > > >>> > _______________________________________________ > >>> > Mapstraction mailing list > >>> > Mapstraction at lists.mapstraction.com > >>> > > >>> > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Andrew Turner > >>> mobile: 248.982.3609 > >>> andrew at fortiusone.com > >>> http://highearthorbit.com > >>> > >>> http://geocommons.com Helping build the Geospatial Web > >>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography > >>> _______________________________________________ > >>> Mapstraction mailing list > >>> Mapstraction at lists.mapstraction.com > >>> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >> > >> > >> _______________________________________________ > >> Mapstraction mailing list > >> Mapstraction at lists.mapstraction.com > >> > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >> > > > > > > _______________________________________________ > > Mapstraction mailing list > > Mapstraction at lists.mapstraction.com > > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > > > > > > > > -- > Andrew Turner > mobile: 248.982.3609 > andrew at fortiusone.com > http://highearthorbit.com > > http://geocommons.com Helping build the Geospatial Web > Introduction to Neogeography - http://oreilly.com/catalog/neogeography > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100528/64cd5c48/attachment-0001.htm>
Hi!
I''m happy for your decission. Using Git, everybody can fork the master
branch and develop their own patches.
However, maintainers will have to work hard because there will be a big
number of pull requests and decide which are really beneficial for the
library.
If you wish, I volunteer to work with maintainers and help as possible.
--
Saludos,
Pablo L?pez Escob?s
2010/5/28 Derek Fowler <dezfowler at gmail.com>
> I''m happy to move to Github. I''m also happy to migrate
all the existing
> issues across to the Github repository and to either delete the Google Code
> one or put big messages in there saying it''s moved. Andrew, is the
Github
> version synced up with SVN now? If so I''ll see about locking
Google Code to
> stop further commits. I''ll also migrate all the items across from
issue
> tracking however my net connection at home has been down for three days now
> so I may not be able to work on it until next week.
>
> Github seems much better from a people taking forks and submitting patches
> back without needing permissions on the master repository - I''m
sorry I
> didn''t just trust your judgement when we set it up now.
>
> Derek
>
> On 28 May 2010 03:41, Andrew Turner <andrew at highearthorbit.com>
wrote:
>
>> So this is the crux of the problem for me - there are many
>> contributors and will be many more!
>>
>> However SVN is overly restricting & hierarchical. Do we give anyone
>> SVN access? Only after you''ve submitted so many patches? that
requires
>> a developer to manually bring patches into SVN all the time until
>> people are trusted enough to push into the official SVN. Should we
>> give anyone access to SVN that asks but only link to tagged releases
>> and make it very clear that the SVN is very volatile?
>>
>> My preference would be to use Github, give a few of the core devs
>> commit access to the Mapstraction user and let new contributes make
>> their forks and pull requests that can be vetted and merged into the
>> Mapstraction user with tests and verification.
>>
>> But I also have not had the bandwidth lately to support the project
>> and fortunately there have been awesome developers such as Derek, Ed,
>> Rob and many more that have. So while I prefer Git - it really resides
>> on them currently to authorize who should get SVN access and pull in
>> patches if that''s the path we continue to stay on.
>>
>> Let me know and I will take down the Github version.
>> Andrew
>>
>>
>> On Wed, May 26, 2010 at 3:55 AM, Vito Tafuni <vito at
vitotafuni.com> wrote:
>> > I agree with both Andrew and Pablo:
>> > 1. we have to use one versioning system
>> > 2. critical changes made on that system need to be available for
new
>> > developers (and users) asap
>> >
>> > last time i used a versioning system it was cvs so choosing
between svn
>> or
>> > git is not the problem for me... even if git seems to be more
>> appropriate
>> > for collaborative development
>> >
>> > @Andrew: ok let''s use svn! but... how can i be a
committer on google
>> code
>> > repos?? i need the changes i''ve made because i''m
working on a project (i
>> > think a lot of people would like the click event to fire
correctly!) but
>> i
>> > would like to update my local repository with new code developed
by
>> others
>> > too (and not to be alone on my fork, losting a lot of interesting
new
>> > features!!)
>> >
>> >
>> > sorry for my english... i hope you understand my point of view
>> >
>> > -Vito-
>> >
>> >
>> > --
>> > -----------
>> > Tafuni Vito
>> > vito at vitotafuni.com
>> > ---------------------------------------------
>> > "Verba volant, scripta manent... data corrupted"
>> >
>> >
>> > 2010/5/26 Pablo L?pez Escob?s <plopesc at gmail.com>
>> >>
>> >> I found the Mapstraction v2 library at Git through your blog
>> >> (http://highearthorbit.com/mapstraction-updates/), where we I
read:
>> >>
>> >>> "In order to start promoting the new API and
encouraging developers to
>> >>> come and help out, we put the source code and tickets into
a Google
>> Code
>> >>> project. Although, being Subversion, you still have to
submit patches
>> to get
>> >>> changes accepted for now. So I personally suggest working
from the
>> Github
>> >>> version, which will be kept up to speed with git-svn, and
then you can
>> >>> submit patches from here to push into the ?official?
subversion
>> repository."
>> >>
>> >> The main drawback of the SVN repository is that few people can
access
>> it.
>> >> I think that work with Git is more appropriate, but
maintainers should
>> up to
>> >> date the master fork from all the pull requests.
>> >>
>> >> If we continue as at present, there will be patches in the Git
>> repository
>> >> for months, but not added to the main repository. I.E. : The
microsoft
>> >> provider click event patch
>> >> --
>> >> Saludos,
>> >> Pablo L?pez Escob?s
>> >>
>> >> 2010/5/26 Andrew Turner <andrew at highearthorbit.com>
>> >>>
>> >>> Ok - sorry again for the confusion here. The Github
repository was
>> >>> never meant to try and be a parallel repository but since
we were
>> >>> using Git internally and for several collaborative
projects, I put a
>> >>> copy up.
>> >>>
>> >>> I added notes in a README as a very first pass:
>> >>> http://github.com/mapstraction/mxn
>> >>>
>> >>> And I also updated the description at the top.
>> >>>
>> >>> I''d like to discuss using Git as the repository -
but only after
>> >>> discussion/consensus. But lets separate that from this.
>> >>>
>> >>> If people would prefer, I can "hide" the MXN
project on Github if the
>> >>> README and description aren''t sufficient.
I''m curious to hear how
>> >>> people found it (for example, are people browsing Github
more often
>> >>> now?)
>> >>>
>> >>> Andrew
>> >>>
>> >>> On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at
vitotafuni.com>
>> wrote:
>> >>> > I hope i''ve made it the right way...
>> >>> >
>> >>> > i created a fork on github, changed the svn more
recent files
>> >>> > and than commited with some changes i''ve
talked about today
>> (microsoft
>> >>> > &
>> >>> > googlev3)
>> >>> >
>> >>> > i''ve made a pull request too
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > -----------
>> >>> > Tafuni Vito
>> >>> > vito at vitotafuni.com
>> >>> > ---------------------------------------------
>> >>> > "Verba volant, scripta manent... data
corrupted"
>> >>> >
>> >>> >
>> >>> > 2010/5/25 Vito Tafuni <vito at vitotafuni.com>
>> >>> >>
>> >>> >> agree 200%
>> >>> >>
>> >>> >> but at the moment the problem is:
>> >>> >> i want to contribute but i don''t want to
work on an old version!!!
>> >>> >>
>> >>> >> so... ok for 2 versioning... but i think that
"last version on svn"
>> <>> >>> >> "last version on git" and
not viceversa
>> >>> >>
>> >>> >> because (let me pass this comparison with debian)
i think git is
>> the
>> >>> >> unstable version (or experimental) and svn the
testing one ready to
>> >>> >> use for
>> >>> >> who doesn''t want to bother with
problems.
>> >>> >>
>> >>> >>
>> >>> >> so i refer back the question: can i have an
update git version or i
>> >>> >> have
>> >>> >> to manually merge my fork with the last svn??
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> -----------
>> >>> >> Tafuni Vito
>> >>> >> vito at vitotafuni.com
>> >>> >> ---------------------------------------------
>> >>> >> "Verba volant, scripta manent... data
corrupted"
>> >>> >>
>> >>> >>
>> >>> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at
gmail.com>
>> >>> >>>
>> >>> >>> I agree too.
>> >>> >>>
>> >>> >>> It''s necessary choose one and give
complete docummentation.
>> >>> >>>
>> >>> >>> Everybody should be able to collaborate
without these
>> >>> >>> misunderstandings.
>> >>> >>>
>> >>> >>> --
>> >>> >>> Saludos,
>> >>> >>> Pablo L?pez Escob?s
>> >>> >>>
>> >>> >>> 2010/5/25 Ed Freyfogle <edf at
sloan.mit.edu>
>> >>> >>>>
>> >>> >>>> agree 100%. pick one and let''s
go with it. two solutions means
>> >>> >>>> chaos.
>> >>> >>>>
>> >>> >>>>
>> >>> >>>> 2010/5/25 Lev Tsypin <lev at
levelos.com>
>> >>> >>>>>
>> >>> >>>>> I feel that having multiple
repositories is a huge PITA and very
>> >>> >>>>> confusing. Development vs stable code
bases is what branches are
>> >>> >>>>> for a
>> >>> >>>>> within repository, E.g.,
we''d have a stable branch for every
>> major
>> >>> >>>>> version,
>> >>> >>>>> tags for each release, with active
development taking place in
>> >>> >>>>> either trunk
>> >>> >>>>> or a major version dev branch. If
we''re going to use Google
>> Code,
>> >>> >>>>> lets dive
>> >>> >>>>> in and use it, actively using the
wiki, issue queue, mailing
>> list,
>> >>> >>>>> granting
>> >>> >>>>> other developers rights, etc.
Otherwise, lets switch to Git and
>> >>> >>>>> GitHub. The
>> >>> >>>>> advantages of the latter are the
ability for developers w/o
>> commit
>> >>> >>>>> access to
>> >>> >>>>> fork the project, still make
incremental commits, and then
>> submit
>> >>> >>>>> more
>> >>> >>>>> complete changes back to the master
repo, which can be accepted
>> in
>> >>> >>>>> whole or
>> >>> >>>>> in part. I think Git is better for a
project like this, but
>> >>> >>>>> understand there
>> >>> >>>>> may be momentum with Google Code. My
2 cents.
>> >>> >>>>> On May 25, 2010, at 10:53 AM, Vito
Tafuni wrote:
>> >>> >>>>>
>> >>> >>>>> i''ve understood the
principle to have 2 versioning system
>> >>> >>>>> but now i would like to help the
project growing (and have a
>> >>> >>>>> full-working version to use)
>> >>> >>>>>
>> >>> >>>>> Lev Tsypin
>> >>> >>>>> _____________________
>> >>> >>>>> Level Online Strategy, LLC
>> >>> >>>>> 503.342.8044
>> >>> >>>>> levelos.com | twitter.com/levelos
>> >>> >>>>>
>> >>> >>>>>
_______________________________________________
>> >>> >>>>> Mapstraction mailing list
>> >>> >>>>> Mapstraction at
lists.mapstraction.com
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>>
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>> >>>>>
>> >>> >>>>
>> >>> >>>>
>> >>> >>>>
_______________________________________________
>> >>> >>>> Mapstraction mailing list
>> >>> >>>> Mapstraction at lists.mapstraction.com
>> >>> >>>>
>> >>> >>>>
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>> >>>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
_______________________________________________
>> >>> >>> Mapstraction mailing list
>> >>> >>> Mapstraction at lists.mapstraction.com
>> >>> >>>
>> >>> >>>
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>> >>>
>> >>> >>
>> >>> >
>> >>> >
>> >>> > _______________________________________________
>> >>> > Mapstraction mailing list
>> >>> > Mapstraction at lists.mapstraction.com
>> >>> >
>> >>> >
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>> >
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Andrew Turner
>> >>> mobile: 248.982.3609
>> >>> andrew at fortiusone.com
>> >>> http://highearthorbit.com
>> >>>
>> >>> http://geocommons.com Helping build the
Geospatial Web
>> >>> Introduction to Neogeography -
>> http://oreilly.com/catalog/neogeography
>> >>> _______________________________________________
>> >>> Mapstraction mailing list
>> >>> Mapstraction at lists.mapstraction.com
>> >>>
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>
>> >>
>> >> _______________________________________________
>> >> Mapstraction mailing list
>> >> Mapstraction at lists.mapstraction.com
>> >>
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >>
>> >
>> >
>> > _______________________________________________
>> > Mapstraction mailing list
>> > Mapstraction at lists.mapstraction.com
>> >
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>> >
>> >
>>
>>
>>
>> --
>> Andrew Turner
>> mobile: 248.982.3609
>> andrew at fortiusone.com
>> http://highearthorbit.com
>>
>> http://geocommons.com Helping build the Geospatial Web
>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography
>> _______________________________________________
>> Mapstraction mailing list
>> Mapstraction at lists.mapstraction.com
>>
http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>>
>
>
>
> --
> Derek Fowler
> m. +44 (0) 7966 512 369
> e. dezfowler at gmail.com
>
> _______________________________________________
> Mapstraction mailing list
> Mapstraction at lists.mapstraction.com
> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100528/58a76026/attachment-0001.htm>
I doubt there will be that large a number - should be manageable. I''m currently working on getting your geocoding changes in - am doing a few amends so once Git is up to date I''ll get them into a branch for you to have a look at before I put them in to the trunk. Then I''ll have a look at your interactive stuff. Derek 2010/5/28 Pablo L?pez Escob?s <plopesc at gmail.com>> Hi! > > I''m happy for your decission. Using Git, everybody can fork the master > branch and develop their own patches. > > However, maintainers will have to work hard because there will be a big > number of pull requests and decide which are really beneficial for the > library. > > If you wish, I volunteer to work with maintainers and help as possible. > > -- > Saludos, > Pablo L?pez Escob?s > > > 2010/5/28 Derek Fowler <dezfowler at gmail.com> > > I''m happy to move to Github. I''m also happy to migrate all the existing >> issues across to the Github repository and to either delete the Google Code >> one or put big messages in there saying it''s moved. Andrew, is the Github >> version synced up with SVN now? If so I''ll see about locking Google Code to >> stop further commits. I''ll also migrate all the items across from issue >> tracking however my net connection at home has been down for three days now >> so I may not be able to work on it until next week. >> >> Github seems much better from a people taking forks and submitting patches >> back without needing permissions on the master repository - I''m sorry I >> didn''t just trust your judgement when we set it up now. >> >> Derek >> >> On 28 May 2010 03:41, Andrew Turner <andrew at highearthorbit.com> wrote: >> >>> So this is the crux of the problem for me - there are many >>> contributors and will be many more! >>> >>> However SVN is overly restricting & hierarchical. Do we give anyone >>> SVN access? Only after you''ve submitted so many patches? that requires >>> a developer to manually bring patches into SVN all the time until >>> people are trusted enough to push into the official SVN. Should we >>> give anyone access to SVN that asks but only link to tagged releases >>> and make it very clear that the SVN is very volatile? >>> >>> My preference would be to use Github, give a few of the core devs >>> commit access to the Mapstraction user and let new contributes make >>> their forks and pull requests that can be vetted and merged into the >>> Mapstraction user with tests and verification. >>> >>> But I also have not had the bandwidth lately to support the project >>> and fortunately there have been awesome developers such as Derek, Ed, >>> Rob and many more that have. So while I prefer Git - it really resides >>> on them currently to authorize who should get SVN access and pull in >>> patches if that''s the path we continue to stay on. >>> >>> Let me know and I will take down the Github version. >>> Andrew >>> >>> >>> On Wed, May 26, 2010 at 3:55 AM, Vito Tafuni <vito at vitotafuni.com> >>> wrote: >>> > I agree with both Andrew and Pablo: >>> > 1. we have to use one versioning system >>> > 2. critical changes made on that system need to be available for new >>> > developers (and users) asap >>> > >>> > last time i used a versioning system it was cvs so choosing between svn >>> or >>> > git is not the problem for me... even if git seems to be more >>> appropriate >>> > for collaborative development >>> > >>> > @Andrew: ok let''s use svn! but... how can i be a committer on google >>> code >>> > repos?? i need the changes i''ve made because i''m working on a project >>> (i >>> > think a lot of people would like the click event to fire correctly!) >>> but i >>> > would like to update my local repository with new code developed by >>> others >>> > too (and not to be alone on my fork, losting a lot of interesting new >>> > features!!) >>> > >>> > >>> > sorry for my english... i hope you understand my point of view >>> > >>> > -Vito- >>> > >>> > >>> > -- >>> > ----------- >>> > Tafuni Vito >>> > vito at vitotafuni.com >>> > --------------------------------------------- >>> > "Verba volant, scripta manent... data corrupted" >>> > >>> > >>> > 2010/5/26 Pablo L?pez Escob?s <plopesc at gmail.com> >>> >> >>> >> I found the Mapstraction v2 library at Git through your blog >>> >> (http://highearthorbit.com/mapstraction-updates/), where we I read: >>> >> >>> >>> "In order to start promoting the new API and encouraging developers >>> to >>> >>> come and help out, we put the source code and tickets into a Google >>> Code >>> >>> project. Although, being Subversion, you still have to submit patches >>> to get >>> >>> changes accepted for now. So I personally suggest working from the >>> Github >>> >>> version, which will be kept up to speed with git-svn, and then you >>> can >>> >>> submit patches from here to push into the ?official? subversion >>> repository." >>> >> >>> >> The main drawback of the SVN repository is that few people can access >>> it. >>> >> I think that work with Git is more appropriate, but maintainers should >>> up to >>> >> date the master fork from all the pull requests. >>> >> >>> >> If we continue as at present, there will be patches in the Git >>> repository >>> >> for months, but not added to the main repository. I.E. : The microsoft >>> >> provider click event patch >>> >> -- >>> >> Saludos, >>> >> Pablo L?pez Escob?s >>> >> >>> >> 2010/5/26 Andrew Turner <andrew at highearthorbit.com> >>> >>> >>> >>> Ok - sorry again for the confusion here. The Github repository was >>> >>> never meant to try and be a parallel repository but since we were >>> >>> using Git internally and for several collaborative projects, I put a >>> >>> copy up. >>> >>> >>> >>> I added notes in a README as a very first pass: >>> >>> http://github.com/mapstraction/mxn >>> >>> >>> >>> And I also updated the description at the top. >>> >>> >>> >>> I''d like to discuss using Git as the repository - but only after >>> >>> discussion/consensus. But lets separate that from this. >>> >>> >>> >>> If people would prefer, I can "hide" the MXN project on Github if the >>> >>> README and description aren''t sufficient. I''m curious to hear how >>> >>> people found it (for example, are people browsing Github more often >>> >>> now?) >>> >>> >>> >>> Andrew >>> >>> >>> >>> On Tue, May 25, 2010 at 3:15 PM, Vito Tafuni <vito at vitotafuni.com> >>> wrote: >>> >>> > I hope i''ve made it the right way... >>> >>> > >>> >>> > i created a fork on github, changed the svn more recent files >>> >>> > and than commited with some changes i''ve talked about today >>> (microsoft >>> >>> > & >>> >>> > googlev3) >>> >>> > >>> >>> > i''ve made a pull request too >>> >>> > >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > ----------- >>> >>> > Tafuni Vito >>> >>> > vito at vitotafuni.com >>> >>> > --------------------------------------------- >>> >>> > "Verba volant, scripta manent... data corrupted" >>> >>> > >>> >>> > >>> >>> > 2010/5/25 Vito Tafuni <vito at vitotafuni.com> >>> >>> >> >>> >>> >> agree 200% >>> >>> >> >>> >>> >> but at the moment the problem is: >>> >>> >> i want to contribute but i don''t want to work on an old version!!! >>> >>> >> >>> >>> >> so... ok for 2 versioning... but i think that "last version on >>> svn" <>>> >>> >> "last version on git" and not viceversa >>> >>> >> >>> >>> >> because (let me pass this comparison with debian) i think git is >>> the >>> >>> >> unstable version (or experimental) and svn the testing one ready >>> to >>> >>> >> use for >>> >>> >> who doesn''t want to bother with problems. >>> >>> >> >>> >>> >> >>> >>> >> so i refer back the question: can i have an update git version or >>> i >>> >>> >> have >>> >>> >> to manually merge my fork with the last svn?? >>> >>> >> >>> >>> >> >>> >>> >> -- >>> >>> >> ----------- >>> >>> >> Tafuni Vito >>> >>> >> vito at vitotafuni.com >>> >>> >> --------------------------------------------- >>> >>> >> "Verba volant, scripta manent... data corrupted" >>> >>> >> >>> >>> >> >>> >>> >> 2010/5/25 Pablo L?pez Escob?s <plopesc at gmail.com> >>> >>> >>> >>> >>> >>> I agree too. >>> >>> >>> >>> >>> >>> It''s necessary choose one and give complete docummentation. >>> >>> >>> >>> >>> >>> Everybody should be able to collaborate without these >>> >>> >>> misunderstandings. >>> >>> >>> >>> >>> >>> -- >>> >>> >>> Saludos, >>> >>> >>> Pablo L?pez Escob?s >>> >>> >>> >>> >>> >>> 2010/5/25 Ed Freyfogle <edf at sloan.mit.edu> >>> >>> >>>> >>> >>> >>>> agree 100%. pick one and let''s go with it. two solutions means >>> >>> >>>> chaos. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> 2010/5/25 Lev Tsypin <lev at levelos.com> >>> >>> >>>>> >>> >>> >>>>> I feel that having multiple repositories is a huge PITA and >>> very >>> >>> >>>>> confusing. Development vs stable code bases is what branches >>> are >>> >>> >>>>> for a >>> >>> >>>>> within repository, E.g., we''d have a stable branch for every >>> major >>> >>> >>>>> version, >>> >>> >>>>> tags for each release, with active development taking place in >>> >>> >>>>> either trunk >>> >>> >>>>> or a major version dev branch. If we''re going to use Google >>> Code, >>> >>> >>>>> lets dive >>> >>> >>>>> in and use it, actively using the wiki, issue queue, mailing >>> list, >>> >>> >>>>> granting >>> >>> >>>>> other developers rights, etc. Otherwise, lets switch to Git and >>> >>> >>>>> GitHub. The >>> >>> >>>>> advantages of the latter are the ability for developers w/o >>> commit >>> >>> >>>>> access to >>> >>> >>>>> fork the project, still make incremental commits, and then >>> submit >>> >>> >>>>> more >>> >>> >>>>> complete changes back to the master repo, which can be accepted >>> in >>> >>> >>>>> whole or >>> >>> >>>>> in part. I think Git is better for a project like this, but >>> >>> >>>>> understand there >>> >>> >>>>> may be momentum with Google Code. My 2 cents. >>> >>> >>>>> On May 25, 2010, at 10:53 AM, Vito Tafuni wrote: >>> >>> >>>>> >>> >>> >>>>> i''ve understood the principle to have 2 versioning system >>> >>> >>>>> but now i would like to help the project growing (and have a >>> >>> >>>>> full-working version to use) >>> >>> >>>>> >>> >>> >>>>> Lev Tsypin >>> >>> >>>>> _____________________ >>> >>> >>>>> Level Online Strategy, LLC >>> >>> >>>>> 503.342.8044 >>> >>> >>>>> levelos.com | twitter.com/levelos >>> >>> >>>>> >>> >>> >>>>> _______________________________________________ >>> >>> >>>>> Mapstraction mailing list >>> >>> >>>>> Mapstraction at lists.mapstraction.com >>> >>> >>>>> >>> >>> >>>>> >>> >>> >>>>> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >>>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> _______________________________________________ >>> >>> >>>> Mapstraction mailing list >>> >>> >>>> Mapstraction at lists.mapstraction.com >>> >>> >>>> >>> >>> >>>> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> >>> Mapstraction mailing list >>> >>> >>> Mapstraction at lists.mapstraction.com >>> >>> >>> >>> >>> >>> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> >>> >>> >>> >> >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Mapstraction mailing list >>> >>> > Mapstraction at lists.mapstraction.com >>> >>> > >>> >>> > >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Andrew Turner >>> >>> mobile: 248.982.3609 >>> >>> andrew at fortiusone.com >>> >>> http://highearthorbit.com >>> >>> >>> >>> http://geocommons.com Helping build the Geospatial Web >>> >>> Introduction to Neogeography - >>> http://oreilly.com/catalog/neogeography >>> >>> _______________________________________________ >>> >>> Mapstraction mailing list >>> >>> Mapstraction at lists.mapstraction.com >>> >>> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> >>> >> >>> >> _______________________________________________ >>> >> Mapstraction mailing list >>> >> Mapstraction at lists.mapstraction.com >>> >> >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Mapstraction mailing list >>> > Mapstraction at lists.mapstraction.com >>> > >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> > >>> > >>> >>> >>> >>> -- >>> Andrew Turner >>> mobile: 248.982.3609 >>> andrew at fortiusone.com >>> http://highearthorbit.com >>> >>> http://geocommons.com Helping build the Geospatial Web >>> Introduction to Neogeography - http://oreilly.com/catalog/neogeography >>> _______________________________________________ >>> Mapstraction mailing list >>> Mapstraction at lists.mapstraction.com >>> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >>> >> >> >> >> -- >> Derek Fowler >> m. +44 (0) 7966 512 369 >> e. dezfowler at gmail.com >> >> _______________________________________________ >> Mapstraction mailing list >> Mapstraction at lists.mapstraction.com >> http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >> >> > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com > >-- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100528/9454be5e/attachment-0001.htm>
Thanks Derek! Appreciate the effort to make that happen and looking forward to it. On May 28, 2010, at 1:43 AM, Derek Fowler wrote:> I''m happy to move to Github. I''m also happy to migrate all the existing issues across to the Github repository and to either delete the Google Code one or put big messages in there saying it''s moved. Andrew, is the Github version synced up with SVN now? If so I''ll see about locking Google Code to stop further commits. I''ll also migrate all the items across from issue tracking however my net connection at home has been down for three days now so I may not be able to work on it until next week. > > Github seems much better from a people taking forks and submitting patches back without needing permissions on the master repository - I''m sorry I didn''t just trust your judgement when we set it up now. >Lev Tsypin _____________________ Level Online Strategy, LLC 503.342.8044 levelos.com | twitter.com/levelos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20100528/8b0d618e/attachment.htm>