Btw we are on Google 
I mean, Google is still taking my data to show this, but this is definitely an ad. I checked.
Yes from me.
No with veto !This is only step to easier merge with Luna !
1 Like
I have similar concerns to [Exoneratelarouche]. We have a few validators that are also YouTubers who should NOT be given more powers. These Youtubers are embarrassing the LUNC community with the constant talk of pumps, to the moon, or bitterness about marketing. If we want to be taken seriously something has to change with this “influencers”
1 Like
Basically ‘If it ain’t broke, dont fix it’. The system we used works. The only issue there is seems to be ex-TR team vs TR team unable to get along.
Imo its enough if both parties communicate and grant access to the L1 Team.
4 Likes
That would be nice. Unfortunately it is broke and it needs fixing. We cannot afford having the L1 team held hostage by the Terra Robbers which are no longer / probabaly never have been interested in Lunc success. Their focus is exclusively their private wallets. We need to clear the path for those with a broader vision for LUNC than how to rip off the community.
2 Likes
With what LUNC has experienced in recent past, not once but twice, we should not have any central canonical repository.
TargetNodes votes YES
1 Like
@ek826 can we get a follow up on when you’re putting this to a vote? It’s been almost four months and this proposal hasn’t gone to vote yet.
5 Likes
You still agree with this statement now?
@ek826, I’ve sent you a message on Discord about this prop, but haven’t heard back from you…
It’s been 4+ months since you opened this thread… and this prop was an item in the L1JTF’s Q1 deliverables list. IMHO it’s long overdue you sent it up for a vote.
Or is LUNC now completely under TGF control to the exclusion of anyone else?
6 Likes
I vote against, with the possibility to review this proposal in 2 years in the future, at the moment this decentralization will lead to centralization between programmers and validators, a small conspiracy suggests, in short, it is a fatality, in the future I also want to try to become a validator, and for some reason it seems , that the repository should be one and should be updated as always, I don’t see any problem in changing this information about the kernel, namely its location. (dangerous for the project, leave it as is.)
Let me tell you who submitted this proposal.
Frag-TCV best friend.
Pholuna-TCV best dog
Rexxaurus-who is this?maybe rexyz.
See?Still want to vote yes huh?
You’re wrong, it was Ed Kim who started the discussion back in January.
1 Like
No from me. I don’t think is the right time for this proposal. It will cause problems with validators and lower the security level. Let the L1 team concentrate on the parity in May and burn tax in June first. Prices have fallen to critical level and we may lost the L1 if we don’t work to push the price up. IMO, there is more cons then pros especially at this critical time. Both the validators and community is still not mature enough and may be lead wrongly by the validators.
3 Likes
It is my understanding that while commit hashes provide a way to identify a specific version of the codebase, they do not provide the same level of functionality as a canonical repo.
Canonical repo provides a way for multiple developers to collaborate on the codebase and manage changes to it over time. Wouldn’t just using commit hashes make it difficult to manage these aspects of the codebase?
IMO, commit hashes should not be used as a replacement for a canonical repo. For instance, while they can be used to track changes and revert to previous versions of the code, they do not provide the same level of access control as a canonical repo.
Is the canonical rep still the TR classic repo? If yes, why dont we change it?
This is Ed’s prop. Doesn’t matter who it was submitted by.
How? If anything, it’ll make the chain more secure, not less. Right now only TGF gets to decide what happens to the main codebase. If this prop passes that’s no longer the case.
This prop is in no way tied to that. Nor does the L1 team have to do anything if this prop passes.
And whose fault is that?
Re-read the prop again… carefully. It doesn’t say validators will lead the chain.
Yes but it’s still owned and controlled by a single entity - and that’s currently the TGF. This is completely antithetical to crypto and decentralization in general. No one who wants LUNC to succeed should want only one group to have control over it, regardless of who they are. Diversification and decentralized access makes the chain more secure, not less.
3 Likes
It is important to consider the potential security risks that may rear their ugly heads by voting “YES”.
Some are listed below. What steps will be taken to mitigate them?
- Unauthorized access
- Lack of access control
- Lack of accountability:
- Difficulty managing updates
Ed Kim is right. The was the leader of the L1 that the community once fully support. Since his departure, the L1 team lost support of over half the community
By Ed Kim:
"By voting YES**, you are communicating that you believe that there is no central canonical repository required for the Terra Classic blockchain, and you support the procedure of using code commit hashes (starting with the current code hash) as the preferred method of upgrading the blockchain.
By voting NO, you are communicating that you would like the canonical repository to stay as the Terra Rebel’s classic repository, https://github.com/terra-rebels/classic-core , or you would prefer that we propose to change the canonical repository instead."
Are we still a decentralized chain or not? This prop needs to pass if we want to claim that we are.
The problem is that you want to embark on a new method of deployment without having provided the full deployment lifecycle of releases, and the official engagement process between (distinct) development teams and validators.
i.e.
- How will the next team know which repo holds the latest hash release to clone and pick up development from
- Where is the release/hash information of a deployment stored for future reference
- How can we track the previous release to be used in fallback scenarios
- How is the official deployment release communicated to the Validators (Team)
All of the above might sound like semantics but a PROCESS need to be set to stone on the rules of engagement, so everyone understands how things work (Developers/Validators/Delegators)!
In the absence of the above, I lean toward the fallback option of getting everyone access rights in the TR GitHub. Ideally, one member of the current official Q? team working on the chain should be given management access rights on the relevant Repo to avoid a single team point of failure!
1 Like
It’s not safe for the chain, suggest something better. At the moment NO
2 Likes