>It breaks anything relying on `run-news`. For example if you have Anarki running as a systemd unit, you'll have to fix that.
Fair enough, although I would point out that, given that this is a language designed for experimentation with an open commit policy, breaking changes should be tolerated and expected if the end result improves the codebase, which in this case I believe it does.
Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course. We should be breaking things harder and more often.
And... people just have to fix it once. No one is suggesting a new hierarchy every week. Literally, just that applications should live somewhere other than /lib.
> It creates an overcomplicated folder hierarchy for the Anarki package manager, e.g. if you add a custom app through prompt.arc, it will now be in `anarki/apps/news/www/apps/[user name]/[app name]` rather than `anarki/www/apps/[user name]/[app name]`. Is it really necessary to have another `apps` folder inside the `apps` folder? Why?
The package manager should be updated as well, mea culpa. But that demonstrates that the forum should have been moved to begin with, since it didn't conform to that convention. Also /anarki/www/apps/[user name]/[app name] is more complicated than the convention I want to use, which is /anarki/apps/[app name].
> Perhaps when new stuff is added, it is fine to break things, but what new features does this commit bring, or what problem does it solve?
It solves the problem of the forum being in the same path as the library. Every other language with a web framework separates one from the other.
>Again, sorry for being negative here. Am I being unreasonable?
For the criticism? No, I'm the newb, my last commit was kind of garbage, I can take it and I welcome it.
For wanting to give up and switch forks because I moved some code into a new folder? I think that is a bit unreasonable. Try to meet me halfway here, I'm not just breaking stuff for the lulz.
The risk here is that everytime a newcomer tries out our codebase and finds it broken, we lose a potential recruit. And we don't have so much incoming attention that we can afford to be lax with it. Our situation is akin to a store that is mostly empty: we can't afford to just shut down longer, because that way lies death. We have to stay open for business.
Not allowing in obvious breakage is also a way to show respect for your collaborators, other people programming on the same codebase. When you come to Arc you would be demotivated if the news app didn't work, if you had to first get it working, figure out who broke it and how. It's the same with others. When we find a few hours to hack on something fun, we all prefer that it start out in a non-broken state. And we try to leave it in a non-broken state.
So I have a suggestion for you: everytime you create a PR, first try to break it yourself. Ask yourself what changed, and what it may affect. Try to catch the really obvious stuff yourself, like "does news load, does it look the same, can I submit a post?" Run the unit tests. Report in the commit message or PR what all you did by way of testing. These exercises will make you a better programmer. Tell yourself that the goal is to make changes in an efficient manner, solve the problem in a single PR, rather than require more changes to fix breakage in one change, that cause their own breakage, and on and on.
None of this is particularly serious. It's not like any breakage here is a deal-breaker. As long as others see you making an effort to get better I think you'll get a lot of support.
Certainly a lot of things could be tested more; this would help.
But also, we might want to set Github to require the tests to pass on a PR before letting it be merged. I could be wrong, but I think a PR can be merged even if the tests fail.
This is a slight step away from "anyone can commit anything", I acknowledge. But it's also a step towards stability. At least the person would have to fix or delete the failing tests before merging.
Ok. I will try to be more careful in the future. In fact, I won't even merge until someone looks at the commit, fair enough?
It isn't broken, though, at least not if "broken" implies an unusable state. I did test the forum before I pushed, I just didn't catch everything... I didn't even know prompt.arc existed, or what it was for, but apparently neither did you. ;)
But news does still work. It just doesn't work from the same location as previously, which I think is hardly setting fire to the store.
For what it's worth I agree with the app/news changes. So Good Job I say.
And with that said, after looking at the anarki directory it's apparently becoming a dumping ground for people to place files at the top level. I'm not sure why this is happening, but I hope others take a look at what you have done with app/news and continue the trend of organizing things better.
> We should be breaking things harder and more often.
That line of thinking is completely incompatible with my requirements as I'm using News for my own web page that sort of needs to work. Fork time, I guess.
Another option is to have stable branches/tagged releases.
As for "breaking things harder and more often". I don't think 'harder' has to happen 'often'. I'd be ok with 'harder' when need be with more 'often' being good.
This language has 3-6 people active users and maybe another 6-10 lurkers. More changes like the app/news change have potential to garner more users and more users means more changes which may lead to a fuller and richer language.
Having the news app so heavily integrated was a poor design choice to begin with. This is a language and the language development should not be constrained by a single application which is currently the case. That app needs to be a downstream consumer of the language.
Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
If we don't do this the language is dead for all but a hand full of hardcore arc lovers + news appers.
I think a stable branch is a good idea. People can experiment elsewhere while not stepping on anyone's toes.
>Ideally we can get to a point where you can just repo your own app and marry it with a tagged release while collectively the app users can report any breaking changes.
Currently, it looks like "apps" are mapped to an admin namespace and will only work for that user, so that would need to be changed to make them portable.
> I think a stable branch is a good idea. People can experiment elsewhere while not stepping on anyone's toes.
I think it's possible to experiment with things while still considering stability and backwards compatibility. I recently reworked the password hashing function, but I took care to not break the logins of every user, when doing that.
I must say I'm a bit upset by you being so apparently casual and careless about creating several breakages[0][1][2] in News that I've had to fix, and then suggesting that I should just get off the master branch if I don't like your "experimentation".
I will. I'm done with this.
Experimentation is not the same as carelessness. Seriously, WTF is this?:
You also made a bunch of breaking changes the repo a while ago. Because of those, I got more of the tests running under the Travis CI script to help us all monitor them without having to ask each other to remember to run them all the time. I really hope I didn't make you feel ashamed about that. You got to make changes, and I got to make changes, and I felt like the repo was better with both of those together. The same is true here.
I did break some things in Anarki, and I appreciate you spending time helping me fix those breakages and adding more automated tests. Thank you.
What bugs me here is not so much that stuff gets broken now and then, but this nonchalant attitude to breaking things, and lack of acknowledgement for others that have to wipe up the mess.
> And... people just have to fix it once.
> Given that is not a mature language or a stable framework yet, I would disagree that breaking changes, per se, should be avoided as a matter of course.
Also, I have a strong aversion to CAPTCHAs, partly because they're non-free Google SaSS, but also just because they are just plain annoying. Why would anyone want to inflict that upon themselves? There's already plenty of ways to deal with spammers in News.
And, quite unrelated, I'm not big on Github as their site requires non-free JS, and I'm particularly wary of them since they were bought by MS, so that is just one more reason to host the code elsewhere. So, I've forked Anarki, and we'll see what happens: https://notabug.org/hjek/knark
>What bugs me here is not so much that stuff gets broken now and then, but this nonchalant attitude to breaking things, and lack of acknowledgement for others that have to wipe up the mess.
You don't have to wipe up the mess. I didn't ask you to wipe up the mess, and I didn't expect you to. I also suspect you're conflating my beliefs about whether or not Anarki should be willing to make breaking changes when necessary with some general lack of regard for whether or not anything works at all, and that's not the case.
I'm new to lisps, to this lisp in particular, to this framework, and to working in a team. I admit (and have admitted) that I make mistakes and I've picked up some bad habits that I need to correct. If I know about an issue, I will gladly deal with it.
But, as to the specific issues you listed... I don't know what happened with the css (it worked for me when I pushed it but your comment that it might have needed testing in other browsers is correct,) but #104 wasn't broken, but misconfigured. And you've explained at length already why that entire commit was misguided, but it wasn't broken.
But sometimes I do miss things, forget things, there are some mistakes I might not even see because I'm working on Windows. But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.
That said, I stand by moving news, and I stand by my statement that we should be making breaking changes (with the caveat that those changes improve the code.) Now is the time to do that, when there are so few people actually using this codebase, as opposed to later when there might be dozens or hundreds, or never, simply because change is difficult to deal with. Chances are most of the entire universe of people using this fork in production are already in this thread. Moving news to a new folder shouldn't be a reason to create a hostile fork.
And that's why I agreed with i4cu's suggestion earler that a stable branch might be a good idea... which for some reason you interpreted as a personal attack,
"(...) and then suggesting that I should just
get off the master branch if I don't like your "experimentation"."
Rather than more charitably, that you should stay on the master branch and the unstable branch should be elsewhere, as I was actually conceding your point and agreeing with what I thought would be an equitable solution.
> You don't have to wipe up the mess. I didn't ask you to wipe up the mess, and I didn't expect you to.
I agree. That was my own expectation, and also I might have been wrong in expecting stability from a repo that's meant to be "extremely permissive in accepting patches."
> And you've explained at length already why that entire commit was misguided, but it wasn't broken.
That I don't agree with. I would consider a commit, that makes all links not work in the default config and prepends the site name to already absolute links, broken as well as misguided.
> But I am trying to make things better here. So thank you for cleaning up after me, and I will try harder in the future.
That's great. It's good to see work done on Arc. Looking forward to see where this goes.
> Moving news to a new folder shouldn't be a reason to create a hostile fork.
Let's just call it a fork, not a hostile fork, shall we? Also there's some other reasons listed in the readme of the fork.
I agree that we should hold ourselves to some standard about not breaking Anarki for each other.
It's our job, yours and mine and that of other long-time participants, to explain the norms that we have here. And to do it in a nice way, realizing that what's obvious to us isn't necessarily obvious to newcomers.
This is a pretty non-standard repo where anybody can make changes, so it's understandable that a newcomer may think stability is not important. We have to articulate precisely what sorts of stability are necessary and what we don't consider important. It's a tough job. So I really hope you stick around to help us out :)
I'm actually curious how you run a production service on Anarki. Everytime I ever tried to do that I would maintain a cutout in between that was wholly in my control, and decide what patches should flow from Anarki to it.
> So I really hope you stick around to help us out :)
Definitely!
> I'm actually curious how you run a production service on Anarki. Everytime I ever tried to do that I would maintain a cutout in between that was wholly in my control, and decide what patches should flow from Anarki to it.
Usually I'm trying out the latest commits on a local laptop before doing git pull on the server. Works fine. If it's broken for some reason, then I'll just do a `git reset --hard [known-good-revision]`, because the `www` folder with all the news data is outside the git tree anyway so it stays as it is (and no-one have yet been changing the data format, so that's not an issue either.)
I find it a lot simpler to manage than for example Wordpress (although Wordpress on the other hand has tons more featuers and plugins).
> Also, I have a strong aversion to CAPTCHAs, partly because they're non-free Google SaSS, but also just because they are just plain annoying. Why would anyone want to inflict that upon themselves? There's already plenty of ways to deal with spammers in News.
Languages allow people to make their own choices on what is worthy to build. Debates like this are why it's a shitty idea to have apps baked into the language.
> I find the border between app.arc and news.arc a bit murky.
It could just be the name that's offsetting you, but app.arc is an application library just like srv.arc is, only manages application ops/state instead of server ops/state. The best way to look at it is that app.arc, like srv.arc, can optionally be used by different applications (like news.arc, blog.arc or whatever), which is why it's under lib. Someone who wants to build an app, needs to know what libs can be used and those can be. They also need to know that news.arc is not a library to to use for a new shiny app they want to build and when they want to share their app where to put it. Right now the only place is under app/, and ideally (IMHO) we can move them out further someday.
Agreed. Yet it is also possible to imagine apps that could benefit from tighter coupling with News, e.g. to access user 'karma' and to integrate into the layout and navigation of News.
Also, the password reset email function in app.arc requires `this-site` to be set, but `this-site` is set in news.arc. I'm not sure how I'd go about fixing that.
So I could just put values (like site-url*) into app.arc with default settings and reset them from news.arc. Provided that it's utilized dynamically then all is good.
However lacking this functionality in arc I would just move the required config settings to app.arc and be done with it. You're still loading app.arc at the top of news.arc so the only real problem is app users need to know to change the settings therein (a comment would do).
News already has a repl and "apps" in prompt.arc, and I'm already working on getting them to work together. That could provide the basis for a plugin (app, what have you) system.
