Ready for github?

[Rok Garbas]

Ready for Github? I get those moments of excitements which are basically
stupid, but anyway you feel good. So is this one ... but nevertheless
... are you ready for Github!


1. Code: http://github.com/plone/svn-migrate
for documentation just follow README.rst


2. Help needed! In any form:
 - contact me if you need help to get started (maybe i can give you dump
of svn repositories so you wont need to wait 3 days to sync it)
 - write migration rules
 - help me setup jenkins project using
 - write script which will query plone.org and plone's ldap which will
map permissions as we have them in ldap
 - write coredev documentation which hanno already started
(https://github.com/plone/coredev-docs)
 - buy me rum (http://www.legendario.com/) to keep me working on this, i
have 1.5 bottles on stock and i'm quickly running out.


3. Permissions on ldap (in short):
 - github's permissions suck. then know it. everyone who tried to used
their api knows it.
 - for this we will create 2 groups: Administrators and Developers.
Administrators will, in addition to pull/push permissions the Developers
have, have the permissions to create/remove repositories.


4. Migration plan:
 - migration script is ready.
 - migrate 'plone-coredev' and rewrite sources to github
 - run tests in jenkins using github sources for 4.1, 4.2 (anybody
thinks we should also do this for 4.0 and 3.3?)
 - script that will update Developers team with plone core commiters
from ldap. (help on this much appreciated)
 - after and only after tests are passing for needed plone-coderev
branches we give 1 week announcement (or change that 1 week to as long
as you think its appropriate) that svn.plone.org/svn/(plone|archetypes)
will go into read-only mode.
 - above step will hopefully will attract more ppl to test migration.
 - if no bigger problem arises we put
svn.plone.org/svn/(plone|archetypes) to read-only
 - and we use github happily ever after



none of above is set to stone, i want to share with you my views and
hopefully you'll correct me if you see something you think could be done
better.



--
Rok





------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[johannes raggam]

yay! good to see that the svn to git move is progressing. but some
questions arise, nevertheless:

* github is a commercial company, although they have strong support on
open source projects. how does the github team feel about another big
open source project moving to them? which obligations does the plone
foundation have against github then? there might be none, but i don't know.

* is github doing backups, which are accessible to us? i don't think so.
if not, we need a backup strategy like cloning/pulling all repositories
once a day.

On 08/27/2011 12:44 PM, Rok Garbas wrote:
>  1. Code: http://github.com/plone/svn-migrate for documentation just
>  follow README.rst

* are you talking about plone-core packages only? what about the rest of
the collective packages then?

>  3. Permissions on ldap (in short): - github's permissions suck. then
>  know it. everyone who tried to used their api knows it. - for this
>  we will create 2 groups: Administrators and Developers.
>  Administrators will, in addition to pull/push permissions the
>  Developers have, have the permissions to create/remove repositories.

* this will mean, that if you aren't in the admin group, you won't be
able to create new repositories. i guess, this will take away some of
the development agility.
on the other hand, with the github fork/pull request development model
in mind, developers could create repositories in their own account in
the first place and push-requesting it then to the plone/collective
development space. so this could also be a chance of a slightly cleaner
development spaces.

>  4. Migration plan: - migration script is ready. - migrate
>  'plone-coredev' and rewrite sources to github - run tests in jenkins
>  using github sources for 4.1, 4.2 (anybody thinks we should also do
>  this for 4.0 and 3.3?) - script that will update Developers team
>  with plone core commiters from ldap. (help on this much appreciated)

* all of the plone coredevs must have a github account for this and
announce their plone-svn to github account name mapping. mine is thet,
on both sides.

>  - after and only after tests are passing for needed plone-coderev
>  branches we give 1 week announcement (or change that 1 week to as
>  long as you think its appropriate) that
>  svn.plone.org/svn/(plone|archetypes) will go into read-only mode.
fine for me.

>  - above step will hopefully will attract more ppl to test migration.
>  - if no bigger problem arises we put
>  svn.plone.org/svn/(plone|archetypes) to read-only - and we use
>  github happily ever after

best,
hannes

--
johannes raggam / thet,thetet
python plone zope development
mailto: [hidden email]
web:  http://bluedynamics.com


------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Sat, Aug 27, 2011 at 7:00 PM, Johannes Raggam <[hidden email]> wrote:
> yay! good to see that the svn to git move is progressing.

Yep, Rok and Wyn have volunteered to shepherd the whole effort - as
I'm simple not finding the time to follow-up on this.

> * github is a commercial company, although they have strong support on
> open source projects. how does the github team feel about another big
> open source project moving to them? which obligations does the plone
> foundation have against github then? there might be none, but i don't know.

Github has decent terms of service, which I have reviewed and I think
Wyn asked the Foundation board to do the same. There's nothing
surprising in those and I trust Github as much as the other commercial
companies we rely on and have given our entire source code, like
Geeknet Inc (sf.net), Canonical Ltd (launchpad.net) or the various
organizations and companies involved in hosting the various plone.org
servers.

We haven't asked Github about us moving our code to them. Compared to
the other big foundations like Apache and Mozilla we are pretty small
and they shouldn't notice us. What we are doing is well covered by
their standard terms.

> * is github doing backups, which are accessible to us? i don't think so.
> if not, we need a backup strategy like cloning/pulling all repositories
> once a day.

Yes, I believe this is on Wyn's list.

> * are you talking about plone-core packages only? what about the rest of
> the collective packages then?

My proposal has always been about Plone Core only - but actually all
of that no matter what repository it currently lives in.

We are specifically not talking about moving the entire collective.
The permission and sharing model of github isn't compatible with the
way we work in the collective as Rok's experiment has shown. As for
large parts of Archetypes or various other code in the Plone repo, I
think those can move over, if there's current maintainers which are
interested in this. There's a lot of old code for which it doesn't
make much sense to move it with us. We also left a good deal of code
in the old sf.net CVS repos. These are still available and if somebody
comes along and wants to work on these we can move them on demand.

> * this will mean, that if you aren't in the admin group, you won't be
> able to create new repositories. i guess, this will take away some of
> the development agility.

That's another reason why we are only talking about Plone Core at this
point. Getting code into Plone Core is a structured process already
and it's not up to any one single person to decide about this. So I
think it's perfectly fine to have some process around what gets into
the foundations repository - after all we only get a new project every
month or so - and you can always start the code locally without having
it published to github.

> * all of the plone coredevs must have a github account for this and
> announce their plone-svn to github account name mapping. mine is thet,
> on both sides.

For the actual migration script we don't need the github account
names. It maps SVN usernames to email addresses - so we can take those
out of plone.org's LDAP. But we will need those account names to give
everyone commit rights ;)

Hanno

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Laurence Rowe]

On 27 August 2011 18:27, Hanno Schlichting <[hidden email]> wrote:
> On Sat, Aug 27, 2011 at 7:00 PM, Johannes Raggam <[hidden email]> wrote:
>> * all of the plone coredevs must have a github account for this and
>> announce their plone-svn to github account name mapping. mine is thet,
>> on both sides.
>
> For the actual migration script we don't need the github account
> names. It maps SVN usernames to email addresses - so we can take those
> out of plone.org's LDAP. But we will need those account names to give
> everyone commit rights ;)

I guess this means we need to extend the plone.org LDAP schema to add
a field for the github userid, update the plone.org PAS ldap settings
and modify the forms. While we're at it perhaps we should also add
fields for zope svn, launchpad and bitbucket ids - incase they come in
useful some day.

Laurence

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Balazs Ree-2]

On 2011-08-27 17:27:32 +0000, Hanno Schlichting said:

>
>> * is github doing backups, which are accessible to us? i don't think so.
>> if not, we need a backup strategy like cloning/pulling all repositories
>> once a day.
>
> Yes, I believe this is on Wyn's list.
>

This is essential. I've experienced one company loosing all its
repositories, with no backup on github's side. We don't want to happen
this with Plone, so we need our autonomous backups.

Cheers -

--
Balazs Ree, Greenfinity, LLC



------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

On 27/08/11 19:59, Laurence Rowe wrote:

> On 27 August 2011 18:27, Hanno Schlichting <[hidden email]> wrote:
>> > On Sat, Aug 27, 2011 at 7:00 PM, Johannes Raggam <[hidden email]> wrote:
>>> >> * all of the plone coredevs must have a github account for this and
>>> >> announce their plone-svn to github account name mapping. mine is thet,
>>> >> on both sides.
>> >
>> > For the actual migration script we don't need the github account
>> > names. It maps SVN usernames to email addresses - so we can take those
>> > out of plone.org's LDAP. But we will need those account names to give
>> > everyone commit rights ;)
> I guess this means we need to extend the plone.org LDAP schema to add
> a field for the github userid, update the plone.org PAS ldap settings
> and modify the forms. While we're at it perhaps we should also add
> fields for zope svn, launchpad and bitbucket ids - incase they come in
> useful some day.

to map to their user account we need email and fullname ppl use on
github ... so we took the usernames from plone's ldap and did a query on
plone.org (who knew we only store username and password in ldap).

maybe we should move email and fullname to ldap as well. that way we
only query ldap.

any way that gives us back fullname and email in shape of "Fullname
<Email>" is ok with me.



------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

On 27/08/11 20:40, Balazs Ree wrote:

> On 2011-08-27 17:27:32 +0000, Hanno Schlichting said:
>
>> >
>>> >> * is github doing backups, which are accessible to us? i don't think so.
>>> >> if not, we need a backup strategy like cloning/pulling all repositories
>>> >> once a day.
>> >
>> > Yes, I believe this is on Wyn's list.
>> >
> This is essential. I've experienced one company loosing all its
> repositories, with no backup on github's side. We don't want to happen
> this with Plone, so we need our autonomous backups.

github lost data? really? you have any link for this?

maybe we could create mirror to our setup own setup of git (with
gitolite) and we could even mirror to bitbucket. this tasks would be
easier since we are already using some dvcs.






------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

>> * github is a commercial company, although they have strong support on

>> open source projects. how does the github team feel about another big
>> open source project moving to them? which obligations does the plone
>> foundation have against github then? there might be none, but i don't know.
>
> Github has decent terms of service, which I have reviewed and I think
> Wyn asked the Foundation board to do the same. There's nothing
> surprising in those and I trust Github as much as the other commercial
> companies we rely on and have given our entire source code, like
> Geeknet Inc (sf.net), Canonical Ltd (launchpad.net) or the various
> organizations and companies involved in hosting the various plone.org
> servers.
>
> We haven't asked Github about us moving our code to them. Compared to
> the other big foundations like Apache and Mozilla we are pretty small
> and they shouldn't notice us. What we are doing is well covered by
> their standard terms.
>

I'm actually in favor of hosting our project ourself (with gitolite) but
i understand why ppl are in favor of github.

>> * are you talking about plone-core packages only? what about the rest of
>> the collective packages then?
>
> My proposal has always been about Plone Core only - but actually all
> of that no matter what repository it currently lives in.
>
> We are specifically not talking about moving the entire collective.
> The permission and sharing model of github isn't compatible with the
> way we work in the collective as Rok's experiment has shown. As for
> large parts of Archetypes or various other code in the Plone repo, I
> think those can move over, if there's current maintainers which are
> interested in this. There's a lot of old code for which it doesn't
> make much sense to move it with us. We also left a good deal of code
> in the old sf.net CVS repos. These are still available and if somebody
> comes along and wants to work on these we can move them on demand.
>

after this move also thing in github/collection are going to change ...
it will probably work in similar way that github/plone will. group of
ppl saying "its ok, you can put your code into collective". i will write
separate mail on this issue (soon i promise) and we can discuss it. i
will not take actions without discussion.


>> * all of the plone coredevs must have a github account for this and
>> announce their plone-svn to github account name mapping. mine is thet,
>> on both sides.
>
> For the actual migration script we don't need the github account
> names. It maps SVN usernames to email addresses - so we can take those
> out of plone.org's LDAP. But we will need those account names to give
> everyone commit rights ;)
>

thats true, you're right ... we will need then for commits rights.



------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Balazs Ree-2]

On 2011-08-27 19:57:17 +0000, Rok Garbas said:

> On 27/08/11 20:40, Balazs Ree wrote:
>> On 2011-08-27 17:27:32 +0000, Hanno Schlichting said:
>>
>>>>
>>>>>> * is github doing backups, which are accessible to us? i don't think so.
>>>>>> if not, we need a backup strategy like cloning/pulling all repositories
>>>>>> once a day.
>>>>
>>>> Yes, I believe this is on Wyn's list.
>>>>
>> This is essential. I've experienced one company loosing all its
>> repositories, with no backup on github's side. We don't want to happen
>> this with Plone, so we need our autonomous backups.
>
> github lost data? really? you have any link for this?

No. I cannot even tell with whom it happened, or any more details.

> maybe we could create mirror to our setup own setup of git (with
> gitolite) and we could even mirror to bitbucket. this tasks would be
> easier since we are already using some dvcs.


--
Balazs Ree, Greenfinity, LLC



------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[kiorky]

Le 27/08/2011 22:06, Rok Garbas a écrit :
> I'm actually in favor of hosting our project ourself (with gitolite) but
> i understand why ppl are in favor of github.

+1, as github is a commercial company, i would also be more comfurtable with
gitolite.
For backup, it will then also be a lot more trivial.
And it will be easier to map to the current infra.
Only thing we have to loose is the social whistle github has.


--
Cordialement,
KiOrKY
GPG Key FingerPrint: 0x1A1194B7681112AF
Pensez à l’environnement.
N’imprimez ce courriel que si vous en avez vraiment besoin.



------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Hanno Schlichting-4]

On Sun, Aug 28, 2011 at 8:46 PM, kiorky <[hidden email]> wrote:
> +1, as github is a commercial company, i would also be more comfurtable with
> gitolite.
> For backup, it will then also be a lot more trivial.
> And it will be easier to map to the current infra.
> Only thing we have to loose is the social whistle github has.

The straw poll we took for this was very conclusive. Our community
wants Github, SVN or Git - in that order. The numbers of strong
support where 46 Github, 28 SVN and 10 Git out of 79 votes with 33
people being strongly against self-hosted Git.

If there's some roadblock preventing us from moving to Github, we'll
stay with Subversion instead - self hosted Git is not an alternative
that's up for discussion.

Hanno

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

On 28 August 2011 19:46, kiorky <[hidden email]> wrote:

Only thing we have to loose is the social whistle github has.

Which, as Hanno pointed out, is basically the point of any potential migration. :)

Martin 

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[aclark]

On 8/28/11 3:43 PM, Martin Aspeli wrote:

>
>
> On 28 August 2011 19:46, kiorky
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     Only thing we have to loose is the social whistle github has.
>
>
> Which, as Hanno pointed out, is basically the point of any potential
> migration. :)

Heh. I do think a mirror to something like:

- git.plone.org

is a good idea though. And to help everyone sleep at night, we should
daily-cron something like:

for repo in github.com/plone
do
   #git clone $repo
   git pull
done

from somewhere that has tape backups like OSUOSL or SFU.

It's also worth reminding anyone new to git: every git repo has the
potential to be "the" master. So if you are particularly nervous, just
pull core to your laptop every night ;-)


Alex

>
> Martin
>
>
> ------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
>
>
>
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

--
Alex Clark · http://aclark.net


------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

hey,

I'll just continue this tread and update you a little bit on migration
status.


STATUS:

- most of svn2git rules for packages is written (a little more then 100
packages) ... and successfully migrated about 60% of packages, others
needs some additional work.

- migrated plumi projects: http://github.com/plumi

if you wish to migrate some project to git(hub) please send me email. if
your history is sane it would be easy to do while doing migration for plone.

- deco packages migrated to git(hub) as part of preparation for living
statues sprint. packages should be on github in next day as soon as i
get "blessing" from Rob|4D :)


NEXT STEPS:

- this kind of migration can not be smooth for everybody, especially
since there is just too much code to migrate and make no mistakes .
therefore i would propose to migrate packages gradually, updating
plone-coredev sources.cfg to point to new location on github. this
ofcourse does not mean we will migrate for all next year .. just next
month or even less. every move to github will be announced here on this
list.

- to get permissions for github will be done via script which will fetch
github usernames of core commiters from plone.org. but it might take
some time (in next few months) until this done and i dont see a reason
why this would stop us from starting to use github. i suggest here, that
somebody (can be also me) collects github usernames and add/removes them
manually.

- as said already before, documentation would need to be updated to
point to github.









------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

On 18/09/11 04:05, Rok Garbas wrote:

> hey,
>
> I'll just continue this tread and update you a little bit on migration
> status.
>
>
> STATUS:
>
> - most of svn2git rules for packages is written (a little more then 100
> packages) ... and successfully migrated about 60% of packages, others
> needs some additional work.
>
> - migrated plumi projects: http://github.com/plumi
>
> if you wish to migrate some project to git(hub) please send me email. if
> your history is sane it would be easy to do while doing migration for plone.
>
> - deco packages migrated to git(hub) as part of preparation for living
> statues sprint. packages should be on github in next day as soon as i
> get "blessing" from Rob|4D :)
>

deco packages that were migrated:

 * plone.formwidget.querystring
 * plone.app.tiles
 * decobrewery.theme
 * plone.resource
 * plone.app.tinymce
 * plone.tiles
 * Products.ResourceRegistries
 * decobrewery.contenttypes
 * plone.app.deco
 * plone.app.querystring
 * plone.directives.tiles
 * plone.formwidget.multifile
 * plone.app.drafts
 * plone.app.search
 * plone.app.blocks
 * buildout.deco
 * plone.app.page
 * decobrewery.policy
 * plone.app.standardtiles
 * plone.subrequest
 * five.intid

- _dexterity_ packages also migrated to git(hub):

 * collective.z3cform.datagridfield_demo
 * plone.directives.form
 * plone.namedfile
 * plone.scale
 * plone.multilingual
 * example.conference
 * plone.multilingualbehavior
 * plone.formwidget.contenttree
 * plone.synchronize
 * plone.schemaeditor
 * plone.testing
 * buildout.dexterity
 * plone.formwidget.namedfile
 * plone.supermodel
 * plone.app.intid
 * plone.app.lockingbehavior
 * plone.dexterity
 * plone.app.dexterity
 * plone.formwidget.autocomplete
 * plone.autoform
 * plone.folder
 * plone.app.textfield
 * plone.app.relationfield
 * collective.z3cform.datetimewidget
 * plone.rfc822
 * plone.app.versioningbehavior
 * plone.app.referenceablebehavior
 * plone.app.z3cform
 * plone.uuid
 * collective.z3cform.datagridfield
 * plone.app.stagingbehavior
 * plone.alterego
 * plone.behavior
 * plone.directives.dexterity
 * example.dexterity



------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

What happens if people now work on Dexterity or Deco in the "old" buildouts in svn?

Martin

On 18 September 2011 05:22, Rok Garbas <[hidden email]> wrote:

On 18/09/11 04:05, Rok Garbas wrote:
> hey,
>
> I'll just continue this tread and update you a little bit on migration
> status.
>
>
> STATUS:
>
> - most of svn2git rules for packages is written (a little more then 100
> packages) ... and successfully migrated about 60% of packages, others
> needs some additional work.
>
> - migrated plumi projects: http://github.com/plumi
>
> if you wish to migrate some project to git(hub) please send me email. if
> your history is sane it would be easy to do while doing migration for plone.
>
> - deco packages migrated to git(hub) as part of preparation for living
> statues sprint. packages should be on github in next day as soon as i
> get "blessing" from Rob|4D :)
>

deco packages that were migrated:

 * plone.formwidget.querystring
 * plone.app.tiles
 * decobrewery.theme
 * plone.resource
 * plone.app.tinymce
 * plone.tiles
 * Products.ResourceRegistries
 * decobrewery.contenttypes
 * plone.app.deco
 * plone.app.querystring
 * plone.directives.tiles
 * plone.formwidget.multifile
 * plone.app.drafts
 * plone.app.search
 * plone.app.blocks
 * buildout.deco
 * plone.app.page
 * decobrewery.policy
 * plone.app.standardtiles
 * plone.subrequest
 * five.intid

- _dexterity_ packages also migrated to git(hub):

 * collective.z3cform.datagridfield_demo
 * plone.directives.form
 * plone.namedfile
 * plone.scale
 * plone.multilingual
 * example.conference
 * plone.multilingualbehavior
 * plone.formwidget.contenttree
 * plone.synchronize
 * plone.schemaeditor
 * plone.testing
 * buildout.dexterity
 * plone.formwidget.namedfile
 * plone.supermodel
 * plone.app.intid
 * plone.app.lockingbehavior
 * plone.dexterity
 * plone.app.dexterity
 * plone.formwidget.autocomplete
 * plone.autoform
 * plone.folder
 * plone.app.textfield
 * plone.app.relationfield
 * collective.z3cform.datetimewidget
 * plone.rfc822
 * plone.app.versioningbehavior
 * plone.app.referenceablebehavior
 * plone.app.z3cform
 * plone.uuid
 * collective.z3cform.datagridfield
 * plone.app.stagingbehavior
 * plone.alterego
 * plone.behavior
 * plone.directives.dexterity
 * example.dexterity

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Rok Garbas]

On 18/09/11 14:25, Martin Aspeli wrote:
> What happens if people now work on Dexterity or Deco in the "old"
> buildouts in svn?
>

right now nothing... but i would like to change that as soon as
possible. i'm still waiting for for "go do it" words to actually do it.

the thing is ... i'll have some time to work on this, if there are any
issues, next week so i would like to push this thing.

i would update deco/dexterity buildout sources, check that they run
(here i would need help just so i check eveything) and then create "We
moved to github" README file on root of that project in svn. this should
stop ppl from commiting to svn and start pointing their buildouts to github.

would this be ok?



--
Rok Garbas - http://www.garbas.si

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

On 18 September 2011 13:36, Rok Garbas <[hidden email]> wrote:

On 18/09/11 14:25, Martin Aspeli wrote:
> What happens if people now work on Dexterity or Deco in the "old"
> buildouts in svn?
>

right now nothing... but i would like to change that as soon as
possible. i'm still waiting for for "go do it" words to actually do it.

Are we saying those packages are now "officially" migrated, or we did a proof of concept and once we give the word "go" we do another migration and then do something to lock down SVN?

Martin

 

the thing is ... i'll have some time to work on this, if there are any
issues, next week so i would like to push this thing.

i would update deco/dexterity buildout sources, check that they run
(here i would need help just so i check eveything) and then create "We
moved to github" README file on root of that project in svn. this should
stop ppl from commiting to svn and start pointing their buildouts to github.

would this be ok?



--
Rok Garbas - http://www.garbas.si

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[aclark]

On 9/18/11 8:46 AM, Martin Aspeli wrote:

>
>
> On 18 September 2011 13:36, Rok Garbas <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 18/09/11 14:25, Martin Aspeli wrote:
>      > What happens if people now work on Dexterity or Deco in the "old"
>      > buildouts in svn?
>      >
>
>     right now nothing... but i would like to change that as soon as
>     possible. i'm still waiting for for "go do it" words to actually do it.
>
>
> Are we saying those packages are now "officially" migrated, or we did a
> proof of concept and once we give the word "go" we do another migration
> and then do something to lock down SVN?

I believe the latter. And I would try to coordinate with Martior about
locking down svn, to whatever extent that is possible (I assume you can
set auth on specific dirs within /svn/plone e.g.
/svn/plone/plone.dexterity.)


Alex

>
> Martin
>
>     the thing is ... i'll have some time to work on this, if there are any
>     issues, next week so i would like to push this thing.
>
>     i would update deco/dexterity buildout sources, check that they run
>     (here i would need help just so i check eveything) and then create "We
>     moved to github" README file on root of that project in svn. this should
>     stop ppl from commiting to svn and start pointing their buildouts to
>     github.
>
>     would this be ok?
>
>
>
>     --
>     Rok Garbas - http://www.garbas.si
>
>
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
>
>
>
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

--
Alex Clark · http://aclark.net


------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Laurence Rowe]

On 18 September 2011 13:46, Martin Aspeli <[hidden email]> wrote:

>
>
> On 18 September 2011 13:36, Rok Garbas <[hidden email]> wrote:
>>
>> On 18/09/11 14:25, Martin Aspeli wrote:
>> > What happens if people now work on Dexterity or Deco in the "old"
>> > buildouts in svn?
>> >
>>
>> right now nothing... but i would like to change that as soon as
>> possible. i'm still waiting for for "go do it" words to actually do it.
>
> Are we saying those packages are now "officially" migrated, or we did a
> proof of concept and once we give the word "go" we do another migration and
> then do something to lock down SVN?
> Martin

We need to ensure that SVN gets locked down for packages that are
migrated or it could all become too confusing.

Laurence

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
http://p.sf.net/sfu/rim-devcon-copy2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers