nixers
nixers community git - Printable Version
+- nixers (https://nixers.net)
+-- Forum: General (https://nixers.net/Forum-General)
+--- Forum: Community & Forums Related Discussions (https://nixers.net/Forum-Community-Forums-Related-Discussions)
+--- Thread: nixers community git (/Thread-nixers-community-git)
Pages: 1 2 3

RE: nixers community git - Tmplt - 21-07-2017

(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.

RE: nixers community git - z3bra - 21-07-2017

(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?

RE: nixers community git - Tmplt - 21-07-2017

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

Any specific reason? Not supported by quark?

RE: nixers community git - acg - 21-07-2017

(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'.

RE: nixers community git - z3bra - 21-07-2017

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.

RE: nixers community git - z3bra - 25-07-2017

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?

RE: nixers community git - jkl - 25-07-2017

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

RE: nixers community git - z3bra - 25-07-2017

(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

RE: nixers community git - jkl - 25-07-2017

(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.

RE: nixers community git - z3bra - 25-07-2017

(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.

RE: nixers community git - jkl - 25-07-2017

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

RE: nixers community git - z3bra - 25-07-2017

(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.

RE: nixers community git - jkl - 25-07-2017

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

RE: nixers community git - pizzaroll1 - 25-07-2017

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:

Code:
TODO
----

assigned
----------
* fix compiler warnings (assigned to z3bra)
* port to openbsd (assigned to kaashif)
* write a man page (assigned to jkl)

not assigned
-----------
* port to minix
* write new feature x



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

Code:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCtG7r+Zz7KBxxaBSIl78R3yVBHJLIBx+THqLX82n30Zp8VEbSeEKnyJFGMg8qf9YgxW3S4MuQACMjIOhubdA3QgT/lCiIJFEozPNj+IcwROQzIWjCWQuBowc21GHcceRVrlbCWHLo+IDZHZiKOSanacmBnKhxifVmmY74X2v6FzIV5Aya2t/bLyCEmd9Vw9RzabG3Jsnq05N5U929fsv6DjIzFMYJYBRjgK4uzdZYrJDfL97fy8CE/UHZG5yo2wcvayh7Fc09DcCCIv3TchH7D23/HnQbjD4sOmqvjlvYCdXHF4y0mOQpK4GnBFgOvW8sdtOZdCWfp6LOox9Q3xMKp kaashif@thinkpad-t61


RE: nixers community git - z3bra - 25-07-2017

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!

RE: nixers community git - evbo - 25-07-2017

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

RE: nixers community git - acg - 25-07-2017

(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.

RE: nixers community git - jkl - 25-07-2017

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

RE: nixers community git - pizzaroll1 - 25-07-2017

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.

RE: nixers community git - z3bra - 26-07-2017

(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.

RE: nixers community git - z3bra - 26-07-2017

A few heads up:


RE: nixers community git - robotchaos - 28-07-2017

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

RE: nixers community git - z3bra - 28-07-2017

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)

RE: nixers community git - robotchaos - 28-07-2017

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?

RE: nixers community git - z3bra - 28-07-2017

(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:
Code:
$ git checkout -b alice-fix
$ git pull git://alice.server.tld/project.git
$ git diff master
$ git checkout master
$ git merge alice-fix
$ git push origin ssh://bob.server.tld/var/git/project.git

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.

RE: nixers community git - robotchaos - 28-07-2017

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

RE: nixers community git - pizzaroll1 - 01-08-2017

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)

RE: nixers community git - z3bra - 02-08-2017

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

RE: nixers community git - r4ndom - 02-08-2017

(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.

RE: nixers community git - z3bra - 02-08-2017

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!).