Bitcoin Forum
October 04, 2022, 05:52:37 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 [624] 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 ... 2187 »
  Print  
Author Topic: [XMR] Monero Speculation  (Read 3307419 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (2 posts by 1+ user deleted.)
iCEBREAKER
Legendary
*
Offline Offline

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


View Profile WWW
January 31, 2016, 10:08:56 AM
 #12461

Once ETH releases ring signatures dapp its over. The only chance for monero to survive is to increase adoption by a tenfold.
Monero doesn't even have a GUI (not saying that would increase adoption!). Man-child developers..

Look at the blockchain, http://chainradar.com/xmr/blocks , blocks are empty of transactions.. No one is using this shitcoin..
Anyway, I'll keep exchanging xmr for ETH, most likely it won't even exist this time next year.

You may borrow 20591 XMR for 2-60 Days at only 0.0040%.

Some other loans are even less expensive.

Why don't you short XMR, if you are so certain "no one is using this shitcoin" and it "won't even exist this time next year?"


Chicken?


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Is Dash a scam?
Every time a block is mined, a certain amount of BTC (called the subsidy) is created out of thin air and given to the miner. The subsidy halves every four years and will reach 0 in about 130 years.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1664905957
Hero Member
*
Offline Offline

Posts: 1664905957

View Profile Personal Message (Offline)

Ignore
1664905957
Reply with quote  #2

1664905957
Report to moderator
1664905957
Hero Member
*
Offline Offline

Posts: 1664905957

View Profile Personal Message (Offline)

Ignore
1664905957
Reply with quote  #2

1664905957
Report to moderator
1664905957
Hero Member
*
Offline Offline

Posts: 1664905957

View Profile Personal Message (Offline)

Ignore
1664905957
Reply with quote  #2

1664905957
Report to moderator
primer-
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
January 31, 2016, 10:13:26 AM
 #12462

Why don't you short XMR, if you are so certain "no one is using this shitcoin" and it "won't even exist this time next year?"

I've still got around 40k + I mine around 250xmr daily .. No need for a loan ..
Why do you think the price decreased from 160k to 130k ... Most of the sells were mine..
bitebits
Legendary
*
Offline Offline

Activity: 2107
Merit: 2500


Flippin' burgers since 1163.


View Profile
January 31, 2016, 10:15:22 AM
 #12463

Blocks are empty of transactions.. No one is using this shitcoin..

Isn't that awesome? It is like using that new highway with fresh new tarmac all by yourself, without anyone knowing, for free!
Now when thinking about it I really like keeping it for myself, so please move over to your over-hyped toll road.

- You can figure out what will happen, not when /Warren Buffett
- Pay any Bitcoin address privately with a little help of Monero.
primer-
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
January 31, 2016, 10:24:24 AM
 #12464

No one is using this shitcoin.
I'll keep exchanging xmr for ETH
Are you actually implying people are using ETH to buy stuff? Lol

No, ETH is not a currency its so much more. Anyone actually using XMR to buy stuff ? Blocks are empty so no... Name one merchant that accepts xmr ...
primer-
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
January 31, 2016, 10:26:21 AM
 #12465

Blocks are empty of transactions.. No one is using this shitcoin..

Isn't that awesome? It is like using that new highway with fresh new tarmac all by yourself, without anyone knowing, for free!
Now when thinking about it I really like keeping it for myself, so please move over to your over-hyped toll road.

Sure donkey, keep the 'highway' all to yourself..
klee
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000



View Profile
January 31, 2016, 10:26:56 AM
 #12466

No one is using this shitcoin.
I'll keep exchanging xmr for ETH
Are you actually implying people are using ETH to buy stuff? Lol

No, ETH is not a currency its so much more. Anyone actually using XMR to buy stuff ? Blocks are empty so no... Name one merchant that accepts xmr ...
Nice idea! I am starting accepting XMR for my subscription fees since now!

EDIT: Also ETH lol
primer-
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
January 31, 2016, 10:45:21 AM
 #12467

No one is using this shitcoin.
I'll keep exchanging xmr for ETH
Are you actually implying people are using ETH to buy stuff? Lol

No, ETH is not a currency its so much more. Anyone actually using XMR to buy stuff ? Blocks are empty so no... Name one merchant that accepts xmr ...
People are holding ETH for two reasons, speculation or development, mostly the former; its the same situation as Monero right now.

Monero and development are two words that don't go together. I've been around since the bytecoin fork (April 2014), very little has been done in TWO YEARS...
I've seen shitcoins with a 3 month lifespan do more development-wise than monero in two fucking years..
farfiman
Legendary
*
Offline Offline

Activity: 1449
Merit: 1001



View Profile
January 31, 2016, 10:55:02 AM
 #12468

...
I've seen shitcoins with a 3 month lifespan do more development-wise than monero in two fucking years..

True, most have "developed" much better websites, flashy logos etc...

"We are just fools. We insanely believe that we can replace one politician with another and something will really change. The ONLY possible way to achieve change is to change the very system of how government functions. Until we are prepared to do that, suck it up for your future belongs to the madness and corruption of politicians."
Martin Armstrong
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736
Merit: 1005

Let's talk governance, lipstick, and pigs.


View Profile
January 31, 2016, 11:29:04 AM
 #12469

You know, Monero and ETH are too important to be used for purchasing coffee. We should really look at limiting their blocksizes.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
bitebits
Legendary
*
Offline Offline

Activity: 2107
Merit: 2500


Flippin' burgers since 1163.


View Profile
January 31, 2016, 11:47:29 AM
 #12470

You know, Monero and ETH are too important to be used for purchasing coffee. We should really look at limiting their blocksizes.

Great idea. It will make it more valuable too because of the increased scarcity.

- You can figure out what will happen, not when /Warren Buffett
- Pay any Bitcoin address privately with a little help of Monero.
binaryFate
Legendary
*
Offline Offline

Activity: 1484
Merit: 1001


Still wild and free


View Profile
January 31, 2016, 11:50:37 AM
 #12471

You know, Monero and ETH are too important to be used for purchasing coffee. We should really look at limiting their blocksizes.

Great idea. It will make it more valuable too because of the increased scarcity.

Monero's block size is already limited - algorithmically with an "elastic" rule.
The suggestion clearly comes from a Bitcoin centric view. In fact irrelevant here.

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. 
This makes Monero a better candidate to deserve the term "digital cash".
DaveyJones
Hero Member
*****
Offline Offline

Activity: 768
Merit: 505


View Profile
January 31, 2016, 12:13:35 PM
 #12472

No one is using this shitcoin.
I'll keep exchanging xmr for ETH
Are you actually implying people are using ETH to buy stuff? Lol

No, ETH is not a currency its so much more. Anyone actually using XMR to buy stuff ? Blocks are empty so no... Name one merchant that accepts xmr ...
People are holding ETH for two reasons, speculation or development, mostly the former; its the same situation as Monero right now.

Monero and development are two words that don't go together. I've been around since the bytecoin fork (April 2014), very little has been done in TWO YEARS...
I've seen shitcoins with a 3 month lifespan do more development-wise than monero in two fucking years..

So why are you even here and keep mining it if there is better stuff around.
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1736
Merit: 1005

Let's talk governance, lipstick, and pigs.


View Profile
January 31, 2016, 12:51:49 PM
 #12473

You know, Monero and ETH are too important to be used for purchasing coffee. We should really look at limiting their blocksizes.

Great idea. It will make it more valuable too because of the increased scarcity.

Monero's block size is already limited - algorithmically with an "elastic" rule.
The suggestion clearly comes from a Bitcoin centric view. In fact irrelevant here.
That depends on your "consensus".
I'll see myself out now. I know this will be deleted anyway.

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
generalizethis
Legendary
*
Offline Offline

Activity: 1750
Merit: 1035


Facts are more efficient than fud


View Profile WWW
January 31, 2016, 01:08:53 PM
 #12474

No one is using this shitcoin.
I'll keep exchanging xmr for ETH
Are you actually implying people are using ETH to buy stuff? Lol

No, ETH is not a currency its so much more. Anyone actually using XMR to buy stuff ? Blocks are empty so no... Name one merchant that accepts xmr ...
People are holding ETH for two reasons, speculation or development, mostly the former; its the same situation as Monero right now.

Monero and development are two words that don't go together. I've been around since the bytecoin fork (April 2014), very little has been done in TWO YEARS...
I've seen shitcoins with a 3 month lifespan do more development-wise than monero in two fucking years..

So why are you even here and keep mining it if there is better stuff around.

And why would you slam a coin you supposedly hold 40k in and continue to mine? Not exactly smart unless you are lying and really think your investment opinion matters--though I think it is more that primer is lying to himself about the latter. If you believe a coin is going to fail, you pump it and sell into the hype, not vice verse.

dEBRUYNE
Legendary
*
Offline Offline

Activity: 2268
Merit: 1141


View Profile
January 31, 2016, 01:18:54 PM
 #12475

Once ETH releases ring signatures dapp its over. The only chance for monero to survive is to increase adoption by a tenfold.
Monero doesn't even have a GUI (not saying that would increase adoption!). Man-child developers..

Look at the blockchain, http://chainradar.com/xmr/blocks , blocks are empty of transactions.. No one is using this shitcoin..
Anyway, I'll keep exchanging xmr for ETH, most likely it won't even exist this time next year.




Unless it is enforced (and thus mandatory) on the protocol level it would simply be a mixer similiar to Bitcoin's Coinjoin (perhaps one with better privacy features). Therefore, it will only slightly improve fungibility. Also (afaik), the fees to mix have to be done with transparent coins, which leaks your privacy.

Privacy matters, use Monero - A true untraceable cryptocurrency
Why Monero matters? http://weuse.cash/2016/03/05/bitcoiners-hedge-your-position/
flagel8
Full Member
***
Offline Offline

Activity: 188
Merit: 100



View Profile
January 31, 2016, 05:14:13 PM
Last edit: January 31, 2016, 05:25:09 PM by flagel8
 #12476

Once ETH releases ring signatures dapp its over. The only chance for monero to survive is to increase adoption by a tenfold.
Monero doesn't even have a GUI...

...No one is using this (Monero)...


He is very offensive, but what really makes me sad is that I sort of agree with him. I think that the opportunity window for Monero's success probably closed many months ago. (If not, there is very little time left). Great technology, but there is NO Marketing, and no (Non-Techno-Geek) user friendliness.  Nor does there seem to be any recognition that these factors might be important.

Beta was superior to VHS. But that analogy is flawed, because those two videotapes were functionally more or less equivalent in their applications. But the Market obviously sees the potential functionality of ETH as superior to that of Monero. And again, there's a disparity in Marketing among the two. Look at their ages, and their market caps. And ETH is not yet finished either.
iCEBREAKER
Legendary
*
Offline Offline

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


View Profile WWW
January 31, 2016, 05:55:42 PM
 #12477

He is very offensive, but what really makes me sad is that I sort of agree with him. I think that the opportunity window for Monero's success probably closed many months ago. (If not, there is very little time left). Great technology, but there is NO Marketing, and no (Non-Techno-Geek) user friendliness.  Nor does there seem to be any recognition that these factors might be important.

Beta was superior to VHS. But that analogy is flawed, because those two videotapes were functionally more or less equivalent in their applications. But the Market obviously sees the potential functionality of ETH as superior to that of Monero. And again, there's a disparity in Marketing among the two. Look at their ages, and their market caps. And ETH is not yet finished either.

The "NO Marketing" is intentional, because of the "no user friendliness" you also note.

Monero isn't even out of beta yet.  We can't really judge its success or failure until after multisig, confidential tx, and the GUI (not to mention some marketing) have given the coin a chance to gain market share.


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Is Dash a scam?
rpietila
Donator
Legendary
*
Offline Offline

Activity: 1722
Merit: 1026



View Profile
January 31, 2016, 06:26:27 PM
 #12478

Despite the short attention span of some, I still:

1) Don't think there has been invented anything more interesting in the world, since crypto was invented.
2) Don't think there is any coin more interesting created, since Monero was created.

=> Despite that sun goes up and goes down, and it would be nice to have [insert feature here], there is no place better to be than Monero is.

HIM TVA Dragon, AOK-GM, Emperor of the Earth, Creator of the World, King of Crypto Kingdom, Lord of Malla, AOD-GEN, SA-GEN5, Ministry of Plenty (Join NOW!), Professor of Economics and Theology, Ph.D, AM, Chairman, Treasurer, Founder, CEO, 3*MG-2, 82*OHK, NKP, WTF, FFF, etc(x3)
dEBRUYNE
Legendary
*
Offline Offline

Activity: 2268
Merit: 1141


View Profile
January 31, 2016, 07:46:53 PM
 #12479

Crosspost, logs of the first IRC dev meeting (https://forum.getmonero.org/4/academic-and-technical/2471/irc-dev-meeting-every-2nd-sunday-at-5pm-utc)

For this that are interested, here are the logs from the dev meeting. Someone is working on an overview if you don't feel like reading the whole thing.

<fluffypony>  who are we missing 
<fluffypony>  tewinget / othe / warptangent / NoodleDoodle you guys around? 
<warptangent>  ^ 
<fluffypony>  hokay 
<dEBRUYNE>  smooth? 
<fluffypony>  smooth and luigi1111w are around 
<fluffypony>  although luigi1111w is using some other nick 
<fluffypony>  luigi1112 I think 
<luigi1114>  4 
<moneromooo>  mario1114 
<fluffypony>  lol 
<fluffypony>  about a year ago we did this using TeamSpeak 
<fluffypony>  I mean Mumble 
<luigi1114>  for you guys 
<fluffypony>  which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking 
<binaryFate>  Firechat? Was cool 
<fluffypony>  binaryFate: no we did a couple of actual dev meetings   
<fluffypony>  but it's tough to sustain 
<binaryFate>  Oh ok 
<xmrpromotions>  I think typing is fine too. 
<ArticMine>  This is fine 
<fluffypony>  agreed 
<fluffypony>  plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P 
<fluffypony>  ok so there are a few things on the agenda   
<luigi1111>  I'm sick so my voice is already changed 
<warptangent>  the format seems to have been working well for kovri too 
<fluffypony>  the first thing I think we should discuss is the dev branch   
<fluffypony>  we've fallen back into the habit of merging stuff to master 
<moneromooo>  That's because bugs 
<fluffypony>  I know 
<fluffypony>  we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs 
<fluffypony>  are there any bug fixes waiting in the wings, or should we do that next week? 
<moneromooo>  That last commit thing, which I'll have to think about a bit more. 
<moneromooo>  Also, possibly merging the per-tx bits in lmdb. 
<hyc>  which? 
<moneromooo>  tx_{unlocks,heights,outputs} 
<hyc>  ah 
<moneromooo>  And output_{keys,amounts,indices,txs} 
<hyc>  DB format change, I don't think that's a bug-fix 
<moneromooo>  Way more of htose than blocks 
<fluffypony>  maybe we need to consider a more generalised approach to format changes   
<fluffypony>  something like Laravel's migrations 
<fluffypony>  it'll have to be per-DB-format anyway   
<fluffypony>  per-DB-type I mean 
<warptangent>  i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes. 
<warptangent>  two sets of bug fixes not yet added though 
<fluffypony>  ok if they're not considered crucial for 0.9.x then we can put them into dev? 
<hyc>  warptangent: since I've been working on the same thing, I guess I should take a look at your stuff 
<warptangent>  1. berkeleydb support for importer - almost ready, some argument usage cleanup 
<moneromooo>  Once I re-merged then 
<hyc>  but I don't consider anything I'm looking at now as bug-fix 
<fluffypony>  (this is how we meeting https://i.imgur.com/OR5ZVoI.jpg
<warptangent>  2. finish hf fix for importer - mostly done, pending some cleanup with bdb 
<fluffypony>  hokay 
<hyc>  (I have a wineglass here too, sadly empty) 
<warptangent>  hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys 
<fluffypony>  also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful 
<fluffypony>  any objections to the bundling? 
<luigi1111>  how much of a pain is it to change formats? 
<hyc>  I haven't even looked at dev. no objection from me 
<fluffypony>  luigi1111w: mostly just requires copying data to a new table and nuking the old one 
<moneromooo>  Hmm. I have a few patches to czmq, to make things build. 
<moneromooo>  Not super sure whether it was me being dumb or not though. 
<fluffypony>  ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on? 
<fluffypony>  I'll get it in the source tree the meantime, and cmake-ify all of the things 
<moneromooo>  I'll merge yes. Then you can add zmq to the cmake stuff Tongue Then I'll add my patches if they're still needed. 
<moneromooo>  Great, ty 
<fluffypony>  great minds think alike 
<fluffypony>  ok next I'd like us to chat about a style guide 
<fluffypony>  we've been working on one in Kovri that we can possibly use for Monero 
<fluffypony>  https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style 
<hyc>  oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit 
<fluffypony>  not necessary to read the style guide now, just more a general sense of if everyone is comfy with a style guide, and if anyone has any particular preferences   
<smooth>  i have no objection to any reasonable style guide but i do object to re-styling of existing code 
<moneromooo>  Pages and pages of stuff ? :| 
<moneromooo>  I object too, if it's only restyling for the sake of it. 
<fluffypony>  ok so more of a restyle-as-you-go   
<moneromooo>  That massive reindent patch already caused me grief 
<fluffypony>  which is in line with our refactor-as-you-go approach 
<ArticMine>  Apply the style guide to new code 
<smooth>  imo the best policy is keep the style on small chages to existing code and new style on new code 
<smooth>  there is probably a gray area there 
<warptangent>  should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces. 
<hyc>  agreed 
<fluffypony>  warptangent: that's the one area where we differ from Kovri, I'd lean towards yes 
<moneromooo>  I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense. 
<warptangent>  moneromooo: style on the current project though, not different styles per file, right? 
<moneromooo>  Whatever code I'm modifying. 
<moneromooo>  It causes the least problems. 
<fluffypony>  moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to 
<warptangent>  the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point 
<moneromooo>  Oh OK. 
<moneromooo>  With that out of the way... 
<fluffypony>  ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things 
<warptangent>  yes, seems good 
<hyc>  I would push harder on "code should go in a .cpp not .h" 
<fluffypony>  hyc: agreed 
<fluffypony>  I'll make it clearer 
<fluffypony>  moneromooo: did you want to raise a point, or were you saying we can move on? 
<hyc>  overall it looks sane to me 
<moneromooo>  I'm good. 
<fluffypony>  ok   
<fluffypony>  next point is also administrative in nature 
<fluffypony>  we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors 
<fluffypony>  http://rfc.zeromq.org/spec:22 
<fluffypony>  we can discuss it more in future, but the long and the short of it 
<fluffypony>  is that we merge every PR as long as it doesn't break the build 
<fluffypony>  if it does something bad / dangerous we can have a follow up PR to revert 
<fluffypony>  but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged 
<fluffypony>  because it's never "perfect" 
<fluffypony>  so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests) 
<moneromooo>  This PR-hell problem's never happened, has it ? 
<fluffypony>  moneromooo: not in Monero yet, but Bitcoin is chock-full of it 
<gingeropolous>  ^ this is for dev branch, right? 
<moneromooo>  I think common sense is again a better thing than going the opposite extreme. 
<fluffypony>  gingeropolous: this is in general 
<warptangent>  i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect? 
<fluffypony>  moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P 
<smooth>  i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master 
<moneromooo>  Well, if it's nuanced, fine. 
<fluffypony>  warptangent: it does, yes 
<fluffypony>  as explained by Pieter to binaryFate and I last year 
<smooth>  if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction 
<smooth>  *tagged 
<fluffypony>  smooth: yes that's a given 
<fluffypony>  master represents a stable, tagged release 
<fluffypony>  we work in dev 
<fluffypony>  anyone that submits a PR to master gets it closed and asked to submit it to dev 
<fluffypony>  anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor   
<smooth>  there needs to be a place for bug fix releases though 
<binaryFate>  I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable. 
<moneromooo>  There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it. 
<binaryFate>  Common sense might work now, long term with a higher market cap we'll face same issues as btc 
<binaryFate>  Where common sense diverges and the code Base ossifies 
<xmrpromotions>  As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev 
<fluffypony>  smooth: it doesn't preclude it 
<fluffypony>  moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine 
<binaryFate>  What's the envisionned time scale for ringct? 
<smooth>  the idea of a historical record is good 
<hyc>  we have similar issues with OpenLDAP - you need 3 branches 
<hyc>  one for dev, one for released code, and one for release bugfixes 
<smooth>  but i would make the case then that 0MQ should be reverted since it is unusable 
<hyc>  particularly when dev and release are far apart 
<smooth>  im not actually proposing this because i know it would be a mess, but making a point for the future 
<hyc>  like now, where dev has 0MQ and release doesn't 
<fluffypony>  smooth: I agree - moneromooo and I will play around with it next week and make a decision   
<moneromooo>  Reverting isn't really possible. 
<fluffypony>  moneromooo: we could drop dev and re-branch 
<moneromooo>  But one could add ringCT to a new branch based on master. 
<fluffypony>  if it came to that, I mean 
<moneromooo>  That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again. 
<fluffypony>  ok 
<smooth>  imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable 
<moneromooo>  s/on master/on a branch based off master/ 
<fluffypony>  smooth: it was usable-ish, we might have regressed some in fiddling   
<moneromooo>  Yes, that. 
<fluffypony>  anyway - let's evaluate and figure out 
<moneromooo>  I think I added all missing RPC so it cn be used, just not by people who want it to work without problem. 
<dnaleor>  **<fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching 
<hyc>  doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev 
<fluffypony>  hyc: I guess it depends on the importance of a bug fix 
<moneromooo>  It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close. 
<fluffypony>  we'll see   
<fluffypony>  I don't think we need to create a pressure-cooker for it 
<fluffypony>  ok can I go on? 
<ArticMine>  There are trade offs here. I see problems if dev and master deviate materially 
<xmrpromotions>  it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes 
<fluffypony>  xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties 
<ArticMine>  With bug fixes as a transition from dev to master 
<fluffypony>  again depends on the nature of the bugfix   
<fluffypony>  like warptangent's work on BDB and the importer probably aren't critical enough to go into master 
<warptangent>  the importer works properly when it has the hard fork support though, and that uses the bdb support 
<moneromooo>  If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it. 
<ArticMine>  My concern is master deviating materially from a quasi stable dev 
<fluffypony>  ArticMine: something like ringct would have to be done in both master and dev 
<ArticMine>  So a project based on master would need a major rewrite after a tagged release 
<fluffypony>  we did dual-PRs for a while 
<fluffypony>  we can do them again 
<fluffypony>  might be easier than The Grand Merge 
<smooth>  something like ringct should only be in dev imo 
<ArticMine>  Yes anything fundamental has to be done in parallel 
<smooth>  until it gets released of course 
<fluffypony>  I think let's defer further discussion of this till the next meeting 
<luigi1111>  agreed to both 
<fluffypony>  we don't have enough info on the ringct effort or on the state of the dev branch right now anyway 
<binaryFate>  One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them? 
<ArticMine>  I agree and lets carefully review the zeromq rfc in the meantime 
<moneromooo>  I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready. 
<fluffypony>  binaryFate: no matter what we say people clone and build master 
<gingeropolous>  **<- this guy 
<fluffypony>  it doesn't matter how much we encourage building a tagged release 
<fluffypony>  so we made a decision ages ago that master would be stable 
<fluffypony>  so that anyone pulling and building master doesn't get some hacky, broken branch 
<binaryFate>  Ok 
<fluffypony>  moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev 
<moneromooo>  It can be in any repo. 
<smooth>  i think not in the main repo is fine 
<moneromooo>  Like I was hacking on tewinget's branch for a while. 
<fluffypony>  yeah that's a good point 
<luigi1111>  +1 
<fluffypony>  as long as that person is around and accepting PRs it's perfect 
<warptangent>  then one big PR to dev when it's ready? 
<moneromooo>  If we go to a dev/master setup, how does dev get merged to master anyway ? 
<warptangent>  that has worked before, yes 
<hyc>  yeah, keep main repo relatively clean 
<luigi1111>  a new feature can get a sort of "lead dev" 
<fluffypony>  moneromooo: when we release we merge from dev to master and tag master 
<luigi1111>  and contributers can hack on his repo 
<moneromooo>  So master becomes a copy of dev at that point ? 
<fluffypony>  yes 
<ArticMine>  Yes but a six month cycle could be too long 
<smooth>  thats a different issue 
<smooth>  how often to have major releases 
<fluffypony>  we can do major releases whenever, as long as we have major fork releases every 6 months 
<smooth>  also are releases time based or feature based 
<luigi1111>  kinda both ? 
<fluffypony>  yeah both 
<hyc>  feature-based is all that makes sense to me 
<ArticMine>  The merge to master may need to be more frequent than major fork releases 
<moneromooo>  feature based, but the rolling hard fork also pulls time based I think. 
<fluffypony>  yes 
<binaryFate>  Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent? 
<fluffypony>  binaryFate: depends on how stable dev is 
<luigi1111>  so new features thus shouldn't be in dev until they are working properly/ready for release 
<luigi1111>  because of timed releases 
<smooth>  time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture 
<fluffypony>  smooth, luigi1111: yes, you're both right 
<luigi1111>  it works as long as the half finished feature isn't partially merged 
<luigi1111>  or whatever 
<fluffypony>  the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done 
<fluffypony>  but I think let's make it the last time that happens 
<fluffypony>  then we avoid complication 
<warptangent>  ok 
<moneromooo>  tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem. 
<smooth>  i agree with ArticMine that we can have releases sooner than 6 months 
<gingeropolous>  ah ok. so how the 0MQ happened is not how it will be in future 
<binaryFate>  Agree with moneromooo 
<fluffypony>  ok guys we're running overtime, so let's drop this for now, we can pick it up again later 
<smooth>  i think it is simply unnecessary to merge to master 
<smooth>  er sorry, commit unreleased stuff to master 
<moneromooo>  I think one of the problems with 0mq is that oranjuice kinda left 
<smooth>  any developer can handle getting the latest stuff from someone ele 
<smooth>  *somewhere else 
<moneromooo>  So it jsut had to be merged 
<ArticMine>  Let get back to this question at the next meeting 
<fluffypony>  ok 
<fluffypony>  last two things   
<smooth>  yup 
<fluffypony>  the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way 
<fluffypony>  I'd like us to decide whether we want to keep hacking around things 
<moneromooo>  Does epee really get in the way ? 
<fluffypony>  or if we want to spend the effort now dumping this stuff for things that are easier 
<hyc>  it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too 
<moneromooo>  epee does ? 
<hyc>  yeah 
<fluffypony>  moneromooo: yes it does; it made QoS an absolute nightmare to do 
<fluffypony>  and it's still not done properly 
<moneromooo>  We'd have a replace a lot of stuff. 
<ArticMine>  32bit especially on windows is going to be around for a long time 
<dEBRUYNE>  + TAILS 
<moneromooo>  And a lot of somewhat low level stuff. 
<warptangent>  the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning? 
<fluffypony>  warptangent: low to impossible at the moment 
<fluffypony>  I mean, we can rip and replace the logging stuff with boost::log 
<fluffypony>  all the console stuff can go ncurses or similar   
<smooth>  id be more in favor of specific items like that, done on feature branch 
<fluffypony>  and the wire protocol can go ZMTP, since we have a 0MQ dep anyway 
<fluffypony>  eventually we'll get to a point where we're no longer reliant on epee 
<moneromooo>  I agree with the bit by bit approach. 
<warptangent>  that sounds manageable 
<fluffypony>  also then we'll actually have usable Doxygen docs 
<smooth>  the thing to bear in mind is this has virtually zero end user benefit, if not actually zero 
<fluffypony>  yes 
<fluffypony>  on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library 
<moneromooo>  Well, the benefit is said to be for 32 bit users. 
<fluffypony>  so we have a shortcut of sorts there 
<fluffypony>  (in terms of users clamouring for stuff) 
<fluffypony>  moneromooo: and long-term viability   
<fluffypony>  we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one 
<fluffypony>  so there's scope to slowly bring the codebase in line 
<smooth>  i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code. 
<hyc>  huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed 
<moneromooo>  I was kinda thinking that too... 
<fluffypony>  I guess, but tbh it does make the project seem significantly less mature 
<fluffypony>  which I guess is fair, it's not even 2 years old 
<gingeropolous>  less hurdles, more good 
<smooth>  it is somewhat hard to come up to speed with the code, i would agree with that 
<fluffypony>  alright 
<fluffypony>  last thing so we can wrap up 
<fluffypony>  I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects 
<fluffypony>  both on behalf of the core team, and on behalf of the community   
<fluffypony>  you all do an amazing job, and we've done a truckload of work in 2014 and 2015 
<fluffypony>  so here's to an amazing 2016 
<gingeropolous>  hear hear! thank you fluffypony for herding the cats so good 
<Bassica>  hear hear! 
<xmrpromotions>  thank you! 
<ArticMine>  Thanks for all the good work 
<fluffypony>  thus concludes the first meeting, next one in two weeks 
<warptangent>  thanks fluffypony 
<luigi1111>  thanks 
<binaryFate>  Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community. 
<dEBRUYNE>  Thanks fluffypony! 
<hyc>  **<glug> thanks all 
<Infinite_Jest>  is there a buffet? 
<fluffypony>  Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins 
<Infinite_Jest>  ok great Smiley but seriously thanks! 
<cardboardoranges>  thanks fluffy

Privacy matters, use Monero - A true untraceable cryptocurrency
Why Monero matters? http://weuse.cash/2016/03/05/bitcoiners-hedge-your-position/
owm123
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
January 31, 2016, 10:08:14 PM
 #12480

Crosspost, logs of the first IRC dev meeting (https://forum.getmonero.org/4/academic-and-technical/2471/irc-dev-meeting-every-2nd-sunday-at-5pm-utc)

For this that are interested, here are the logs from the dev meeting. Someone is working on an overview if you don't feel like reading the whole thing.

<fluffypony>  who are we missing 
<fluffypony>  tewinget / othe / warptangent / NoodleDoodle you guys around? 
<warptangent>  ^ 
<fluffypony>  hokay 
<dEBRUYNE>  smooth? 
<fluffypony>  smooth and luigi1111w are around 
<fluffypony>  although luigi1111w is using some other nick 
<fluffypony>  luigi1112 I think 
<luigi1114>  4 
<moneromooo>  mario1114 
<fluffypony>  lol 
<fluffypony>  about a year ago we did this using TeamSpeak 
<fluffypony>  I mean Mumble 
<luigi1114>  for you guys 
<fluffypony>  which was nice, but it isn't as fluid as typing because sometimes you can't hear that someone else is talking 
<binaryFate>  Firechat? Was cool 
<fluffypony>  binaryFate: no we did a couple of actual dev meetings   
<fluffypony>  but it's tough to sustain 
<binaryFate>  Oh ok 
<xmrpromotions>  I think typing is fine too. 
<ArticMine>  This is fine 
<fluffypony>  agreed 
<fluffypony>  plus there are people working on Monero that would prefer not to have to use a voice changer just to participate :-P 
<fluffypony>  ok so there are a few things on the agenda   
<luigi1111>  I'm sick so my voice is already changed 
<warptangent>  the format seems to have been working well for kovri too 
<fluffypony>  the first thing I think we should discuss is the dev branch   
<fluffypony>  we've fallen back into the habit of merging stuff to master 
<moneromooo>  That's because bugs 
<fluffypony>  I know 
<fluffypony>  we're going to have to do a point release to fix the v1/v2 / stuck transactions bugs 
<fluffypony>  are there any bug fixes waiting in the wings, or should we do that next week? 
<moneromooo>  That last commit thing, which I'll have to think about a bit more. 
<moneromooo>  Also, possibly merging the per-tx bits in lmdb. 
<hyc>  which? 
<moneromooo>  tx_{unlocks,heights,outputs} 
<hyc>  ah 
<moneromooo>  And output_{keys,amounts,indices,txs} 
<hyc>  DB format change, I don't think that's a bug-fix 
<moneromooo>  Way more of htose than blocks 
<fluffypony>  maybe we need to consider a more generalised approach to format changes   
<fluffypony>  something like Laravel's migrations 
<fluffypony>  it'll have to be per-DB-format anyway   
<fluffypony>  per-DB-type I mean 
<warptangent>  i've got schema changes i've been using for a couple months, for better use on hdd, but they aren't bug fixes. 
<warptangent>  two sets of bug fixes not yet added though 
<fluffypony>  ok if they're not considered crucial for 0.9.x then we can put them into dev? 
<hyc>  warptangent: since I've been working on the same thing, I guess I should take a look at your stuff 
<warptangent>  1. berkeleydb support for importer - almost ready, some argument usage cleanup 
<moneromooo>  Once I re-merged then 
<hyc>  but I don't consider anything I'm looking at now as bug-fix 
<fluffypony>  (this is how we meeting https://i.imgur.com/OR5ZVoI.jpg
<warptangent>  2. finish hf fix for importer - mostly done, pending some cleanup with bdb 
<fluffypony>  hokay 
<hyc>  (I have a wineglass here too, sadly empty) 
<warptangent>  hyc: yes, that would be good. i think i mentioned the tx changes last month to avoid as many subdbs with tx hash keys 
<fluffypony>  also I think the thing that's holding up a general move of effort to dev is that we haven't bundled CZMQ / 0MQ in source, which makes compiling a bit painful 
<fluffypony>  any objections to the bundling? 
<luigi1111>  how much of a pain is it to change formats? 
<hyc>  I haven't even looked at dev. no objection from me 
<fluffypony>  luigi1111w: mostly just requires copying data to a new table and nuking the old one 
<moneromooo>  Hmm. I have a few patches to czmq, to make things build. 
<moneromooo>  Not super sure whether it was me being dumb or not though. 
<fluffypony>  ok well moneromooo, maybe post-bugfix do you want to do the merge from master to dev, and then plonk those patches on? 
<fluffypony>  I'll get it in the source tree the meantime, and cmake-ify all of the things 
<moneromooo>  I'll merge yes. Then you can add zmq to the cmake stuff Tongue Then I'll add my patches if they're still needed. 
<moneromooo>  Great, ty 
<fluffypony>  great minds think alike 
<fluffypony>  ok next I'd like us to chat about a style guide 
<fluffypony>  we've been working on one in Kovri that we can possibly use for Monero 
<fluffypony>  https://github.com/monero-project/kovri/blob/master/CONTRIBUTING.md#style 
<hyc>  oh, I do have one outstanding - tweak to BlocchainLMDB::get_estimated_batch_size - change batch_safety_factor to get blockchain_import to succeed on 32bit 
<fluffypony>  not necessary to read the style guide now, just more a general sense of if everyone is comfy with a style guide, and if anyone has any particular preferences   
<smooth>  i have no objection to any reasonable style guide but i do object to re-styling of existing code 
<moneromooo>  Pages and pages of stuff ? :| 
<moneromooo>  I object too, if it's only restyling for the sake of it. 
<fluffypony>  ok so more of a restyle-as-you-go   
<moneromooo>  That massive reindent patch already caused me grief 
<fluffypony>  which is in line with our refactor-as-you-go approach 
<ArticMine>  Apply the style guide to new code 
<smooth>  imo the best policy is keep the style on small chages to existing code and new style on new code 
<smooth>  there is probably a gray area there 
<warptangent>  should we assume from this point on the code is indented like the majority of the code so far - 2 spaces, not tabs, not 4 spaces. 
<hyc>  agreed 
<fluffypony>  warptangent: that's the one area where we differ from Kovri, I'd lean towards yes 
<moneromooo>  I tend to keep the style of whatever I'm hacking on. And I doubt I'll read all that google style guide thing. I'd prefer we use common sense. 
<warptangent>  moneromooo: style on the current project though, not different styles per file, right? 
<moneromooo>  Whatever code I'm modifying. 
<moneromooo>  It causes the least problems. 
<fluffypony>  moneromooo: don't worry about the Google style guide, the 16 points we've put in for Kovri are more what I was referring to 
<warptangent>  the majority of files are one style in the codebase, with a few that became some kind of hybrid at one point 
<moneromooo>  Oh OK. 
<moneromooo>  With that out of the way... 
<fluffypony>  ok - everyone happy with that as a general starting point? I can dump those points in and then we can take pull requests on it if anyone wants to refine / change things 
<warptangent>  yes, seems good 
<hyc>  I would push harder on "code should go in a .cpp not .h" 
<fluffypony>  hyc: agreed 
<fluffypony>  I'll make it clearer 
<fluffypony>  moneromooo: did you want to raise a point, or were you saying we can move on? 
<hyc>  overall it looks sane to me 
<moneromooo>  I'm good. 
<fluffypony>  ok   
<fluffypony>  next point is also administrative in nature 
<fluffypony>  we'd like to adopt the Collective Code Construction Contract that 0MQ uses, as a guide for project administrators and for contributors 
<fluffypony>  http://rfc.zeromq.org/spec:22 
<fluffypony>  we can discuss it more in future, but the long and the short of it 
<fluffypony>  is that we merge every PR as long as it doesn't break the build 
<fluffypony>  if it does something bad / dangerous we can have a follow up PR to revert 
<fluffypony>  but the aim is to avoid PR-hell where everyone comments on a PR for days and weeks and it never gets merged 
<fluffypony>  because it's never "perfect" 
<fluffypony>  so merge, create issues on Github where something is lacking (eg. new feature, little or no tests - create issues for tests) 
<moneromooo>  This PR-hell problem's never happened, has it ? 
<fluffypony>  moneromooo: not in Monero yet, but Bitcoin is chock-full of it 
<gingeropolous>  ^ this is for dev branch, right? 
<moneromooo>  I think common sense is again a better thing than going the opposite extreme. 
<fluffypony>  gingeropolous: this is in general 
<warptangent>  i haven't read the zeromq document thoroughly, but does it leave room for the common sense aspect? 
<fluffypony>  moneromooo: the problem is that there are lots of nuanced situations where "common sense" isn't that common :-P 
<smooth>  i dont think there should be an arbitrary merge policy on master, but it is already stated by me that i dont think anything but tagged releases should go on master 
<moneromooo>  Well, if it's nuanced, fine. 
<fluffypony>  warptangent: it does, yes 
<fluffypony>  as explained by Pieter to binaryFate and I last year 
<smooth>  if the concept of only taggest releases on master is no adopted then i would oppose going even further in the other direction 
<smooth>  *tagged 
<fluffypony>  smooth: yes that's a given 
<fluffypony>  master represents a stable, tagged release 
<fluffypony>  we work in dev 
<fluffypony>  anyone that submits a PR to master gets it closed and asked to submit it to dev 
<fluffypony>  anyway what I wanted to say, is that Pieter explained that the reason that you want to merge-all-of-the-things and then revert something bad is that you have a historical record of the bad actor   
<smooth>  there needs to be a place for bug fix releases though 
<binaryFate>  I'm with you fluffypony. 0MQ founder/leader feedback on this approach was extremely valuable. 
<moneromooo>  There's also the potential thing about not being able to use the 0mq version in time for the next 6-month fork. It wasn't exactly usable yet last I hacked on it. 
<binaryFate>  Common sense might work now, long term with a higher market cap we'll face same issues as btc 
<binaryFate>  Where common sense diverges and the code Base ossifies 
<xmrpromotions>  As a non programmer smooths comment seems like the safer approach. Thank you for clarifying the master vs dev branch issue fluffy. http://rfc.zeromq.org/spec:22 sounded scary as applied to PRs sent to master before dev 
<fluffypony>  smooth: it doesn't preclude it 
<fluffypony>  moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine 
<binaryFate>  What's the envisionned time scale for ringct? 
<smooth>  the idea of a historical record is good 
<hyc>  we have similar issues with OpenLDAP - you need 3 branches 
<hyc>  one for dev, one for released code, and one for release bugfixes 
<smooth>  but i would make the case then that 0MQ should be reverted since it is unusable 
<hyc>  particularly when dev and release are far apart 
<smooth>  im not actually proposing this because i know it would be a mess, but making a point for the future 
<hyc>  like now, where dev has 0MQ and release doesn't 
<fluffypony>  smooth: I agree - moneromooo and I will play around with it next week and make a decision   
<moneromooo>  Reverting isn't really possible. 
<fluffypony>  moneromooo: we could drop dev and re-branch 
<moneromooo>  But one could add ringCT to a new branch based on master. 
<fluffypony>  if it came to that, I mean 
<moneromooo>  That'd be a lot of pain. I'd rather not. Much better to hack on master and merge do dev again. 
<fluffypony>  ok 
<smooth>  imo something like zeromq should be developed on a separate branch somewhere, until it is actually usable 
<moneromooo>  s/on master/on a branch based off master/ 
<fluffypony>  smooth: it was usable-ish, we might have regressed some in fiddling   
<moneromooo>  Yes, that. 
<fluffypony>  anyway - let's evaluate and figure out 
<moneromooo>  I think I added all missing RPC so it cn be used, just not by people who want it to work without problem. 
<dnaleor>  **<fluffypony> moneromooo: as it stands we're probably going to push the fork date out a little to see if we have enough room to work on RingCT, so that's fine <= I welcome this. Just wanted to say that imho it's important to have RingCT active in the september/october hard fork. Carry on. i'm watching 
<hyc>  doing all new work in dev is fine, but backporting bugfixes to release will become non-trivial as more features are added to dev 
<fluffypony>  hyc: I guess it depends on the importance of a bug fix 
<moneromooo>  It looks to me like ring CT is going to need a lot of changes to bitmonerod/CN. September looks very close. 
<fluffypony>  we'll see   
<fluffypony>  I don't think we need to create a pressure-cooker for it 
<fluffypony>  ok can I go on? 
<ArticMine>  There are trade offs here. I see problems if dev and master deviate materially 
<xmrpromotions>  it seems like 3 branches as smooth mentioned would be easiest for everyone in long run even if it requires more effort now. 1.dev 3. release and bug fixes 
<fluffypony>  xmrpromotions: otoh we can backport fixes straight into master to allow for immediate testing by affected parties 
<ArticMine>  With bug fixes as a transition from dev to master 
<fluffypony>  again depends on the nature of the bugfix   
<fluffypony>  like warptangent's work on BDB and the importer probably aren't critical enough to go into master 
<warptangent>  the importer works properly when it has the hard fork support though, and that uses the bdb support 
<moneromooo>  If someone wants to rewrite that hard fork code, btw, you're welcome. I don't like it, and I'm not sure how to improve it. 
<ArticMine>  My concern is master deviating materially from a quasi stable dev 
<fluffypony>  ArticMine: something like ringct would have to be done in both master and dev 
<ArticMine>  So a project based on master would need a major rewrite after a tagged release 
<fluffypony>  we did dual-PRs for a while 
<fluffypony>  we can do them again 
<fluffypony>  might be easier than The Grand Merge 
<smooth>  something like ringct should only be in dev imo 
<ArticMine>  Yes anything fundamental has to be done in parallel 
<smooth>  until it gets released of course 
<fluffypony>  I think let's defer further discussion of this till the next meeting 
<luigi1111>  agreed to both 
<fluffypony>  we don't have enough info on the ringct effort or on the state of the dev branch right now anyway 
<binaryFate>  One thing I miss in discussion is what is master purpose? Do we want to encourage users to compile from it? How is master gonna diverge from tag release between them? 
<ArticMine>  I agree and lets carefully review the zeromq rfc in the meantime 
<moneromooo>  I think large things should go to their own branch (ie, ringct). Smaller things can share branches (to dev). Both end up being merged to master when ready. 
<fluffypony>  binaryFate: no matter what we say people clone and build master 
<gingeropolous>  **<- this guy 
<fluffypony>  it doesn't matter how much we encourage building a tagged release 
<fluffypony>  so we made a decision ages ago that master would be stable 
<fluffypony>  so that anyone pulling and building master doesn't get some hacky, broken branch 
<binaryFate>  Ok 
<fluffypony>  moneromooo: I don't know if we want topic branches in the main repo, but perhaps a more generalised "staging" branch, as long as anything going to that is also PRd to dev 
<moneromooo>  It can be in any repo. 
<smooth>  i think not in the main repo is fine 
<moneromooo>  Like I was hacking on tewinget's branch for a while. 
<fluffypony>  yeah that's a good point 
<luigi1111>  +1 
<fluffypony>  as long as that person is around and accepting PRs it's perfect 
<warptangent>  then one big PR to dev when it's ready? 
<moneromooo>  If we go to a dev/master setup, how does dev get merged to master anyway ? 
<warptangent>  that has worked before, yes 
<hyc>  yeah, keep main repo relatively clean 
<luigi1111>  a new feature can get a sort of "lead dev" 
<fluffypony>  moneromooo: when we release we merge from dev to master and tag master 
<luigi1111>  and contributers can hack on his repo 
<moneromooo>  So master becomes a copy of dev at that point ? 
<fluffypony>  yes 
<ArticMine>  Yes but a six month cycle could be too long 
<smooth>  thats a different issue 
<smooth>  how often to have major releases 
<fluffypony>  we can do major releases whenever, as long as we have major fork releases every 6 months 
<smooth>  also are releases time based or feature based 
<luigi1111>  kinda both ? 
<fluffypony>  yeah both 
<hyc>  feature-based is all that makes sense to me 
<ArticMine>  The merge to master may need to be more frequent than major fork releases 
<moneromooo>  feature based, but the rolling hard fork also pulls time based I think. 
<fluffypony>  yes 
<binaryFate>  Those Dev -> Master merges would happen with what kind of tagging? Point fix? Even more frequent? 
<fluffypony>  binaryFate: depends on how stable dev is 
<luigi1111>  so new features thus shouldn't be in dev until they are working properly/ready for release 
<luigi1111>  because of timed releases 
<smooth>  time based means that if you have 6 features in progress and one doesn't work in time, you do the release anyway, without the unfinished feture 
<fluffypony>  smooth, luigi1111: yes, you're both right 
<luigi1111>  it works as long as the half finished feature isn't partially merged 
<luigi1111>  or whatever 
<fluffypony>  the only reason 0MQ got pushed to dev anyway was because oranjuice could no longer work on it, and it was basically done 
<fluffypony>  but I think let's make it the last time that happens 
<fluffypony>  then we avoid complication 
<warptangent>  ok 
<moneromooo>  tbh I'd be tempted to not really care about people building master. If it's said clearly to use a release if you don't know what you're doing, then it's your problem. 
<smooth>  i agree with ArticMine that we can have releases sooner than 6 months 
<gingeropolous>  ah ok. so how the 0MQ happened is not how it will be in future 
<binaryFate>  Agree with moneromooo 
<fluffypony>  ok guys we're running overtime, so let's drop this for now, we can pick it up again later 
<smooth>  i think it is simply unnecessary to merge to master 
<smooth>  er sorry, commit unreleased stuff to master 
<moneromooo>  I think one of the problems with 0mq is that oranjuice kinda left 
<smooth>  any developer can handle getting the latest stuff from someone ele 
<smooth>  *somewhere else 
<moneromooo>  So it jsut had to be merged 
<ArticMine>  Let get back to this question at the next meeting 
<fluffypony>  ok 
<fluffypony>  last two things   
<smooth>  yup 
<fluffypony>  the first is that we have some major efforts coming up, besides ringCT, and things like epee, the 3 (THREE!!!) different logging systems, and a bunch of unused stuff is going to get in the way 
<fluffypony>  I'd like us to decide whether we want to keep hacking around things 
<moneromooo>  Does epee really get in the way ? 
<fluffypony>  or if we want to spend the effort now dumping this stuff for things that are easier 
<hyc>  it makes 32bit builds murder. but if we can abandon 32bit, that problem disappears too 
<moneromooo>  epee does ? 
<hyc>  yeah 
<fluffypony>  moneromooo: yes it does; it made QoS an absolute nightmare to do 
<fluffypony>  and it's still not done properly 
<moneromooo>  We'd have a replace a lot of stuff. 
<ArticMine>  32bit especially on windows is going to be around for a long time 
<dEBRUYNE>  + TAILS 
<moneromooo>  And a lot of somewhat low level stuff. 
<warptangent>  the multiple logging systems situation is strange, but i don't think it's interfered with current work. is there any knowledge on rfree's likelihood of returning? 
<fluffypony>  warptangent: low to impossible at the moment 
<fluffypony>  I mean, we can rip and replace the logging stuff with boost::log 
<fluffypony>  all the console stuff can go ncurses or similar   
<smooth>  id be more in favor of specific items like that, done on feature branch 
<fluffypony>  and the wire protocol can go ZMTP, since we have a 0MQ dep anyway 
<fluffypony>  eventually we'll get to a point where we're no longer reliant on epee 
<moneromooo>  I agree with the bit by bit approach. 
<warptangent>  that sounds manageable 
<fluffypony>  also then we'll actually have usable Doxygen docs 
<smooth>  the thing to bear in mind is this has virtually zero end user benefit, if not actually zero 
<fluffypony>  yes 
<fluffypony>  on the flip side, we can plug the GUI in via 0MQ instead of monero-as-a-library 
<moneromooo>  Well, the benefit is said to be for 32 bit users. 
<fluffypony>  so we have a shortcut of sorts there 
<fluffypony>  (in terms of users clamouring for stuff) 
<fluffypony>  moneromooo: and long-term viability   
<fluffypony>  we've had potential contributors ask for an architectural doc for the code, and get turned off when there isn't one 
<fluffypony>  so there's scope to slowly bring the codebase in line 
<smooth>  i dont believe there is anything about the current code that precludes a GUI. After all, BBR has one with basically the same code. 
<hyc>  huh.. contributors that are turned off so easily ... I wouldn't expect much use out of them if they stayed 
<moneromooo>  I was kinda thinking that too... 
<fluffypony>  I guess, but tbh it does make the project seem significantly less mature 
<fluffypony>  which I guess is fair, it's not even 2 years old 
<gingeropolous>  less hurdles, more good 
<smooth>  it is somewhat hard to come up to speed with the code, i would agree with that 
<fluffypony>  alright 
<fluffypony>  last thing so we can wrap up 
<fluffypony>  I just wanted to deeply thank everyone who has contributed and who continues to contribute to Monero development, whether it is Monero's core, the website, any other peripheral projects 
<fluffypony>  both on behalf of the core team, and on behalf of the community   
<fluffypony>  you all do an amazing job, and we've done a truckload of work in 2014 and 2015 
<fluffypony>  so here's to an amazing 2016 
<gingeropolous>  hear hear! thank you fluffypony for herding the cats so good 
<Bassica>  hear hear! 
<xmrpromotions>  thank you! 
<ArticMine>  Thanks for all the good work 
<fluffypony>  thus concludes the first meeting, next one in two weeks 
<warptangent>  thanks fluffypony 
<luigi1111>  thanks 
<binaryFate>  Thanks to you fluffy (enjoy that wine)! Thanks to all of you, awesome community. 
<dEBRUYNE>  Thanks fluffypony! 
<hyc>  **<glug> thanks all 
<Infinite_Jest>  is there a buffet? 
<fluffypony>  Infinite_Jest: snacks will be served in The Grand Ballroom in 15 mins 
<Infinite_Jest>  ok great Smiley but seriously thanks! 
<cardboardoranges>  thanks fluffy

Is a summary of the key points of the discussion available?

Bitcoin is NOT anonymous: http://www.bitcoinisnotanonymous.com
Pages: « 1 ... 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 [624] 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 ... 2187 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!