W dniu 04.01.2016 o 18:41, Michael Torrie pisze:
>> Decade ago, I had plenty of friends on my jabber contacts list. Next,
>> > Google made it's talk compatible with jabber, then my friends slowly
>> > migrated to gtalk, because if they used gmail anyway, then why not use
>> > it also for jabber?
>>
On Monday, January 4, 2016 at 12:41:32 PM UTC-5, Michael Torrie wrote:
> On 01/04/2016 03:21 AM, m wrote:
> > W dniu 03.01.2016 o 05:43, Ben Finney pisze:
> >> That and other vendor-locked workflow aspects of GitHub makes it a poor
> >> choice for communities that want to retain the option of contr
On 01/04/2016 03:21 AM, m wrote:
> W dniu 03.01.2016 o 05:43, Ben Finney pisze:
>> That and other vendor-locked workflow aspects of GitHub makes it a poor
>> choice for communities that want to retain the option of control over
>> their processes and data.
>
> I'm also afraid that Github will make
W dniu 03.01.2016 o 05:43, Ben Finney pisze:
> That and other vendor-locked workflow aspects of GitHub makes it a poor
> choice for communities that want to retain the option of control over
> their processes and data.
I'm also afraid that Github will make to git the same thing as Google
did to Ja
Am 04.01.16 um 06:29 schrieb Paul Rubin:
Chris Angelico writes:
On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote:
Chris Angelico writes:
If you're not using a GitHub PR, then what you're doing is using GH to
host your repository.
What's the point of GH in that situation?
Mainly hosting,
Chris Angelico writes:
> On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote:
>> Chris Angelico writes:
>>> If you're not using a GitHub PR, then what you're doing is using GH to
>>> host your repository.
>> What's the point of GH in that situation?
> Mainly hosting, plus you can use gh-pages and
Michael Torrie writes:
> I noticed this too. Though threading based on message-id is working
> quite well, as designed!
It doesn't work as well here as elsewhere, though, because message-ids
get rewritten by the usenet gateway, so the IDs referenced in people's
headers differ depending on whether
On 01/03/2016 05:51 PM, Random832 wrote:
> Just as a general comment, I note there are now at least four mangled
> versions of this subject header, and threading is already fragile enough
> on this list. I think in the future it would be best to avoid non-ASCII
> characters in subject lines.
I no
Just as a general comment, I note there are now at least four mangled
versions of this subject header, and threading is already fragile enough
on this list. I think in the future it would be best to avoid non-ASCII
characters in subject lines.
--
https://mail.python.org/mailman/listinfo/python-l
On 1/2/16 11:43 PM, Ben Finney wrote:
That and other vendor-locked workflow aspects of GitHub makes it a poor
choice for communities that want to retain the option of control over
their processes and data.
The Tcl community has moved to Fossil with great success:
http://www.fossil-scm.org
Lig
On 01/03/2016 08:09 AM, Bernardo Sulzbach wrote:
> On Sun, Jan 3, 2016 at 1:05 PM, Michael Torrie wrote:
>> kernel development is now exclusively on github.
>>
>
> No it is not. If they have (now) 88 PR is because people don't RTFM.
Good to know.
--
https://mail.python.org/mailman/listinfo/pyt
On 01/02/2016 09:56 PM, Michael Vilain wrote:
> Seriously, don't like git and the gitflow, find a project where they do
> things more to your liking.
I do like git and the git work-flow. Seems like github is doing an
end-run around several of the key features of git and the git work-flow
to keep
On Sun, Jan 3, 2016 at 9:42 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> If you're not using a GitHub PR, then what you're doing is using GH to
>> host your repository. So yes, you pull into your local repo and then
>> push to GH.
>
> What's the point of GH in that situation?
Mainly hosting
Chris Angelico writes:
> If you're not using a GitHub PR, then what you're doing is using GH to
> host your repository. So yes, you pull into your local repo and then
> push to GH.
What's the point of GH in that situation?
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Jan 3, 2016 at 8:31 PM, Random832 wrote:
> Chris Angelico writes:
>> They are. Ultimately, a GitHub pull request is backed by a git pull
>> request.
>
> There is no such thing as a "git pull request", except in the
> ordinary english meaning of the word request. It is true that a
> pull r
On Sun, Jan 3, 2016 at 8:46 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney
>> wrote:
>> > Anyone can take email data from the email server, migrate it to a
>> > different implementation of the same email system, keep it running
>> > with the same
Random832 writes:
> All of that discussion has value, and it's not good to
> have any of it locked up in a place that cannot be exported.
I have a dim recollection of Python moving from Trac to a proprietary,
hosted bug tracker for a while, but now they're back to an open(?)
system but are about
Chris Angelico writes:
> On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney wrote:
> > Anyone can take email data from the email server, migrate it to a
> > different implementation of the same email system, keep it running
> > with the same data and allow the same people to continue interacting
> > wit
On Sun, Jan 03, 2016 at 04:31:55AM -0500, Random832 wrote:
> But there is no command to create a "pull request", nowhere for such
> a thing to exist in the repository, etc.
There is this [1].
> Also if someone puts through a github pull request and then their
> patch is accepted, my understanding
Chris Angelico writes:
> They are. Ultimately, a GitHub pull request is backed by a git pull
> request.
There is no such thing as a "git pull request", except in the
ordinary english meaning of the word request. It is true that a
pull request is, from one angle, a formalized request for someone
t
On Sun, Jan 3, 2016 at 7:45 PM, Ben Finney wrote:
> Anyone can take email data from the email server, migrate it to a
> different implementation of the same email system, keep it running with
> the same data and allow the same people to continue interacting with it
> as before.
>
> Those are trait
Christian Gollwitzer writes:
> There are layers. Below your Python code there is CPython, below that
> the C compiler, the OS, and finally the hardware.
Yes. There are continual motivations to take the technology at any of
those levels and make it less free, make it more locked to single
vendors
Am 03.01.16 um 09:03 schrieb Ben Finney:
Christian Gollwitzer writes:
Arguably, the most valuable outcome of the pull request in the end is
the patch, which is of course contained in the git repository.
Arguably, the most valuable outcome of a database system is the query
result, which is of
Christian Gollwitzer writes:
> Arguably, the most valuable outcome of the pull request in the end is
> the patch, which is of course contained in the git repository.
Arguably, the most valuable outcome of a database system is the query
result, which is of course contained in the result set of tu
Am 03.01.16 um 08:04 schrieb Random832:
Michael Vilain writes:
We used stash/bitbucket at my last contract. It's the second site I've
come across that used Atlasian's toolset. Yes, I know it's not
statistically significant.
Anyway, the pull/merge request workflow is becoming pretty standard.
Michael Vilain writes:
> We used stash/bitbucket at my last contract. It's the second site I've
> come across that used Atlasian's toolset. Yes, I know it's not
> statistically significant.
>
> Anyway, the pull/merge request workflow is becoming pretty standard.
I think you're missing a disti
Michael Torrie writes:
> On 01/02/2016 12:02 AM, Ben Finney wrote:
> > GitHub's “pull request” workflow is entirely proprietary and can
> > only be done within GitHub.
>
> Really? This seems like an entirely artificial github requirement.
Yes, it is.
> There's absolutely no reason why github c
27 matches
Mail list logo
