subversion migration

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

subversion migration

fwierzbicki@gmail.com
All,

I'm going to try to test out the sourceforge subversion migration tool
next weekend (April 8-9).  If the test goes absolutely perfectly, I
will be considering calling the result the new official repository.
The current CVS repository should not be changed at all (I'll back it
up just in case) so if the tool does not yield a perfect result, then
this move may need to be put off.

The important thing is: I'd like any commiters that are sitting on any
changes they would like to get in, to please finish up and get them
into CVS by next Friday (April 7).

Thanks,

-Frank


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Walter Chang-2
Hi Frank...

Can we get a list of users that have commit access, sort of get an
feeling who our "upperclassmen" are ?

It would be interesting to see what their views on the recent feedback are...

Regards,
Walter


On 3/31/06, Frank Wierzbicki <[hidden email]> wrote:

> All,
>
> I'm going to try to test out the sourceforge subversion migration tool
> next weekend (April 8-9).  If the test goes absolutely perfectly, I
> will be considering calling the result the new official repository.
> The current CVS repository should not be changed at all (I'll back it
> up just in case) so if the tool does not yield a perfect result, then
> this move may need to be put off.
>
> The important thing is: I'd like any commiters that are sitting on any
> changes they would like to get in, to please finish up and get them
> into CVS by next Friday (April 7).
>
> Thanks,
>
> -Frank
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> <a href="http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>


--
Simplicity--the art of maximizing the amount
of work not done--is essential.
from: http://www.agilemanifesto.org/principles.html


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

oti-3
Hi,

project developers can be found here:
    http://sourceforge.net/project/memberlist.php?group_id=12867

Best wishes,
Oti.

On 4/1/06, Walter Chang <[hidden email]> wrote:
> Hi Frank...
>
> Can we get a list of users that have commit access, sort of get an
> feeling who our "upperclassmen" are ?
>
> It would be interesting to see what their views on the recent feedback are...


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Walter Chang-2
Thanks Oti...

What do you think of the recent activity?

:)

Regards,
Walter


On 3/31/06, Oti <[hidden email]> wrote:

> Hi,
>
> project developers can be found here:
>     http://sourceforge.net/project/memberlist.php?group_id=12867
>
> Best wishes,
> Oti.
>
> On 4/1/06, Walter Chang <[hidden email]> wrote:
> > Hi Frank...
> >
> > Can we get a list of users that have commit access, sort of get an
> > feeling who our "upperclassmen" are ?
> >
> > It would be interesting to see what their views on the recent feedback are...
>


--
Simplicity--the art of maximizing the amount
of work not done--is essential.
from: http://www.agilemanifesto.org/principles.html


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

oti-3
Walter,

I like people who care and take care.
And for me the current discussion is in big parts: care and take care of Jython.
That's the positive part for me, since I am pretty addicted to Jython,
and I want to help to move it forward.

On the other side, I am a bit sceptical concerning tendencies like
"money and management".
In my daytime life as an employee, I can see the slowing down effect
of too much management, and I don't see how these fit onto the Jython
project.

You might say that I am not in a position to speak of slowing down,
since my pace of production is already quite slow (explanation below).

But I strongly believe that taking care also means not throwing down the walls:
 - make and keep the codebase solid
 - make and keep the tests solid
and the same for website, build, installer, ...

In German we have a saying:
  Viele Koeche verderben den Brei
which, straighforward translated, leads to:
  Too many cooks spoil the menu

So the challenge for Frank is to really well coordinate all the
efforts, and find the appropriate delegate/control balance. This is
difficult, IMHO. Let's support him as much as we can!

Best wishes,
Oti


PS:

Since I am >= 100% employed, and member of a family, Jython developer
time is relatively short for me.

On 4/1/06, Walter Chang <[hidden email]> wrote:
> Thanks Oti...
>
> What do you think of the recent activity?
>
> :)


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Yan Weng
Oti,

I was a Jython user and am working for a company bigger than BEA. I still like Jython and hope to use it in our production system. However, I do have similar concern as Walter has on jython project's current status.

Back to the the "management" topic. Personally, I believe introducing some management, or organization, to Jython project will actually do more good than bad. Walter has mentioned Scrum, which is a good agile development approach.  By doing daily scrum, the community can clearly see the activity of the dev team and understand the capacity of the team. By creating back log and doing monthly sprint, we can choose the reasonable amount important tasks and then focus on them. Then we can *deliver* features and improvements regularly. And that's what jython project really needs.

Several suggestions to the dev team:
1. Make Frank's mock up site page official. It has been more than two months when I heard "really close" to launch the new site page last time. If some link in the page doesn't work, just remove it. We can always add it later.
2. Create a  feature list and assign priorities. Volunteers  still can pick up whatever tasks they are interested. But at least they know which task can benefit the community most before choosing the task.

Just my 2 cents.

Thx,

Yan

On 3/31/06, Oti <[hidden email]> wrote:
Walter,

I like people who care and take care.
And for me the current discussion is in big parts: care and take care of Jython.
That's the positive part for me, since I am pretty addicted to Jython,
and I want to help to move it forward.

On the other side, I am a bit sceptical concerning tendencies like
"money and management".
In my daytime life as an employee, I can see the slowing down effect
of too much management, and I don't see how these fit onto the Jython
project.

You might say that I am not in a position to speak of slowing down,
since my pace of production is already quite slow (explanation below).

But I strongly believe that taking care also means not throwing down the walls:
- make and keep the codebase solid
- make and keep the tests solid
and the same for website, build, installer, ...

In German we have a saying:
  Viele Koeche verderben den Brei
which, straighforward translated, leads to:
  Too many cooks spoil the menu

So the challenge for Frank is to really well coordinate all the
efforts, and find the appropriate delegate/control balance. This is
difficult, IMHO. Let's support him as much as we can!

Best wishes,
Oti


PS:

Since I am >= 100% employed, and member of a family, Jython developer
time is relatively short for me.

On 4/1/06, Walter Chang <[hidden email]> wrote:
> Thanks Oti...
>
> What do you think of the recent activity?
>
> :)


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmdlnk&amp;kid%110944&amp;bid$1720&amp;dat%121642" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/jython-dev

Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Ray Djajadinata
Hi Yan Weng,

> I was a Jython user and am working for a company bigger than BEA. I still like Jython and hope to use it in our production system. However, I
> do have similar concern as Walter has on jython project's current status.

My company is not a very big one. But yeah, Jython project's current status had swayed the decision from Jython to--of all things!--Groovy. IMO it's a bit hasty a choice, Groovy itself hasn't even reached a final release, but yes, the perceived "death" of Jython scared people away.

> Back to the the "management" topic. Personally, I believe introducing some management, or organization, to Jython project will actually do
> more good than bad.

Agreed. Too much management is always bad. I just finished reading mini-Microsoft blog where people are complaining that Windows Vista developers spend 90% time on process and 10% on actually doing development! However, *some* management is obviously going to be useful.

Of course, this is open source, and everybody is doing this by their own volition, so it's not like there's any "manager" or "boss" to which anyone is accountable to here. But everyone is accountable to Jython, and if there's a way to make Jython better... why not?

> Several suggestions to the dev team:
> 1. Make Frank's mock up site page official. It has been more than two months when I heard "really close" to launch the new site page last time.
> If some link in the page doesn't work, just remove it. We can always add it later.

I second this 100%. The website is looking great, Frank has done a great job. Would be great to see it going live soon :)

> 2. Create a  feature list and assign priorities. Volunteers  still can pick up whatever tasks they are interested. But at least they know which task
> can benefit the community most before choosing the task.

Yeah, this too. Is the PyXML task still pending, btw? I mean, if not mistaken PyXML was about to be included merely for compatibility reasons? If that's the only reason maybe it's OK to break this compatibility? PyXML doesn't look very much maintained anymore these days...

Warm regards,
Ray
Reply | Threaded
Open this post in threaded view
|

RE: subversion migration

cupdike
In reply to this post by fwierzbicki@gmail.com
> Can we get a list of users that have commit access, sort of
> get an feeling who our "upperclassmen" are ?
>
> It would be interesting to see what their views on the recent
> feedback are...
>


Walter-

I'm not sure exactly what you're looking for comment on,
but if you'll excuse the long winded and personalized
account, here's a chronology of my experience as a contributor
to jython with some commentary/feedback interspersed
(caveat: these comments are based on the project as it
was circa June 05 when I last did active development):  

"Jython... A Developer's Story" ;-)

My work on the jython project was my first (and only to-date)
experience doing open source development.  In other words, I
was relatively new to cvs, ant, patches, branching,
project contribution "protocol", etc.  But I felt I had
something to offer, so I rolled up my sleeves and jumped
in.  <comment>So I think it is important to encourage people
to jump in if they have something to offer.  Of course,
you have to balance that to some extent, because managing
and guiding new developers takes effort--nothing is free.
</comment>.  Another motivation was that my company had
been using jython in production for a while.  I'd
broached the subject of my company making some kind of
monetary contribution to the project, but it didn't go
over.  <comment>Sadly, I think this is a pervasive attitude.
Companies will pay big bucks to commercial vendors but
perhaps don't see the ROI in supporting something they
can get "for free".</comment>  Well, if my company won't
do it, I'll go it alone...

So I got involved and signed up for the collections
integration.  I enrolled in the "school of hard knocks":
http://mail.python.org/pipermail/python-dev/2002-September/028725.html
And I took my lumps asking the occasional stupid question
or doing the wrong thing.  Brian Zimmer was the project
lead at the time.  He was very encouraging and helpful
(thanks Brian!).  <comment.So that's a quality you probably
need in a project lead--good at mentoring, willing to suffer
idiots well ;-), can keep a lot of activities coordinated
and nurse them along, able to leap tall buildings in a
single bound.  One of the issues that came up recently
I believe was related to "could the project benefit from
a project manager (that was not necessarily a developer)?"
I think it is possible, but that such a manager would
need a technical go-to and that the two would have to
work closely together.</comment>

I discussed design alternatives for the collections
integration with Brian and we'd occasionally tap Samuele
Pedroni.  <comment>Samuele is our connection with the
past--providing invaluable insight and often able to
explain why artifacts of the design are what the way the are.  
But he's quite busy with PyPy  so we are thankful that he still
"keeps in touch" and monitors the list.</comment>.

Okay, I've got an approved approach--time to start coding.
So I start setting up my development environment for 2.2.  It
was a bit difficult--partly because I had not worked with this
kind of toolset/project structure--but also because of a lack
of documentation on how to do it.  I think that's been remedied
somewhat by http://wiki.python.org/jython/JythonDeveloperGuide
<question>Have people been following these steps and do they
work as advertised?  Can they be improved?</question>  I thought
that I should be following a fairly straightforward recipe at
the time, but I felt like I had to invent stuff to get it
up and working--maybe it was just me, maybe there's room
for improvement.

Then I tried to get the unit test to run.  I don't remember
all the details, but I remember being bewildered.  I remember
lots of tests were broken and it seemed like there were different
ways you could run unit tests and you'd end up with different
results.  There were several different types of unit tests
(py unit, test_descr, ad hoc), and there were several different
test directories involved including the "external" cpython tests.
There was also an interaction with the way the build script moved
stuff around.  <comment>I know that there is a certain amount
of inherent complexity, and the tests are necessarily
"co-joined at the hip" with our cpython sibling for the forseable
future (but I believe Brian did discuss segregating pure python
test cases from cpython implementation specific tests with some
folks at pycon at one point).  But IMHO the testing
infrastructure could stand some refactoring and pruning
(there some cruft that could be cleaned up).  Based on some email
exchanges I had with Brian, I'm not sure if anyone understands it
all.  It would be nice if the instructions were more
comprehensive--describing how it all hangs together, what type of
tests there are, how to add new tests.  Cruft should be cleaned
out.  Developers should know when they broke something, and when
they haven't.  A refactoring would be a big job--there a lot of
"moving parts" in the test framework(s).  It would be nice to
try to standardize a bit more.  I did put some effort into this,
but it was clear a lot more could be done.</comment>

So now I'm ready to actually try and write some code.  Brian
explained that "the path to becoming a jython developer
starts with submission of a patch (hint: and you might want to
make sure the unit tests pass or provide new unit tests if it
is new functionality)".  So I did my thing and eventually
submitted a patch.  Brian dutifully reviewed it and eventually
committed it.  I had inspired sufficient confidence in Brian
that he offered me committer rights (scary--I could do some
real damage now ;-).  Eventually I was asked to work with/
help out others, and review other patches.

Ultimately, I wound down after the big push to get my stuff
completed on schedule, and started enjoying a full nights
sleep again.  I was planning on taking a few months downtime
and then picking back up again.  Unfortunately, I was overcome
by events at work and stopped actively developing (sigh!).  
But it was definitely a thrill to toil over the collections
integration stuff and eventually get it working and ultimately
committed.  And I have cited the experience in my performance
review where I work (I would hope all companies value their
employees getting involved with open source).  The developers
I have worked with on the jython project are among the best
developers I've ever been involved with.  I look forward to
getting more involved again at some point.

Ok, enough with my story.  Hopefully a prospective developer
would find it interesting/encouraging and get involved.  But
there's a few other issues that didn't come up.  One is the
lack documentation on how jython works at the core.  It's
come up a couple of times before, and I think everyone agrees
it's a good idea--but it's never been produced.  The obvious
reason is that only a handful of people understand the design
down to the metal.  I'm definitely not one of them.  I've
looked over the code but I have a tough time seeing how it
all hangs together from 10,000 feet.  That doesn't mean I
can't be a productive developer.  But it does limit my ability
to really change the "core" of jython--whatever that
means.  So some of the really challenging tasks, like
implementing new style classes, can only be done by one
or two folks, and that's a bottleneck when those folks are
busy.  I'm not sure I could have _ever_ figured out how to
implement new style classes (kudos to Samuele for doing so),
but unless it becomes easier for developers to understand
everything, these bottlenecks will remain.

One other long term goal I've discussed with Frank is
what it would take to eliminate jythonc, to directly
compile to bytecode like groovy.  It seems like jythonc has
become a maintenance liability, and it sure would be
nice to get the capability transparently.  I understand
that there is a method signature ambiguity issue but
there are ways around that.  Also, I believe Frank said
there will be an inherent jythonc incompatibility with
generators--so maybe it will have to happen anyway.

So in closing, I've perhaps aired some dirty laundry,
but don't get me wrong.  There should be nothing preventing
a surge of new developers from getting involved, pushing
2.2 out the door, and revitalizing the project.  Hopefully
I've identified some issues that might make it easier to
bring more developers on in the future.  Get involved,
figure things out, make things better, document for
others in the wiki (don't be afraid to edit what's there).

Thanks to those that patrol the lists--that's a valuable
service to everyone and helps contribute to the sense
that jython is alive and someone is listening--a jython
"dial tone" as it were.

Regards,
Clark

p.s.  I probably could have produced a patch in the
time it took to write this ;-)


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Walter Chang-2
Hi Clark,

This is quite valuable insight...and I thank you very much for taking
the time (the time to submit a patch no less ) to tell your story.

forgive me, but I'd like to summarize...

- We should all go to the wiki and read
http://wiki.python.org/jython/JythonDeveloperGuide,  try it out and
give feedback on where it needs to be improved.

- High Level Design is not clear to us and we should try to get help
and suggestions as to how to get this knowledge. This is very
important as it seems alot of roadblocks can be clarified when we have
this.  Clark has already said he is not privy to this info...is
Samuele the only one who knows (other then Jim Huggin?)

- There is a process of contributing code: write a patch (useing
diff....) --> submitt for review, and eventually getting it committed.

- Getting money from your boss at work for an OSS is hard....but I
think that we can approach it from other angles (eg. contributing
through a 3rd party vendor that we are a big customer of...etc etc...)
 This is hard to do until we figure out for sure what we need on a
"Design" level...it hard to ask for help if you don't know where it's
needed in the software development process.

once again...thanks for your excellent account...

Regards,
Walter

P.S.  Raymond's post is very good to discourage "whiners", but there
must be a genuine problem when 1 of the 5 active developers we have at
jython doesn't have access to some important design information.




On 4/1/06, Updike, Clark <[hidden email]> wrote:

> > Can we get a list of users that have commit access, sort of
> > get an feeling who our "upperclassmen" are ?
> >
> > It would be interesting to see what their views on the recent
> > feedback are...
> >
>
>
> Walter-
>
> I'm not sure exactly what you're looking for comment on,
> but if you'll excuse the long winded and personalized
> account, here's a chronology of my experience as a contributor
> to jython with some commentary/feedback interspersed
> (caveat: these comments are based on the project as it
> was circa June 05 when I last did active development):
>
> "Jython... A Developer's Story" ;-)
>
> My work on the jython project was my first (and only to-date)
> experience doing open source development.  In other words, I
> was relatively new to cvs, ant, patches, branching,
> project contribution "protocol", etc.  But I felt I had
> something to offer, so I rolled up my sleeves and jumped
> in.  <comment>So I think it is important to encourage people
> to jump in if they have something to offer.  Of course,
> you have to balance that to some extent, because managing
> and guiding new developers takes effort--nothing is free.
> </comment>.  Another motivation was that my company had
> been using jython in production for a while.  I'd
> broached the subject of my company making some kind of
> monetary contribution to the project, but it didn't go
> over.  <comment>Sadly, I think this is a pervasive attitude.
> Companies will pay big bucks to commercial vendors but
> perhaps don't see the ROI in supporting something they
> can get "for free".</comment>  Well, if my company won't
> do it, I'll go it alone...
>
> So I got involved and signed up for the collections
> integration.  I enrolled in the "school of hard knocks":
> http://mail.python.org/pipermail/python-dev/2002-September/028725.html
> And I took my lumps asking the occasional stupid question
> or doing the wrong thing.  Brian Zimmer was the project
> lead at the time.  He was very encouraging and helpful
> (thanks Brian!).  <comment.So that's a quality you probably
> need in a project lead--good at mentoring, willing to suffer
> idiots well ;-), can keep a lot of activities coordinated
> and nurse them along, able to leap tall buildings in a
> single bound.  One of the issues that came up recently
> I believe was related to "could the project benefit from
> a project manager (that was not necessarily a developer)?"
> I think it is possible, but that such a manager would
> need a technical go-to and that the two would have to
> work closely together.</comment>
>
> I discussed design alternatives for the collections
> integration with Brian and we'd occasionally tap Samuele
> Pedroni.  <comment>Samuele is our connection with the
> past--providing invaluable insight and often able to
> explain why artifacts of the design are what the way the are.
> But he's quite busy with PyPy  so we are thankful that he still
> "keeps in touch" and monitors the list.</comment>.
>
> Okay, I've got an approved approach--time to start coding.
> So I start setting up my development environment for 2.2.  It
> was a bit difficult--partly because I had not worked with this
> kind of toolset/project structure--but also because of a lack
> of documentation on how to do it.  I think that's been remedied
> somewhat by http://wiki.python.org/jython/JythonDeveloperGuide
> <question>Have people been following these steps and do they
> work as advertised?  Can they be improved?</question>  I thought
> that I should be following a fairly straightforward recipe at
> the time, but I felt like I had to invent stuff to get it
> up and working--maybe it was just me, maybe there's room
> for improvement.
>
> Then I tried to get the unit test to run.  I don't remember
> all the details, but I remember being bewildered.  I remember
> lots of tests were broken and it seemed like there were different
> ways you could run unit tests and you'd end up with different
> results.  There were several different types of unit tests
> (py unit, test_descr, ad hoc), and there were several different
> test directories involved including the "external" cpython tests.
> There was also an interaction with the way the build script moved
> stuff around.  <comment>I know that there is a certain amount
> of inherent complexity, and the tests are necessarily
> "co-joined at the hip" with our cpython sibling for the forseable
> future (but I believe Brian did discuss segregating pure python
> test cases from cpython implementation specific tests with some
> folks at pycon at one point).  But IMHO the testing
> infrastructure could stand some refactoring and pruning
> (there some cruft that could be cleaned up).  Based on some email
> exchanges I had with Brian, I'm not sure if anyone understands it
> all.  It would be nice if the instructions were more
> comprehensive--describing how it all hangs together, what type of
> tests there are, how to add new tests.  Cruft should be cleaned
> out.  Developers should know when they broke something, and when
> they haven't.  A refactoring would be a big job--there a lot of
> "moving parts" in the test framework(s).  It would be nice to
> try to standardize a bit more.  I did put some effort into this,
> but it was clear a lot more could be done.</comment>
>
> So now I'm ready to actually try and write some code.  Brian
> explained that "the path to becoming a jython developer
> starts with submission of a patch (hint: and you might want to
> make sure the unit tests pass or provide new unit tests if it
> is new functionality)".  So I did my thing and eventually
> submitted a patch.  Brian dutifully reviewed it and eventually
> committed it.  I had inspired sufficient confidence in Brian
> that he offered me committer rights (scary--I could do some
> real damage now ;-).  Eventually I was asked to work with/
> help out others, and review other patches.
>
> Ultimately, I wound down after the big push to get my stuff
> completed on schedule, and started enjoying a full nights
> sleep again.  I was planning on taking a few months downtime
> and then picking back up again.  Unfortunately, I was overcome
> by events at work and stopped actively developing (sigh!).
> But it was definitely a thrill to toil over the collections
> integration stuff and eventually get it working and ultimately
> committed.  And I have cited the experience in my performance
> review where I work (I would hope all companies value their
> employees getting involved with open source).  The developers
> I have worked with on the jython project are among the best
> developers I've ever been involved with.  I look forward to
> getting more involved again at some point.
>
> Ok, enough with my story.  Hopefully a prospective developer
> would find it interesting/encouraging and get involved.  But
> there's a few other issues that didn't come up.  One is the
> lack documentation on how jython works at the core.  It's
> come up a couple of times before, and I think everyone agrees
> it's a good idea--but it's never been produced.  The obvious
> reason is that only a handful of people understand the design
> down to the metal.  I'm definitely not one of them.  I've
> looked over the code but I have a tough time seeing how it
> all hangs together from 10,000 feet.  That doesn't mean I
> can't be a productive developer.  But it does limit my ability
> to really change the "core" of jython--whatever that
> means.  So some of the really challenging tasks, like
> implementing new style classes, can only be done by one
> or two folks, and that's a bottleneck when those folks are
> busy.  I'm not sure I could have _ever_ figured out how to
> implement new style classes (kudos to Samuele for doing so),
> but unless it becomes easier for developers to understand
> everything, these bottlenecks will remain.
>
> One other long term goal I've discussed with Frank is
> what it would take to eliminate jythonc, to directly
> compile to bytecode like groovy.  It seems like jythonc has
> become a maintenance liability, and it sure would be
> nice to get the capability transparently.  I understand
> that there is a method signature ambiguity issue but
> there are ways around that.  Also, I believe Frank said
> there will be an inherent jythonc incompatibility with
> generators--so maybe it will have to happen anyway.
>
> So in closing, I've perhaps aired some dirty laundry,
> but don't get me wrong.  There should be nothing preventing
> a surge of new developers from getting involved, pushing
> 2.2 out the door, and revitalizing the project.  Hopefully
> I've identified some issues that might make it easier to
> bring more developers on in the future.  Get involved,
> figure things out, make things better, document for
> others in the wiki (don't be afraid to edit what's there).
>
> Thanks to those that patrol the lists--that's a valuable
> service to everyone and helps contribute to the sense
> that jython is alive and someone is listening--a jython
> "dial tone" as it were.
>
> Regards,
> Clark
>
> p.s.  I probably could have produced a patch in the
> time it took to write this ;-)
>


--
Simplicity--the art of maximizing the amount
of work not done--is essential.
from: http://www.agilemanifesto.org/principles.html


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

RE: subversion migration

cupdike
In reply to this post by fwierzbicki@gmail.com
> forgive me, but I'd like to summarize...
>
> - We should all go to the wiki and read
> http://wiki.python.org/jython/JythonDeveloperGuide,  try it
> out and give feedback on where it needs to be improved.

Yes.  Although it sounds like with the reorg Frank is doing
those instructions may be changing.  Ideally, the process
is straightforward and reasonably bullet proof, even to people
new to this kind of environment.  

And your summary didn't mention the testing issues--which I
think are also quite important.  I burned way more cycles trying
to understand the testing than I did the build.

> - High Level Design is not clear to us and we should try to
> get help and suggestions as to how to get this knowledge.
> This is very important as it seems alot of roadblocks can be
> clarified when we have this.  Clark has already said he is
> not privy to this info...is Samuele the only one who knows
> (other then Jim Huggin?)

I don't mean to sell anyone else short.  Maybe Frank or others
could have tackled new style classes and such.  I just know
I never understood the core and frequently wished there was
a "trail map" to look at.  I'm sure some people can dig through
the code and figure it all out--but even a small amount of
documentation would make it easier for everyone.

> - There is a process of contributing code: write a patch (useing
> diff....) --> submitt for review, and eventually getting it committed.

There's a couple of processes involved:
> patch submission
> bug reporting
> bug fixing
> development on a branch
> others I'm not even aware of

There's a right way and many wrong ways to do them, and it
involves the sourceforge functionality.  It's not rocket
science--but you'd think this would all be spelled out
somewhere since there's so many sourceforge projects.  At
least when I was getting involved, I never found anything
that explained it all.  Maybe there's better resources now.  
When should a bugs status be changed to fixed?  When should
it be changed to closed?  Maybe someone that knows this stuff
well from other project work could document it on the wiki.

> - Getting money from your boss at work for an OSS is
> hard....but I think that we can approach it from other angles
> (eg. contributing through a 3rd party vendor that we are a
> big customer of...etc etc...)  This is hard to do until we
> figure out for sure what we need on a "Design" level...it
> hard to ask for help if you don't know where it's needed in
> the software development process.

There's probably no substitute for people just rolling up
their sleeves and diving in anyway.  Money might potentially
just mess things for some of the reasons already mentioned
on the list.

> once again...thanks for your excellent account...

I've just been waiting for the right moment to jump in :-)

> Regards,
> Walter
>
> P.S.  Raymond's post is very good to discourage "whiners",
> but there must be a genuine problem when 1 of the 5 active
> developers we have at jython doesn't have access to some
> important design information.

"doesn't have access" is more like "doesn't know" or
"couldn't figure out for himself".  And as I mentioned,
there is plenty that one can contribute without knowing
the "core".

Lastly, I regrettably made it sound like I was the only one that
did the collections integration work--it was most definitely a
multi-person effort.  Brian Zimmer did the set stuff, I was only
helping Mike Garcia on the dictionary implementation, and Andrew
Howard was a big help with making PyArray align with Python 2.4,
and Samuele was always willing to weigh in with advice.  Thanks
to everyone involved.

-Clark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

méchoui
Hi,

I would like to react to the testing issue, and to propose sg.

(Please forgive me if it's not accurate, I admit I did not even downloaded the Jython sources)

I think that whatever the testing framework, the project should be able to be downloaded, compiled, tested ...in just a few clicks. The idea is that when a new developer comes, it must be very easy to start; otherwise the time it takes to understand how it works stops most of us.

If you can have your project "mavenized", it would be great. Download it, "maven eclipse" it (if you use Eclipse) and your Eclipse project is set, "maven test" it and it is compiled / tested. You can start coding, every dependent jar is downloaded, the project configuration is OK, etc, etc.

If you can do that, I'll try to have my company put several integration environments, at least Solaris, Linux and Windows, may be others (Tru64, HP-UX, AIX). They would d/l, compile, test and send emails to a predefined list of users each time sg is commited on the code. The biggest issue is about security, so I need to see how I could have the code be tested without beeing able to access any company's resource. That's the only problem, but it is such a big one...

About the framework which should be used to create the test... well, several things :

- First, I prefer TestNG, and this is a framework we know
- Second, JUnit is OK, but has so many restrictions...
...these two framework make readable reports, and that's the only thing that counts : being able to understand quickly what works/does not work.

- but I can also give help to create Jython tests that can be run by the TestNG or Junit framework. It is important because it gives you the ability to take the power of testNG or Junit tests/reports, and to write your tests in your prefered language (Jython, anybody ?). I work on a project which enables this (Yactu).

Just my 2 cents,

Laurent

(Clark, sorry for the 2 emails...)

On 4/2/06, Updike, Clark <[hidden email]> wrote:
> forgive me, but I'd like to summarize...
>
> - We should all go to the wiki and read
> http://wiki.python.org/jython/JythonDeveloperGuide,  try it
> out and give feedback on where it needs to be improved.

Yes.  Although it sounds like with the reorg Frank is doing
those instructions may be changing.  Ideally, the process
is straightforward and reasonably bullet proof, even to people
new to this kind of environment.

And your summary didn't mention the testing issues--which I
think are also quite important.  I burned way more cycles trying
to understand the testing than I did the build.

> - High Level Design is not clear to us and we should try to
> get help and suggestions as to how to get this knowledge.
> This is very important as it seems alot of roadblocks can be
> clarified when we have this.  Clark has already said he is
> not privy to this info...is Samuele the only one who knows
> (other then Jim Huggin?)

I don't mean to sell anyone else short.  Maybe Frank or others
could have tackled new style classes and such.  I just know
I never understood the core and frequently wished there was
a "trail map" to look at.  I'm sure some people can dig through
the code and figure it all out--but even a small amount of
documentation would make it easier for everyone.

> - There is a process of contributing code: write a patch (useing
> diff....) --> submitt for review, and eventually getting it committed.

There's a couple of processes involved:
> patch submission
> bug reporting
> bug fixing
> development on a branch
> others I'm not even aware of

There's a right way and many wrong ways to do them, and it
involves the sourceforge functionality.  It's not rocket
science--but you'd think this would all be spelled out
somewhere since there's so many sourceforge projects.  At
least when I was getting involved, I never found anything
that explained it all.  Maybe there's better resources now.
When should a bugs status be changed to fixed?  When should
it be changed to closed?  Maybe someone that knows this stuff
well from other project work could document it on the wiki.

> - Getting money from your boss at work for an OSS is
> hard....but I think that we can approach it from other angles
> (eg. contributing through a 3rd party vendor that we are a
> big customer of...etc etc...)  This is hard to do until we
> figure out for sure what we need on a "Design" level...it
> hard to ask for help if you don't know where it's needed in
> the software development process.

There's probably no substitute for people just rolling up
their sleeves and diving in anyway.  Money might potentially
just mess things for some of the reasons already mentioned
on the list.

> once again...thanks for your excellent account...

I've just been waiting for the right moment to jump in :-)

> Regards,
> Walter
>
> P.S.  Raymond's post is very good to discourage "whiners",
> but there must be a genuine problem when 1 of the 5 active
> developers we have at jython doesn't have access to some
> important design information.

"doesn't have access" is more like "doesn't know" or
"couldn't figure out for himself".  And as I mentioned,
there is plenty that one can contribute without knowing
the "core".

Lastly, I regrettably made it sound like I was the only one that
did the collections integration work--it was most definitely a
multi-person effort.  Brian Zimmer did the set stuff, I was only
helping Mike Garcia on the dictionary implementation, and Andrew
Howard was a big help with making PyArray align with Python 2.4,
and Samuele was always willing to weigh in with advice.  Thanks
to everyone involved.

-Clark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmdlnk&amp;kid0944&amp;bid$1720&amp;dat1642"> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

Yan Weng
About maven: I did an initial port Jython to Maven2 about 2 months ago. If you are interested in it, contact me.
About testing: Jython only has few junit tests. Others are python based tests.

- Yan

On 4/2/06, Laurent Ploix <[hidden email]> wrote:
Hi,

I would like to react to the testing issue, and to propose sg.

(Please forgive me if it's not accurate, I admit I did not even downloaded the Jython sources)

I think that whatever the testing framework, the project should be able to be downloaded, compiled, tested ...in just a few clicks. The idea is that when a new developer comes, it must be very easy to start; otherwise the time it takes to understand how it works stops most of us.

If you can have your project "mavenized", it would be great. Download it, "maven eclipse" it (if you use Eclipse) and your Eclipse project is set, "maven test" it and it is compiled / tested. You can start coding, every dependent jar is downloaded, the project configuration is OK, etc, etc.

If you can do that, I'll try to have my company put several integration environments, at least Solaris, Linux and Windows, may be others (Tru64, HP-UX, AIX). They would d/l, compile, test and send emails to a predefined list of users each time sg is commited on the code. The biggest issue is about security, so I need to see how I could have the code be tested without beeing able to access any company's resource. That's the only problem, but it is such a big one...

About the framework which should be used to create the test... well, several things :

- First, I prefer TestNG, and this is a framework we know
- Second, JUnit is OK, but has so many restrictions...
...these two framework make readable reports, and that's the only thing that counts : being able to understand quickly what works/does not work.

- but I can also give help to create Jython tests that can be run by the TestNG or Junit framework. It is important because it gives you the ability to take the power of testNG or Junit tests/reports, and to write your tests in your prefered language (Jython, anybody ?). I work on a project which enables this (Yactu).

Just my 2 cents,

Laurent

(Clark, sorry for the 2 emails...)


On 4/2/06, Updike, Clark <[hidden email]> wrote:
> forgive me, but I'd like to summarize...
>
> - We should all go to the wiki and read
> <a href="http://wiki.python.org/jython/JythonDeveloperGuide" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.python.org/jython/JythonDeveloperGuide ,  try it
> out and give feedback on where it needs to be improved.

Yes.  Although it sounds like with the reorg Frank is doing
those instructions may be changing.  Ideally, the process
is straightforward and reasonably bullet proof, even to people
new to this kind of environment.

And your summary didn't mention the testing issues--which I
think are also quite important.  I burned way more cycles trying
to understand the testing than I did the build.

> - High Level Design is not clear to us and we should try to
> get help and suggestions as to how to get this knowledge.
> This is very important as it seems alot of roadblocks can be
> clarified when we have this.  Clark has already said he is
> not privy to this info...is Samuele the only one who knows
> (other then Jim Huggin?)

I don't mean to sell anyone else short.  Maybe Frank or others
could have tackled new style classes and such.  I just know
I never understood the core and frequently wished there was
a "trail map" to look at.  I'm sure some people can dig through
the code and figure it all out--but even a small amount of
documentation would make it easier for everyone.

> - There is a process of contributing code: write a patch (useing
> diff....) --> submitt for review, and eventually getting it committed.

There's a couple of processes involved:
> patch submission
> bug reporting
> bug fixing
> development on a branch
> others I'm not even aware of

There's a right way and many wrong ways to do them, and it
involves the sourceforge functionality.  It's not rocket
science--but you'd think this would all be spelled out
somewhere since there's so many sourceforge projects.  At
least when I was getting involved, I never found anything
that explained it all.  Maybe there's better resources now.
When should a bugs status be changed to fixed?  When should
it be changed to closed?  Maybe someone that knows this stuff
well from other project work could document it on the wiki.

> - Getting money from your boss at work for an OSS is
> hard....but I think that we can approach it from other angles
> (eg. contributing through a 3rd party vendor that we are a
> big customer of...etc etc...)  This is hard to do until we
> figure out for sure what we need on a "Design" level...it
> hard to ask for help if you don't know where it's needed in
> the software development process.

There's probably no substitute for people just rolling up
their sleeves and diving in anyway.  Money might potentially
just mess things for some of the reasons already mentioned
on the list.

> once again...thanks for your excellent account...

I've just been waiting for the right moment to jump in :-)

> Regards,
> Walter
>
> P.S.  Raymond's post is very good to discourage "whiners",
> but there must be a genuine problem when 1 of the 5 active
> developers we have at jython doesn't have access to some
> important design information.

"doesn't have access" is more like "doesn't know" or
"couldn't figure out for himself".  And as I mentioned,
there is plenty that one can contribute without knowing
the "core".

Lastly, I regrettably made it sound like I was the only one that
did the collections integration work--it was most definitely a
multi-person effort.  Brian Zimmer did the set stuff, I was only
helping Mike Garcia on the dictionary implementation, and Andrew
Howard was a big help with making PyArray align with Python 2.4,
and Samuele was always willing to weigh in with advice.  Thanks
to everyone involved.

-Clark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmdlnk&amp;kid%110944&amp;bid$1720&amp;dat%121642" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/jython-dev


Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

méchoui
Hi,

I (almost) know how to run python / jython / java tests in a single TestNG or Junit report. In fact, I have an old project that just did that, and I'm currently refactoring (). It is very useful when you need to unit test a project which is made of several technologies.

So I could be able to run your python tests either.

Bye,

Laurent

On 4/2/06, Yan Weng <[hidden email]> wrote:
About maven: I did an initial port Jython to Maven2 about 2 months ago. If you are interested in it, contact me.
About testing: Jython only has few junit tests. Others are python based tests.

- Yan


On 4/2/06, Laurent Ploix <[hidden email]> wrote:
Hi,

I would like to react to the testing issue, and to propose sg.

(Please forgive me if it's not accurate, I admit I did not even downloaded the Jython sources)

I think that whatever the testing framework, the project should be able to be downloaded, compiled, tested ...in just a few clicks. The idea is that when a new developer comes, it must be very easy to start; otherwise the time it takes to understand how it works stops most of us.

If you can have your project "mavenized", it would be great. Download it, "maven eclipse" it (if you use Eclipse) and your Eclipse project is set, "maven test" it and it is compiled / tested. You can start coding, every dependent jar is downloaded, the project configuration is OK, etc, etc.

If you can do that, I'll try to have my company put several integration environments, at least Solaris, Linux and Windows, may be others (Tru64, HP-UX, AIX). They would d/l, compile, test and send emails to a predefined list of users each time sg is commited on the code. The biggest issue is about security, so I need to see how I could have the code be tested without beeing able to access any company's resource. That's the only problem, but it is such a big one...

About the framework which should be used to create the test... well, several things :

- First, I prefer TestNG, and this is a framework we know
- Second, JUnit is OK, but has so many restrictions...
...these two framework make readable reports, and that's the only thing that counts : being able to understand quickly what works/does not work.

- but I can also give help to create Jython tests that can be run by the TestNG or Junit framework. It is important because it gives you the ability to take the power of testNG or Junit tests/reports, and to write your tests in your prefered language (Jython, anybody ?). I work on a project which enables this (Yactu).

Just my 2 cents,

Laurent

(Clark, sorry for the 2 emails...)


On 4/2/06, Updike, Clark <[hidden email]> wrote:
> forgive me, but I'd like to summarize...
>
> - We should all go to the wiki and read
> <a href="http://wiki.python.org/jython/JythonDeveloperGuide" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://wiki.python.org/jython/JythonDeveloperGuide ,  try it
> out and give feedback on where it needs to be improved.

Yes.  Although it sounds like with the reorg Frank is doing
those instructions may be changing.  Ideally, the process
is straightforward and reasonably bullet proof, even to people
new to this kind of environment.

And your summary didn't mention the testing issues--which I
think are also quite important.  I burned way more cycles trying
to understand the testing than I did the build.

> - High Level Design is not clear to us and we should try to
> get help and suggestions as to how to get this knowledge.
> This is very important as it seems alot of roadblocks can be
> clarified when we have this.  Clark has already said he is
> not privy to this info...is Samuele the only one who knows
> (other then Jim Huggin?)

I don't mean to sell anyone else short.  Maybe Frank or others
could have tackled new style classes and such.  I just know
I never understood the core and frequently wished there was
a "trail map" to look at.  I'm sure some people can dig through
the code and figure it all out--but even a small amount of
documentation would make it easier for everyone.

> - There is a process of contributing code: write a patch (useing
> diff....) --> submitt for review, and eventually getting it committed.

There's a couple of processes involved:
> patch submission
> bug reporting
> bug fixing
> development on a branch
> others I'm not even aware of

There's a right way and many wrong ways to do them, and it
involves the sourceforge functionality.  It's not rocket
science--but you'd think this would all be spelled out
somewhere since there's so many sourceforge projects.  At
least when I was getting involved, I never found anything
that explained it all.  Maybe there's better resources now.
When should a bugs status be changed to fixed?  When should
it be changed to closed?  Maybe someone that knows this stuff
well from other project work could document it on the wiki.

> - Getting money from your boss at work for an OSS is
> hard....but I think that we can approach it from other angles
> (eg. contributing through a 3rd party vendor that we are a
> big customer of...etc etc...)  This is hard to do until we
> figure out for sure what we need on a "Design" level...it
> hard to ask for help if you don't know where it's needed in
> the software development process.

There's probably no substitute for people just rolling up
their sleeves and diving in anyway.  Money might potentially
just mess things for some of the reasons already mentioned
on the list.

> once again...thanks for your excellent account...

I've just been waiting for the right moment to jump in :-)

> Regards,
> Walter
>
> P.S.  Raymond's post is very good to discourage "whiners",
> but there must be a genuine problem when 1 of the 5 active
> developers we have at jython doesn't have access to some
> important design information.

"doesn't have access" is more like "doesn't know" or
"couldn't figure out for himself".  And as I mentioned,
there is plenty that one can contribute without knowing
the "core".

Lastly, I regrettably made it sound like I was the only one that
did the collections integration work--it was most definitely a
multi-person effort.  Brian Zimmer did the set stuff, I was only
helping Mike Garcia on the dictionary implementation, and Andrew
Howard was a big help with making PyArray align with Python 2.4,
and Samuele was always willing to weigh in with advice.  Thanks
to everyone involved.

-Clark


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmdlnk&amp;kid%110944&amp;bid$1720&amp;dat%121642" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
<a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.sourceforge.net/lists/listinfo/jython-dev



Reply | Threaded
Open this post in threaded view
|

Re: subversion migration

fwierzbicki@gmail.com
In reply to this post by fwierzbicki@gmail.com
I've submitted the sourceforge job to migrate the cvs data to
subversion to.  I have a backup of the cvs nightly tarball just in
case, but the directions say that cvs should not be touched.  The
directions also say that it should take 1-3 hours unless there are a
bunch of projects queued up before me, in which case in could take up
to 24 hours.  I'll send another email when I know it is done.

On 3/31/06, Frank Wierzbicki <[hidden email]> wrote:

> All,
>
> I'm going to try to test out the sourceforge subversion migration tool
> next weekend (April 8-9).  If the test goes absolutely perfectly, I
> will be considering calling the result the new official repository.
> The current CVS repository should not be changed at all (I'll back it
> up just in case) so if the tool does not yield a perfect result, then
> this move may need to be put off.
>
> The important thing is: I'd like any commiters that are sitting on any
> changes they would like to get in, to please finish up and get them
> into CVS by next Friday (April 7).
>
> Thanks,
>
> -Frank
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev