Thank you for sending this Jason. It's important to not let personal
frustrations spill over into personal attacks, or into what can be viewed
as a personal attack.
Joachim, thank you for your contributions to SymPy and for your input on
this thread. You are of course free to do whatever you want,
Jo,
I've looked over the emails in this thread and I see that I said things
several times that were too personal. I let my irritation and anger get the
best of me. Those instances unfortunately tainted the core message I was
trying to convey and hurt the situation instead of helping it. I apologiz
Am 16.07.2015 um 18:21 schrieb Aaron Meurer:
OK, guys, this thread has reached its end.
Fully agreed.
With 20/20 hindsight, I'd say it did many messages ago.
I'm not going to take 100% responsibility for this, but enough that I
want to offer my apologies.
Regards,
Jo
--
You received this m
OK, guys, this thread has reached its end. If someone has a specific
question or issue about rebasing on a specific pull request, let's discuss
it there.
If someone has any comments or concerns about the side discussion that
Jason and Joachim are having please email me off list.
Aaron Meurer
On
The more you do this, the less
we like you.
Frankly, I do not care whether you like me. I care about code.
Also, I do not believe anybody gave you a mandate to tell me that they
don't like me anymore.
You accuse me of not helping moving stuff forward.
Ironically, you've been bogging this disc
Jo,
Please stop derailing the conversation and answer our questions. In
particular, answer Ondrej's question:
> So this should be our recommendation. Jason already agreed to the above.
Yo and others, do you also agree with the above?
You are so focused on finding minor counter arguments to minor
Am 16.07.2015 um 05:32 schrieb Aaron Meurer:
Also, if you're a habitual rebaser and you have push access, you had better
have your origin remote set to read-only.
Very much agreed.
Maybe not just for habitual rebasers, merging with conflicts can go
wrong, too.
I hope to set up my own project
On Wed, Jul 15, 2015 at 2:45 PM, Joachim Durchholz wrote:
> Am 15.07.2015 um 20:54 schrieb AMiT Kumar:
>
>> Well said, I think, this point won the argument!
>>
>
> Actually it didn't, each sentence is easily refuted:
>
> >> Changing the history of your revisions is detrimental to the open
> >> ph
On Wed, Jul 15, 2015 at 12:46 PM, Jason Moore wrote:
> Yes I agree, if your history is so heinous, and bothers you so much, and you
> really really want to rebase, just make a new PR for pure merging after the
> review is done (or discuss with you reviewers about it). But otherwise it
> doesn't re
Hi,
On Wed, Jul 15, 2015 at 8:45 PM, Joachim Durchholz wrote:
> Am 15.07.2015 um 20:54 schrieb AMiT Kumar:
>>
>> Well said, I think, this point won the argument!
>
>
> Actually it didn't, each sentence is easily refuted:
>
>>> Changing the history of your revisions is detrimental to the open
>>>
Am 15.07.2015 um 20:54 schrieb AMiT Kumar:
Well said, I think, this point won the argument!
Actually it didn't, each sentence is easily refuted:
>> Changing the history of your revisions is detrimental to the open
>> philosophy that you should have when developing in open source.
Open philoso
Am 15.07.2015 um 20:23 schrieb Ondřej Čertík:
I agree with this --- many times there is just a few lines change,
that took 50 commits to get done, because the author was learning how
to make it work.
That too, yes.
For these cases I recommend to send a new PR with a polished (=rebased) histor
> Changing the history of your revisions is detrimental to the open
philosophy that you should have when developing in open source. We should
not be afraid to make
> mistakes, and even have it in a permanent record that we made those
mistakes. Good open source software, certainly SymPy, is buil
Yes I agree, if your history is so heinous, and bothers you so much, and
you really really want to rebase, just make a new PR for pure merging after
the review is done (or discuss with you reviewers about it). But otherwise
it doesn't really matter. For example, if git didn't have a rebase command,
On Sun, Jul 12, 2015 at 2:53 AM, Joachim Durchholz wrote:
> Am 12.07.2015 um 00:17 schrieb Jason Moore:
>>
>> FYI: We had a discussion at SymPy on how to synchronize with master and
>> decided that we no longer want to allow or encourage rebasing after a pull
>> request is made to the main SymPy r
On Tue, Jul 14, 2015 at 10:32 AM, Joachim Durchholz
wrote:
> Am 14.07.2015 um 16:39 schrieb Jason Moore:
>
>> It wasn't ignored, I just don't see it. All I see are detailed agreements
>> or counters to each point that has been mentioned to be negative about
>> rebasing.
>>
>
> Indeed, I misrepres
Am 14.07.2015 um 18:10 schrieb Matthew Brett:
? I've certainly done PRs where I had a set of changes that I had to
rewrite completely on the basis of comments, so that the full history
would have been useless and distracting, and an interactive rebase was
obviously the best way to clean that up.
On Tue, Jul 14, 2015 at 4:32 PM, Joachim Durchholz wrote:
> Am 14.07.2015 um 16:39 schrieb Jason Moore:
>>
>> It wasn't ignored, I just don't see it. All I see are detailed agreements
>> or counters to each point that has been mentioned to be negative about
>> rebasing.
>
>
> Indeed, I misrepresen
Am 14.07.2015 um 16:39 schrieb Jason Moore:
It wasn't ignored, I just don't see it. All I see are detailed agreements
or counters to each point that has been mentioned to be negative about
rebasing.
Indeed, I misrepresented that a bit.
I can't hope to discuss solution details if we don't even a
It wasn't ignored, I just don't see it. All I see are detailed agreements
or counters to each point that has been mentioned to be negative about
rebasing.
Here is my two sentence solution:
Rebasing has enough substantial negative effects on contributions that we'd
like to avoid encouraging it and
Am 14.07.2015 um 16:05 schrieb Jason Moore:
I want to discuss a comprehensive solution that
minimizes the git kung fu overhead for sympy contributors. If you have a
suggestion for that, please make it.
I did, but that got ignored.
--
You received this message because you are subscribed to the
Jo,
I'm sorry you think these are cheap shots. That is certainly not the
intention. I'm not trying to make you shut up, but I am trying to point out
that this thread is not helpful to solving the problems we are trying to
solve. I don't mind you writing too much if it is about something that will
Am 13.07.2015 um 23:58 schrieb Jason Moore:
Finally, if you would like to share an alternative solution to making it
simpler and easier for PRs to get merged then, by golly, please do so.
You've now written two long emails that do not come even close to offering
an alternative solution to the pro
Jo,
You did it again. You can't see the forest for the trees, as is often said.
Writing these nitpicking emails do not help anything. I doubt any of us
care if you can come up with a counter for every reason we write for
merging over rebasing. In some sense, it is irrelevant. Like I said, you
can
Am 13.07.2015 um 20:10 schrieb Aaron Meurer:
- Greatly increases the complexity of git for new users.
Agreed. I would recommend it only for people who are willing to write it.
- You can create commits that don't do what they say they do.
Yes for non-interactive rebases.
For an interactive r
On Mon, Jul 13, 2015 at 8:04 PM, Jason Moore wrote:
> This has been debated in a variety of emails, issues, pull requests, chats,
> and in person over the years. It'd take some time to collect all of those
> instances for concise review. There is no one authoritative thread that
> reached consensu
This has been debated in a variety of emails, issues, pull requests, chats,
and in person over the years. It'd take some time to collect all of those
instances for concise review. There is no one authoritative thread that
reached consensus that I know of. The email from Aaron that I quoted
earlier
On Mon, Jul 13, 2015 at 7:40 PM, Jason Moore wrote:
> Yes, we've had it in wiki for a while and I quoted a previous email that
> stated it.
Yes, sorry not to be clear - I was really wondering out loud whether
this was something that was debated fully at the time, I was not at
all questioning whet
Also, to restate this: this rule doesn't prevent you from rebasing **your**
PR if the reviewers are fine with you doing that.
We simply want to have the norm be merging and we want to stop having
people asking our contributors (especially new ones) to rebase.
Jason
moorepants.info
+01 530-601-97
Yes, we've had it in wiki for a while and I quoted a previous email that
stated it.
I'd say we are different that numpy and scipy in that sense. This is may be
one of the reasons we have more contributors with > ~10 commits than those
projects have.
Jason
moorepants.info
+01 530-601-9791
On Mon
Hi,
On Mon, Jul 13, 2015 at 7:10 PM, Aaron Meurer wrote:
> I've probably made my position clear before on this, but to restate it: I
> hate rebasing. You should never do it, and you should absolutely never tell
> others to do it.
Was there some point where y'all agreed on this as project policy?
I've probably made my position clear before on this, but to restate it: I
hate rebasing. You should never do it, and you should *absolutely* never
tell others to do it.
I may write a blog post at some point in more depth about this, but here's
a "short" version of some of the issues with rebasing:
> Yeah... it's all things that one of the project leads or another has
insisted on in the past.
Note that rebasing vs merging has been insisted on in the past by our
project lead, e.g. https://groups.google.com/forum/#!topic/sympy/MnlVfmYYMio
My email simply reminded us of that and strengthened t
Am 13.07.2015 um 16:39 schrieb Jason Moore:
I apologize for insulting you.
Okay.
> I have no intention of insulting you but I find that
the majority of your responses to emails/pr/issues are in essence nitpicks
or bikesheds.
Yeah... it's all things that one of the project leads or another h
Jo,
I apologize for insulting you. What I originally said was not polite or
thoughtful and as Matthew mentions, in this case I may have misused the
word bike-shedding. I have no intention of insulting you but I find that
the majority of your responses to emails/pr/issues are in essence nitpicks
or
Completely from the peanut gallery but
A humble plea to use the term 'bike-shedding' only in the situation
where everyone in the discussion gladly agrees that the discussion is
on an unimportant peripheral point.
--
You received this message because you are subscribed to the Google Groups
"symp
Am 12.07.2015 um 23:17 schrieb Jason Moore:
That is what I think, but I'm not asking you to shut up.
> Rather, I'd like for you to raise legitimate concerns
Well, you're telling me I'm a "master of bikeshedding", which is a
serious insult.
Plus you're dismissing arguments on an issue like git
Jo,
That is what I think, but I'm not asking you to shut up. Rather, I'd like
for you to raise legitimate concerns instead of picking apart every single
thing I wrote in the first email. Those kinds of responses are tiresome and
are not focused on being productive. I'm happy to chat about this mor
Am 12.07.2015 um 16:36 schrieb Jason Moore:
Joachim,
Thanks for the start of the bike shedding, you are becoming a master at it.
Thanks.
If that's what you think, I'll simply shut up.
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscri
Joachim,
Thanks for the start of the bike shedding, you are becoming a master at it.
You can always do what you want on your own pull request if your reviewers
are fine with your synchronization strategy, but we want to make the
default behavior be centered on merging. This means that reviewers s
Am 12.07.2015 um 00:17 schrieb Jason Moore:
FYI: We had a discussion at SymPy on how to synchronize with master and
decided that we no longer want to allow or encourage rebasing after a pull
request is made to the main SymPy repo.
I think that's overstated.
I see some reasons against merging:
Am 12.07.2015 um 00:17 schrieb Jason Moore:
The development docs have been updated:
https://github.com/sympy/sympy/wiki/Development-workflow#synchronization-with-master-sympysympy
Where do I find the img/ subdirectory?
img/dev-guide-apitoken.png needs removing (the API token section in
Accoun
FYI: We had a discussion at SymPy on how to synchronize with master and
decided that we no longer want to allow or encourage rebasing after a pull
request is made to the main SymPy repo.
The main reason is that we stall too many new contributors by forcing them
to do too much git kung fu. But ther
43 matches
Mail list logo
