IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 5e8ff010a1.
This broke all the URLs, we can't have that. (And actually, we probably don't
_want_ to make the change either. It's nicer to have all the pages in one
directory, so one doesn't have to figure out to which collection the page
belongs.)
- Mention "/please-review" in the contributing guide
- Remove "needs-rebase" on push
- Don't add "please-review" if a green label is set
- Don't add please-review label to draft PRs
- Add please-review when a PR moves out of draft
The text made it sound like breaking ABI in libsystemd is allowed with good reasons.
In fact, we plan never to do this, so make the language stronger.
Also remind people about distro forums for reporting bugs. Those are probably a
better place than systemd-devel for new users.
Also, add some missing articles and apostrophes, fix URLs, remove repeated phrases,
etc.
The linked filter gives an up-to-date list of pull requests that need review.
(Yes, there's too many.) We used to set 'needs-review' label, but that is
not available to non-members, and also every pull requests which is not labeled
'reviewed/needs-rework'/'ci-fails/needs-rework'/'needs-rebase' can and should
be reviewed.
If this is merged, I'll drop the 'needs-review' label.
A few related changes: be explicit that 'main' is the branch we're referring
to. There was a case recently of somebody rebasing on 'master' by mistake.
It's better to be explicit, since 'main' is still not the default for git
(AFAIK).
Also, github seems to send mails about force-pushes, so drop that as a
justification. Commenting about changes that were done is useful even if
github were to send a notification.
And finally, $subject. We do that ourselves, but outside contributors might not
know that that's expected.
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
In the past, we asked people to open a security bug on one of the "big"
distros. This worked OK as far as getting bugs reported and notifying some
upstream developers went. But we always had trouble getting information to
all the appropriate parties, because each time a bug was reported, a big
thread was created, with a growing CC list. People who were not CCed early
enough were missing some information, etc.
To clean this up, we decided to create a private mailing list. The natural
place would be freedesktop.org, but unfortunately the request to create a
mailing list wasn't handled
(https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/134). And even
if it was, at this point, if there was ever another administrative issue, it
seems likely it could take months to resolve. So instead, we asked for a list
to be created on the redhat mailservers.
Please consider the previous security issue reporting mechanisms rescinded, and
send any senstive bugs to systemd-security@redhat.com.
It turns out Jekyll (the engine behind GitHub Pages) requires that pages
include a "Front Matter" snippet of YAML at the top for proper rendering.
Omitting it will still render the pages, but including it opens up new
possibilities, such as using a {% for %} loop to generate index.md instead of
requiring a separate script.
I'm hoping this will also fix the issue with some of the pages (notably
CODE_OF_CONDUCT.html) not being available under systemd.io
Tested locally by rendering the website with Jekyll. Before this change, the
*.md files were kept unchanged (so not sure how that even works?!), after this
commit, proper *.html files were generated from it.
The GitHub guide on contributing file says: "Decide whether to store your
contributing guidelines in your repository's root, docs, or .github directory."
https://help.github.com/articles/setting-guidelines-for-repository-contributors/#adding-a-contributing-file
But there's really no advantage to keeping it in the hidden .github/, since
these are public and really belong together with the other documentation.
We can still keep the issue templates under .github/, since they are not really
documentation on their own.
Updated the links pointing to CONTRIBUTING.md to refer to the one in docs/.
