(21-07-2017, 03:51 PM)pranomostro Wrote: Edit: It just keeps loading forever.

Does it work with another browser? If not, can you dig(1) it? Whenever something loads forever for me, it's usually a resolving issue.

(21-07-2017, 03:35 PM)Tmplt Wrote: Could a `change-owner <name> <owner>` command be added? And are there plans for SSL?

No plan for ssl. I though about the "change-owner" command already yeah. For now we'll keep it like this, to see how this service go. If people use it, we'll consider adding more commands..

(21-07-2017, 03:51 PM)pranomostro Wrote: Nice. However, I can't reach http://git.nixers.net, weird.

Edit: It just keeps loading forever.
Edit 2: Using Chromium 59.0.3071.115.

Weird indeed. What do you see in the console? Can you see the headers at least? Also, what does curl says? Did you try other browsers?

(21-07-2017, 04:41 PM)z3bra Wrote: No plan for ssl.

Any specific reason? Not supported by quark?

(21-07-2017, 04:41 PM)z3bra Wrote: Weird indeed. What do you see in the console? Can you see the headers at least? Also, what does curl says? Did you try other browsers?

I'm able to open it using Firefox and Surf, but on Qutebrowser it will say [5/5] loaded on statusbar and won't display.

I curl and the last line, after </html> says 'curl: (18) transfer closed with 1 bytes remaining to read'.

Eh, I guess the webserver is just too fast ;)

EDIT: It's a bug in quark(1). Content-Length is 1240 bytes while the file is 1239 bytes only. As quark(1) will be refactored in august, I'll wait until then for a good fix.

How should we stand regarding dev on this server? I think we need a set of "rules" to avoid clutering the project with useless commits, dead branches and such. For example:

• Always rebase branches
  
• Ask before pushing
  
• Never force push anything
  
• Keep commit messages clean and lean
  
• Ask project owner before pushing
  

What do you think?

Shouldn't project organization be left to the particular project lead dev?

(25-07-2017, 08:35 AM)jkl Wrote: Shouldn't project organization be left to the particular project lead dev?

It could yeah, but I think that having common rules within a single organisation makes it easier to manage, and makes the contribution process smoother. For example, there won't be any need for a "CONTRIBUTING" file, or questions about how to format patches and so on.
It could also remove any need for a "lead dev", as all projects would be managed the same way

(25-07-2017, 08:39 AM)z3bra Wrote: It could also remove any need for a "lead dev", as all projects would be managed the same way

You suggested to "ask project owner before pushing" above, so there still needs to be a certain "project lead" in place (which is OK because everyone probably started a project in order to have certain wishes fulfilled).

I, for one, would suggest reasonable publishing of unified TODOs to make contributing to different projects easier and more inviting. People tend to invent their own format for TODO lists.

(25-07-2017, 08:48 AM)jkl Wrote:

(25-07-2017, 08:39 AM)z3bra Wrote: It could also remove any need for a "lead dev", as all projects would be managed the same way

You suggested to "ask project owner before pushing" above, so there still needs to be a certain "project lead" in place (which is OK because everyone probably started a project in order to have certain wishes fulfilled).

That was not a fixed idea. I proposed that because it was what I had on my mind at this moment. I like the idea of having no project leader, but rather full-community projects.

My goal is to start a discussion and end up with a clear list of guidelines for project contribution.

(25-07-2017, 08:48 AM)jkl Wrote: I, for one, would suggest reasonable publishing of unified TODOs to make contributing to different projects easier and more inviting. People tend to invent their own format for TODO lists.

That's an idea I like. The more unified an interface is, the easier it is to get started with it.

In this case: I'd suggest Todo.txt or org-mode for that.

(25-07-2017, 10:21 AM)jkl Wrote: In this case: I'd suggest Todo.txt or org-mode for that.

Org-mode involves emacs specifically so I'd rather not use that.

org-mode is actually plaintext, perfectly editable with ed(1).
Also, https://github.com/jceb/vim-orgmode/

Just write a TODO file in some sort of format. When you're doing a task, add a note to it saying you're doing that task. Why does it need to be so complicated? This is just bikeshedding, it's not like the file has to be machine-readable. People inventing their own formats is a problem for computers, but people can read anything. What's wrong with writing some unstructured text like:




Also, can I have access? Here is my SSH public key:

Org mode is plain text, but with a strict format that is not pleasant to read. Its goal isn't to look readable as is, but rather to be a simple interface for a rendering engine. In this regard, I also find markdown better suited for the task as it's standardized, and readable as is.

I like what pizza is proposing, it's clear and simple. And that would be until we find a simple bug tracker ;)

@pizza, your key is on!

I agree with pizza, that's a good way to do it.

(25-07-2017, 12:46 PM)pizzaroll1 Wrote: People inventing their own formats is a problem for computers, but people can read anything. What's wrong with writing some unstructured text like

Up-vote for this. Markdown is easy to write, read and can be converted easily (i don't know why you'd do it in this case) since it's standarized.

Markdown explains text formatting, still nothing about the file structure...

Could you explain the benefits of using a structured file format? I don't think we'll be using frontends to this: everyone will edit and read the files in a text editor, so I can't think of any benefits to making it a well-structured machine-readable format. What do you plan to do with the TODO file? I thought the workflow was just:

1. someone writes some tasks in a file
2. people add their names next to the task to claim it
3. they add the task to a "done" list once they're done

Since it's just unstructured plain text, merge conflicts can be resolved easily since it's not like you have to produce a syntactically correct file, or preserve history, or anything: just put something in that makes sense to the person reading it.

This is like a NEWS file or CONTRIBUTING file, it's purely for the benefit of humans.

(25-07-2017, 06:01 PM)jkl Wrote: Markdown explains text formatting, still nothing about the file structure...

Dude please make some effort developping your ideas instead of criticizing things nonchalantly like you own the great truth.

A few heads up:

• quark(1) has been fixed
  
• git:// urls are now working
  
• Welcome text available at http://git.nixers.net/HELLO.txt
  
• GOPHER version of the releases folder will be up soon
  

Can I put up my code I'm learning with? I know it wouldn't be fun for you guys to go through, but a place for me to store it and get familiar with git. Trying to be like you guys

My first idea regarding this repo was to be for projects shared by community members, and not "personnal learning projects".
Not that I'm against the idea, but if everyone starts doing that, it might end up in a big mess of small abandonned projects.
That's only my opinion though, and this is the community git, so I don't have the last word on it.

If you want to get familiar with git, there is the motd.git repo which doesn't require anything more than common sense, and the ability to fit an ascii message in a 80 char wide file ;) Plus, you could hopefully see your motd when connecting via ssh if you're lucky enough! (/etc/motd is generated every 30 minutes by picking a random file in this repo)

That's a fair point. I wouldn't need the repo forever. I will keep my learning projects local and if they are ever ready to publish, then I will do so. No harm in this.

I mean I've used git privately for storing my pass repo and for my other coding projects. I was more so thinking of getting familiar with git collaboration. Pull requests, dev branches, etc. Which could all be done with that motd.git yes?

(28-07-2017, 02:12 PM)robotchaos Wrote: That's a fair point. I wouldn't need the repo forever. I will keep my learning projects local and if they are ever ready to publish, then I will do so. No harm in this.

I mean I've used git privately for storing my pass repo and for my other coding projects. I was more so thinking of getting familiar with git collaboration. Pull requests, dev branches, etc. Which could all be done with that motd.git yes?

First of all, pull requests is bullshit. It's a fancy word github coined to name external contributions. The real pull request is:

- "Hey bob, I forked your project and added something, care to check it out?"
- "Sure Alice, I'm all excited!"
Bob then issue the following, to review, and merde Alice's code:

What happened here? Alice requested Bob to pull her changes, to get them merged in the project.
An even simpler way to do that would have been to simply send a patch to Bob, so he could apply it.
But people want fame and glory more than working simplicity, so they create pull requests to get their avatar in a project history ;)

Basically, there's nothing more that push/pull to do on shared remote repositories.

Thanks for setting me straight on that. I thought that was the basic idea, but never collaborated with anyone, so was unsure.

Perhaps we could do something like what many projects do (e.g. OpenBSD, Linux, GNU, many many more) and have mailing lists for each project where people can send patches if they want them to be reviewed?

Actually I guess that is overkill, since we have a forum we could do that in. But I greatly support the practice of sending patches somewhere (forum, mailing list, wherever) and discussing them in public, where there will be a record of: what the patches were, how the review process changed the patches, what the discussion was etc. I think this is important for future contributors, so they can learn and make their contributions better.

Your example of Alice sending Bob patches is so simple you didn't even explain it, since it's trivially obvious what happens (they mail back and forth, Bob eventually is satisfied and applies the patches).

Recall that the Linux kernel is developed this way, so the tooling around emailing patches is excellent: look at git-send-email and git-am, for example. It sends the commit and applies it, preserving author, time data and GPG signatures too.

(Note: I am not specifically advocating for mailed patches, but just putting patches somewhere and talking about them as a group before applying them, at least for big patches adding lots of new functionality)

The idea of a mail list is appealing to me as well, as you can also get notified of new commits/releases/projects on the repo

(01-08-2017, 09:33 PM)pizzaroll1 Wrote: Perhaps we could do something like what many projects do (e.g. OpenBSD, Linux, GNU, many many more) and have mailing lists for each project where people can send patches if they want them to be reviewed?

I like it! It makes getting involved in project a lot easier.

I don't manage the nixers.net mail server though so we'll have to wait on venam for that. If needed, I can provide a temporary mail list with my own domain.

@venam, I'd vote for mlmmj for mail list handling. I can help you set it up if you want (it's insanely easy to do, really!).