Hi,
> Since I'm on this list (less than a year) I regularly observed
> lots of resistance with respect to any changes of workflow. This
> can be either due to bad suggestions for improvement, or due to
> the emerge of an overly conservative development culture. I'm
On Sun, Feb 3, 2013 at 1:38 PM, Matthew Knepley wrote:
> On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp wrote:
>
>> Hi Matt,
>>
>>
>> > ---
>>
>>> 'I don't think there is any
>>>
>>> evidence that it increases productivity, and quite a lot that it is
>>> rather marginal on that score
On Sun, Feb 3, 2013 at 2:04 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 12:29 PM, Karl Rupp wrote:
>
>> New developers are usually willing to adapt to the workflow of the
>> project anyways, particularly if it follows established 'best practices'.
>> 'Compile cleanly at high warning levels'
On Sun, Feb 3, 2013 at 1:29 PM, Karl Rupp wrote:
> Hi Matt,
>
>
> > ---
>
>> 'I don't think there is any
>>
>> evidence that it increases productivity, and quite a lot that it is
>> rather marginal on that score while increasing development
>> costs. I do not see any effect fr
On Sun, Feb 3, 2013 at 12:38 PM, Matthew Knepley wrote:
> I was not being flippant here, but noting that the baseline is the current
> system which is being criticized.
>
I outlined many ways in which organizing patches for reviewability and
feature-provenance is a good thing. You have essential
On Sun, Feb 3, 2013 at 12:59 PM, Karl Rupp wrote:
> Hi Matt,
>
>
> On 02/03/2013 11:37 AM, Matthew Knepley wrote:
>
>>
>> +1 for Sean. I'm tired of carefully writing down the points I'm
>> trying to make, carefully (re-)reading through what I've written,
>> and then just to get a gene
On Sun, Feb 3, 2013 at 12:29 PM, Karl Rupp wrote:
> New developers are usually willing to adapt to the workflow of the project
> anyways, particularly if it follows established 'best practices'. 'Compile
> cleanly at high warning levels' is one of them, so we are not proposing
> something radical
On Sun, Feb 3, 2013 at 12:49 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:31 AM, Matthew Knepley wrote:
>
>> How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do
>>> your work in a bookmark and merge it when it's ready for review. It's not a
>>> hard concept.
>>>
>>
>> It
On Sun, Feb 3, 2013 at 12:32 PM, Karl Rupp wrote:
> On 02/03/2013 11:25 AM, Sean Farley wrote:
>
>> On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley
>> wrote:
>>
>>> On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote:
>>>
On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley
wrote
On Sun, Feb 3, 2013 at 12:31 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:23 AM, Matthew Knepley wrote:
>
>> How do you identify what the feature is when it's in 10 commits
>>> interspersed over 200 in the history. My claim is that you should make
>>> those 10 commits on top of each other w
On Sun, Feb 3, 2013 at 12:24 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley wrote:
>
>> Its more work for me. Clearly you are asking me to do something I do not
>> currently do. A loss.
>>
>
> How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do your
>
On Sun, Feb 3, 2013 at 12:27 PM, Sean Farley wrote:
> On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley
> wrote:
> >
> >>
> >> Pushing as a checkpointing mechanism discourages review.
> >
> >
> > Review should happend when the section is complete, but this is no way
> > implies that you should no
Hi Matt,
> ---
> 'I don't think there is any
>
> evidence that it increases productivity, and quite a lot that it is
> rather marginal on that score while increasing development
> costs. I do not see any effect from these kind of pushes. Does that
> mean my workflow is mor
On Sun, Feb 3, 2013 at 12:01 PM, Matthew Knepley wrote:
> http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
>>
>
> Notice here that "Informal code review" is the second worst form of
> checking by percentage of bugs
> found, and thus would appear to be an inefficient way to go
On Sun, Feb 3, 2013 at 12:20 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley wrote:
>
>> I did address. It would be great if people never pushed warnings. I try
>> not to.
>>
>
> You push new warnings almost every day.
>
Hyperbole does not serve rational argument.
>
>
On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley wrote:
>
>> Can you quantify your productivity gains that come from pushing
>>> checkpoints instead of waiting for a semantically meaningful point to merge
>>> and push?
>>>
>>
>> I can quantify
On Sun, Feb 3, 2013 at 12:14 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 11:09 AM, Matthew Knepley wrote:
>
>> If the checkin you originally complained about the build did not fail and
>> a memory leak did not appear. You
>> still cannot explain what was wrong there, so you proceed to a diffe
On Sun, Feb 3, 2013 at 12:09 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 9:58 AM, Matthew Knepley wrote:
>
>> It is not the current workflow that must be justified, but a mandatory
>> change in that workflow. I don't think there is any
>> evidence that it increases productivity, and quite a
On Sun, Feb 3, 2013 at 12:02 PM, Jed Brown wrote:
>
> On Sun, Feb 3, 2013 at 9:35 AM, Matthew Knepley wrote:
>
>> Again, you misuse words when it is convenient for you. This is dishonest
>> argument.
>>
>> "Stable" for applications means that the behavior of the application will
>> not change. T
On Sun, Feb 3, 2013 at 11:37 AM, Matthew Knepley wrote:
> It is burdensome to cordon off work into separate channels, which may have
> to be updated between them. And
> you can say that VC has features to do this, which is true, but it is
> simply wrong to assert that they entail no cost.
> You c
Hi Matt,
On 02/03/2013 11:37 AM, Matthew Knepley wrote:
>
> +1 for Sean. I'm tired of carefully writing down the points I'm
> trying to make, carefully (re-)reading through what I've written,
> and then just to get a generic 'how does this relate to XYZ'-type of
> answer without re
On Sun, Feb 3, 2013 at 11:31 AM, Matthew Knepley wrote:
> How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do your
>> work in a bookmark and merge it when it's ready for review. It's not a hard
>> concept.
>>
>
> It is clearly more work.
>
How so? Every (non-science) open sourc
On 02/03/2013 11:25 AM, Sean Farley wrote:
> On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley wrote:
>> On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote:
>>>
>>>
>>> On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley
>>> wrote:
>
> Can you quantify your productivity gains that come from pu
On Sun, Feb 3, 2013 at 11:23 AM, Matthew Knepley wrote:
> How do you identify what the feature is when it's in 10 commits
>> interspersed over 200 in the history. My claim is that you should make
>> those 10 commits on top of each other without merging (unless you need
>> sometIhing specific that
On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley wrote:
>
>>
>> Pushing as a checkpointing mechanism discourages review.
>
>
> Review should happend when the section is complete, but this is no way
> implies that you should not push until it is complete.
There seems to be a misunderstanding: You
On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley wrote:
> On Sun, Feb 3, 2013 at 12:16 PM, Jed Brown wrote:
>>
>>
>> On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley
>> wrote:
Can you quantify your productivity gains that come from pushing
checkpoints instead of waiting for a sema
On Sun, Feb 3, 2013 at 11:17 AM, Matthew Knepley wrote:
> Its more work for me. Clearly you are asking me to do something I do not
> currently do. A loss.
>
How is _not typing 'hg merge' or 'hg pull'_ harder than typing it? Do your
work in a bookmark and merge it when it's ready for review. It's
On Sun, Feb 3, 2013 at 11:16 AM, Matthew Knepley wrote:
> I did address. It would be great if people never pushed warnings. I try
> not to.
>
You push new warnings almost every day.
>
>
>> Pushing as a checkpointing mechanism discourages review.
>>
>
> Review should happend when the section is
On Sun, Feb 3, 2013 at 11:11 AM, Matthew Knepley wrote:
> Can you quantify your productivity gains that come from pushing
>> checkpoints instead of waiting for a semantically meaningful point to merge
>> and push?
>>
>
> I can quantify the losses from the changed you propose, which is all I
> nee
On Sun, Feb 3, 2013 at 11:09 AM, Matthew Knepley wrote:
> If the checkin you originally complained about the build did not fail and
> a memory leak did not appear. You
> still cannot explain what was wrong there, so you proceed to a different
> problem.
>
Users even write petsc-maint about the w
On Sun, Feb 3, 2013 at 9:58 AM, Matthew Knepley wrote:
> It is not the current workflow that must be justified, but a mandatory
> change in that workflow. I don't think there is any
> evidence that it increases productivity, and quite a lot that it is rather
> marginal on that score while increas
On Sun, Feb 3, 2013 at 9:35 AM, Matthew Knepley wrote:
> Again, you misuse words when it is convenient for you. This is dishonest
> argument.
>
> "Stable" for applications means that the behavior of the application will
> not change. This is
> definitely true for your example, so characterization
On Sat, Feb 2, 2013 at 6:00 PM, Jed Brown wrote:
>
> On Sat, Feb 2, 2013 at 4:38 PM, Matthew Knepley wrote:
>
>> I would love it if people never pushed code with any bugs. This is
>> possible, just not efficient. All changes to
>> workflow should be evaluated on this basis. For this particular c
On Sat, Feb 2, 2013 at 6:44 PM, Jed Brown wrote:
> The other issue is that we work with applications that need to be able to
> rely on their PETSc being stable. If we can provide a 'dev' that is
> relatively stable, we can rapidly deliver new features, which encourages
> them to work more closely
On 2/3/13 12:44 AM, Jed Brown wrote:
> The other issue is that we work with applications that need to be able
> to rely on their PETSc being stable. If we can provide a 'dev' that is
> relatively stable, we can rapidly deliver new features, which
> encourages them to work more closely with us. I
On Sat, Feb 2, 2013 at 6:34 PM, Anton Popov wrote:
> Have you ever tried to compile PETSc with -Wconversion option (or similar)
> switched on?
>
> I just tried it recently with our code, and it completely spammed compiler
> output by the stuff originating from PETSc headers.
> I find this option
On Sat, Feb 2, 2013 at 5:56 PM, Karl Rupp wrote:
> Hi guys,
>
>
> > They issue warnings and the code can't possibly execute correctly.
>
>> Just don't push it (or push it somewhere else) until it's been
>> cleaned up to the point where it's not wasting our time to review.
>>
>>
>> I w
The other issue is that we work with applications that need to be able to
rely on their PETSc being stable. If we can provide a 'dev' that is
relatively stable, we can rapidly deliver new features, which encourages
them to work more closely with us. If 'dev' is volatile, they will only use
releases
On Sat, Feb 2, 2013 at 5:17 PM, Hong Zhang wrote:
> I agree with Matt on this issue.
>
> 'petsc-dev' means 'dev', that a developer should be able to push on-going work
> after he/she does local tests and is willing to fix the warning/bug as soon as
> the problems appear. Personally, I am unable to
On Sat, Feb 2, 2013 at 5:17 PM, Hong Zhang wrote:
> 'petsc-dev' means 'dev', that a developer should be able to push on-going
> work
> after he/she does local tests and is willing to fix the warning/bug as
> soon as
> the problems appear. Personally, I am unable to write a bug/waring free
> code,
On Sat, Feb 2, 2013 at 5:20 PM, Jed Brown wrote:
>
> On Sat, Feb 2, 2013 at 4:14 PM, Matthew Knepley wrote:
>
>> I think non-working is a misnomer here. These do not break the build.
>
>
> They issue warnings and the code can't possibly execute correctly. Just
> don't push it (or push it somewhe
I agree with Matt on this issue.
'petsc-dev' means 'dev', that a developer should be able to push on-going work
after he/she does local tests and is willing to fix the warning/bug as soon as
the problems appear. Personally, I am unable to write a bug/waring free code,
not matter how much effort an
I think non-working is a misnomer here. These do not break the build.
Matt
On Feb 2, 2013 4:23 PM, "Jed Brown" wrote:
> It seems like every time I pull PETSc, I get more build noise from unused
> or uninitialized variables. I have a suggestion: if it's not clean yet,
> just don't push it. If
On Sat, Feb 2, 2013 at 4:38 PM, Matthew Knepley wrote:
> I would love it if people never pushed code with any bugs. This is
> possible, just not efficient. All changes to
> workflow should be evaluated on this basis. For this particular change,
>
> 1) It does not break the build
>
> 2) Its a
Hi guys,
> They issue warnings and the code can't possibly execute correctly.
> Just don't push it (or push it somewhere else) until it's been
> cleaned up to the point where it's not wasting our time to review.
>
>
> I would love it if people never pushed code with any bugs. This is
On Sat, Feb 2, 2013 at 4:14 PM, Matthew Knepley wrote:
> I think non-working is a misnomer here. These do not break the build.
They issue warnings and the code can't possibly execute correctly. Just
don't push it (or push it somewhere else) until it's been cleaned up to the
point where it's not
It seems like every time I pull PETSc, I get more build noise from unused
or uninitialized variables. I have a suggestion: if it's not clean yet,
just don't push it. If you want a backup or to communicate the messy code
with someone else, push it to bitbucket.org/YOURNAME/petsc-dev. Pushing to
pets
47 matches
Mail list logo
