Antoine Pitrou wrote:
> Well, it seems to me that most of these steps are separated by manual
> intervention (e.g. compile and run the test suite to check that everything
> works
> smoothly)
Agreed.
> so there's no real point in making a script out of them.
The idea would be to provide scripts
"Martin v. Löwis" wrote:
> Yes, I'm also quite grateful for the contributions I have received from
> Daniel.
Thank you Martin. I'm sure I'd still be going around in circles if it
weren't for your guidance, and I'd be MIA after the first time I broke
the tracker too. So thanks a lot for the support
Nick Coghlan wrote:
> Everything I've seen from Daniel so far seems to be about either making
> things we already do more efficient, or else providing additional
> features in ways that don't make the tools any more confusing for others
> already used to a particular way of doing things. So he seem
>> P.S. I don't believe your claim that it forgot changesets. Could it be
>> that it simply forgot adding files, and that it did so because you
>> already had the files in the sandbox, so that the merging failed?
>
> It's more weird actually, it actively forgot some changes in some files but
> so
Martin v. Löwis v.loewis.de> writes:
>
> P.S. I don't believe your claim that it forgot changesets. Could it be
> that it simply forgot adding files, and that it did so because you
> already had the files in the sandbox, so that the merging failed?
It's more weird actually, it actively forgot so
Martin v. Löwis wrote:
> P.P.S. Are you sure you have to re-merge when somebody commits
> something unrelated to the branch? Or just when somebody else merges
> as well?
The latter is the only one I've ever had problems with (and that was due
to me forgetting to update before merging rather than s
> The real issues with svnmerge are its occasional bugs or failures (it forgot
> some changesets when merging in the io-c branch!), its slowness, and its
> limitations (which are really inherent to the SVN model: e.g., if someone
> commits to the branch you have just started doing an svnmerge to, y
> Everything I've seen from Daniel so far seems to be about either making
> things we already do more efficient, or else providing additional
> features in ways that don't make the tools any more confusing for others
> already used to a particular way of doing things. So he seems to be
> navigating
2009/3/23 Antoine Pitrou :
> Guilherme Polo gmail.com> writes:
>>
>> Any chance you were not using the latest svnmerge when you did that
>> merge ? I've had problems like this when using older versions.
>
> Well, actually, Benjamin did the merge, so perhaps he can give more info.
I was using the
Guilherme Polo gmail.com> writes:
>
> Any chance you were not using the latest svnmerge when you did that
> merge ? I've had problems like this when using older versions.
Well, actually, Benjamin did the merge, so perhaps he can give more info.
Regards
Antoine.
__
On Mon, Mar 23, 2009 at 5:03 PM, Antoine Pitrou wrote:
>
> Hi,
>
> Daniel (ajax) Diniz gmail.com> writes:
>>
>> But the real point is that, regardless of underlying VCS, there is a
>> choice between "having all core developers know by heart the right
>> switches and order of steps to correctly ch
Hi,
Daniel (ajax) Diniz gmail.com> writes:
>
> But the real point is that, regardless of underlying VCS, there is a
> choice between "having all core developers know by heart the right
> switches and order of steps to correctly checkout/update ->( branch
> locally) -> fix -> diff -> commit -> m
Thanks for the feedback, Antoine!
Antoine Pitrou wrote:
> Daniel (ajax) Diniz gmail.com> writes:
>>
>> Sometimes, non-obvious bits like the right sequence of svnmerge
>> commands, the right way to link a Rietveld code review to a given
>> issue or checking for correct autoconf version might get
Daniel (ajax) Diniz gmail.com> writes:
>
> Sometimes, non-obvious bits like the right sequence of svnmerge
> commands, the right way to link a Rietveld code review to a given
> issue or checking for correct autoconf version might get in the way of
> real development.
Well, really, rather than
C. Titus Brown wrote:
> Given the relative paucity of core Python GSoC ideas, I think you should
> go for both of these, *especially* if you have a mentor up front. So,
> write 'em up, add 'em to the GSoC page, and let's see who we get...
> If we get good applications for both, then I think we can
> Oh, I heartily endorse his suggestions! I just want to make sure that we
> make maximum use of students (and their code doesn't get tossed at the
> end of the summer, which has serious morale consequences ;)
This is my concern as well.
One of my past students pitched a core project and ended u
On Mon, Mar 23, 2009 at 10:26:54PM +1000, Nick Coghlan wrote:
-> C. Titus Brown wrote:
-> > On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote:
-> > I do think you should be prepared for pushback from python-dev on any
-> > such ideas ;). Don't get too ambitious about writing up *
C. Titus Brown wrote:
> On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote:
> I do think you should be prepared for pushback from python-dev on any
> such ideas ;). Don't get too ambitious about writing up *your* way of
> fixing things, but rather make sure you and the students ar
On Sun, Mar 22, 2009 at 07:30:01PM -0300, Daniel (ajax) Diniz wrote:
-> Even if neither is considered worthy, I'll keep them on my to-do list
-> and hope to slowly and hackishly work towards both proposals' goals.
-> Barring feedback saying that they're out of scope, stupid and
-> downright offensi
Hi,
I'd like to bring up the general idea of using a PSF slot in GSoC2009
to improve the Python development infrastructure. I also happen to
have two concrete proposals for that (such a coincidence!). But I
assure you the general idea is more important than my proposals :)
General:
Solving issues
20 matches
Mail list logo
