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 philosophy and open source are strictly orthogonal.
There are automotive companies that do "glass-pane production", i.e. you
can look into the actual production process; yet their products are as
proprietary as their legal departments can make them (e.g. apply "design
copyright" so nobody can sell a replacement mirror).
The converse is available as well: strictly open-source libraries of
highest quality that are developed mostly behind closed doors, witness
Google's Guava library (you *can* get your changes in, but it's a major
undertaking and you don't see the team's internal priorities so you
don't even know where a contribution would be welcome).
>> We should not be afraid to make
>> mistakes, and even have it in a permanent record that we made those
> mistakes.
It's also not about showing mistakes to the public. It's about making
the commit log more useful.
>> Good open source software, certainly SymPy, is built in the
>> bazaar, not the cathedral.
It's not an opposite, it's a trade-off. Bazaar tends to favor quantity
over quality, cathedral is the reverse.
Case in point is Linux, according to Con Kolivas of kernel scheduler
fame: http://ck-hack.blogspot.be/2010/10/other-schedulers-illumos.html
and also according to the list of CVEs for Linux (bazaar) vs. OpenBSD
(cathedral).
I suggest that we let the proposal stand and that Jo can document all of
the cases over the next several months where rebasing was necessary and
where this
guideline caused more problems that it solved. Once Jo builds his case
with real data he can propose a new guideline and then we can discuss. Is
that sufficient to
move forward here?
+1
We'd just be arguing about whether rebasing in what particular case
would have helped or not.
Aaron's stance is that the commit log should be a
stream-of-consciousness thing. I see no value in that, and actually
think it's damaging (I found the log to be less than helpful to find out
what was changed and why), but essentially it's priorities and
preferences, both subjective, and there's no point in arguing that.
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/55A6B842.5030907%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.