On 5/27/20 2:46 PM, Schanzenbach, Martin wrote:
> Here, a message of "fix #1234" is NOT sufficient.
> I have done so myself and have found ~50 in the current log since 0.12.1.
> Those are not useful messages. Having to do to mantis to check the changes
> meaning
> is quite annoying. Especially if
On 5/27/20 1:58 PM, Daniel Golle wrote:
> Yes, let's please establish something like that. I've tried my best
> myself, but that's like 0.01% of GNUnet commits -- and of course,
> as was pointed out in a previous debate on that, GNUnet is not the
> Linux kernel and experimentation becomes very
Hi *,
On 4/19/20 5:31 PM, Alessio Vanni wrote:
> In my opinion, a nicer approach could be something based on Java's
> Buffer object from the NIO package. For example (again no error
> checking; also the names could use some more work):
We already have something exactly like that:
binary doesn't exist). But that's not really that bad.
- Florian
On 9/24/19 11:22 AM, Christian Grothoff wrote:
> On 9/24/19 11:14 AM, Florian Dold wrote:
>> Hi *,
>>
>> I ran into two usability issues with GNUnet's arm:
>>
>> When a service couldn't be executed at all be
ut that's not really that bad.
- Florian
On 9/24/19 11:22 AM, Christian Grothoff wrote:
> On 9/24/19 11:14 AM, Florian Dold wrote:
>> Hi *,
>>
>> I ran into two usability issues with GNUnet's arm:
>>
>> When a service couldn't be executed at all because the binary d
Hi *,
I ran into two usability issues with GNUnet's arm:
When a service couldn't be executed at all because the binary doesn't
exist, arm logs a message at the *info* log level. This means the
message usually won't be seen *anywhere*, since the info log level is
too verbose and thus supressed.
19 2:44 PM, Hartmut Goebel wrote:
> Am 18.04.19 um 14:31 schrieb Florian Dold:
>> I am curious why this file had to be committed *individually* to every
>> repository, including the wallet and python repositories? It's
>> completely useless for these projects
>
> As y
Hi Hartmut,
It's a bit disheartening to see an honest attempt to improve things
being shot down like this.
The clang-format style that Martin created tries to mirror what style
the existing codebase already has or is supposed to have. If you want
to make any tweaks on top of that, please
On 4/10/19 1:10 AM, Raphael Arias wrote:
> I don't see why the database of a read-only legacy system would need to
> be regularly backed up. If it remains online purely as an archive
> (possibly with a note to go see the gitlab issue tracker) history is
> preserved while not forcing anyone to do
> No, we don't. We dvn et al are faced with unreasonable requirements for the
> use of gitlab which include:
>
> - Migration of Mantis issues -> completely unnecessary. Mantis could remain
> read-only for the "legacy" issues and gitlab used for new issues.
> - No user forks, no pull requests ->
On 4/7/19 6:46 PM, Schanzenbach, Martin wrote:
> The CAA does not help in any way. You are still liable as a platform. It has
> literally nothing to do with the copyright infringements if the contributor
> copied code from somewhere else. You cannot delegate this responsibility
> anymore to the
, Florian Dold wrote:
> On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
>> Contributors should be able to do anything they want in their own namespaces
>> including committing code that does not compile (e.g. for their gnunet.git
>> forks).
>> However, in order to get it int
On 4/7/19 8:33 AM, Schanzenbach, Martin wrote:
> Contributors should be able to do anything they want in their own namespaces
> including committing code that does not compile (e.g. for their gnunet.git
> forks).
> However, in order to get it into the "main" gnunet project codebase, the CI
>
Thanks for taking the time to set this up. So far some things don't
seem right yet:
There is a massive security problem. Everybody (!!) is able to create
accounts and set their password, *without* being the owner of the
respective email address. As "proof", I've been so friendly to create
an
On 3/19/19 6:55 PM, Christian Grothoff wrote:
> On 3/16/19 10:32 PM, Florian Dold wrote:
>> The model of "nobody should push to master" is great if you have the
>> right tooling on the server, but breaks GPG signing of commits by the
>> author, AFAICT.
>
On 3/19/19 8:05 PM, n...@n0.is wrote:
> Christian Grothoff transcribed 5.4K bytes:
> See my last message and read it. It depends on if this
> is applicable. I'll spend tomorrow looking into the 2
> codebases and deciding on if/how this can be applied
> for us.
Please see
I agree with what you've said about not encoding hierarchies in
gitolite. I also think that either nobody or everybody should be able
to merge into master.
The model of "nobody should push to master" is great if you have the
right tooling on the server, but breaks GPG signing of commits by the
On 2/10/19 1:55 PM, Schanzenbach, Martin wrote:
>> An example for such
>> tooling would be Googles's Repo tool
>> (https://source.android.com/setup/develop /
>> https://source.android.com/setup/develop/repo).
>
>
> Actually, google is an example for a proponents of monorepos. So your point
>
From my experience with working on GNU Taler, I tend to agree with the
arguments *against* multirepos, especially for GNUnet.
Multirepos tend to work well if either:
a) The language you're using has support for project-local package
dependencies. This is the case for JavaScript (with npm/yarn),
I'm not the biggest fan of texinfo either, but it works.
mandoc looks like a terrible replacement, and I strongly disagree with
your proposal of switching to it.
When comparing the documentation of mandoc/mdoc
http://mandoc.bsd.lv/man/mandoc.1.html
http://mandoc.bsd.lv/mdoc/
to GNUnet or
On 08/01/2018 06:23 PM, Nils Gillmann wrote:
> I just responded to an off-list message from Christian with an example of
> someone I study with. I think they are younger than I am, and have some
> but not too much experience with Free Software. Not a complete beginner.
> I had to point them to the
I agree that we should not encourage or endorse using proprietary code
hosting sites such as GitHub. I'm strongly against accepting contributions
on GitHub. Even if the Gentoo project decided to do that, it remains a bad
idea. The furthest we could go is have a read-only mirror with issues, pull
22 matches
Mail list logo
