As of 2 days ago:
SMTP is setup, and sign-up is re-enabled with email confirmation.
Git repos are still not migrated over. I'm starting another thread for
updates on this.
- Devan
Florian Dold transcribed 2.5K bytes:
> On 4/7/19 6:29 AM, Devan C. - dvn wrote:
> > Until email/smtp is setup we
Florian Dold transcribed 2.3K bytes:
> 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
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
Hi,
On 08.04.19 16:12, Christian Grothoff wrote:
> On 4/8/19 3:37 PM, Schanzenbach, Martin wrote:
>> 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
>>
On 4/8/19 4:42 PM, n...@n0.is wrote:
>> On 4/8/19 3:37 PM, Schanzenbach, Martin wrote:
It sounds like you're suggesting that we should have a core team of
developers in official capacity for GNUnet e.V. to look at pull requests
and then say "we think that this doesn't infringe on
Christian Grothoff transcribed 8.1K bytes:
> On 4/8/19 3:37 PM, Schanzenbach, Martin wrote:
> >> It sounds like you're suggesting that we should have a core team of
> >> developers in official capacity for GNUnet e.V. to look at pull requests
> >> and then say "we think that this doesn't infringe
> 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/8/19 3:37 PM, Schanzenbach, Martin wrote:
>> It sounds like you're suggesting that we should have a core team of
>> developers in official capacity for GNUnet e.V. to look at pull requests
>> and then say "we think that this doesn't infringe on copyright" and
>> merge them in. Is that what
> On 7. Apr 2019, at 19:20, Florian Dold wrote:
>
> 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
On 4/8/19 12:33 PM, Marcos Marado wrote:
> I am assuming that the "EU regulation" here spoken of is the Copyright Reform,
> in particular Article 13. If that's the case, then “open source
> software development
> and sharing platforms” are explicitly excluded from it[1] (let's see
> how will that
Hi,
On Mon, Apr 8, 2019 at 1:07 PM wrote:
[...]
> > I am assuming that the "EU regulation" here spoken of is the Copyright
> > Reform,
> > in particular Article 13. If that's the case, then “open source
> > software development
> > and sharing platforms” are explicitly excluded from it[1]
Marcos Marado transcribed 2.6K bytes:
> Hi,
>
> On Sun, Apr 7, 2019, 18:20 Florian Dold wrote:
> > 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
z...@hyper.dev transcribed 462 bytes:
> Hello!
>
> On 2019-04-05 21:20, Devan C. dvn wrote:
> > Hello my fellow GNUnetians,
> >
>
> > - Registration is open. There are no guarantees on uptime, or even
> > data retention (though I don't expect data to disappear).
>
> Does it mean I can
Hi,
On Sun, Apr 7, 2019, 18:20 Florian Dold wrote:
> 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
Hello!
On 2019-04-05 21:20, Devan C. dvn wrote:
Hello my fellow GNUnetians,
- Registration is open. There are no guarantees on uptime, or even
data retention (though I don't expect data to disappear).
Does it mean I can register an account and use it to temporarily host my
project?
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
> On 7. Apr 2019, at 13:36, Christian Grothoff wrote:
>
> On 4/7/19 11:11 AM, Schanzenbach, Martin 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
On 4/7/19 11:11 AM, Schanzenbach, Martin 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
On 4/7/19 1:14 PM, Schanzenbach, Martin wrote:
> As I said in another mail you are fighting windmills here. Given that we have
> a mandatory CAA, that is where the gatekeepers come in anyway.
> And the problems you claim here are also exiting there.
Signing the CAA isn't really imposing
> On 7. Apr 2019, at 12:47, 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
Some more detailed arguments for the point I was making:
http://lisperator.net/blog/pull-request-based-development-sucks/
I really like that with GitLab we have to *possibility* to do code
review, but we shouldn't force it down everybody's throat for GNUnet.
- Florian
On 4/7/19 12:47 PM,
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
>
> On 7. Apr 2019, at 11:11, Schanzenbach, Martin
> wrote:
>
>
>
>> On 7. Apr 2019, at 11:02, Christian Grothoff 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
> On 7. Apr 2019, at 11:02, Christian Grothoff 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
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 must
> On 6. Apr 2019, at 21:47, Florian Dold wrote:
>
> Signed PGP part
> 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
On 4/6/19 9:47 PM, Florian Dold wrote:
> Error parsing header X-XSS-Protection: 1; mode=block, 1; mode=block:
> expected semicolon at character position 13. The default protections
> will be applied.
I've fixed this, seems Gitlab is adding this, and the Apache config was
_also_ adding it,
On 4/6/19 9:47 PM, Florian Dold wrote:
> 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
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
wldhx transcribed 4.1K bytes:
> > So instead of "hey, signup and we give you access", what about the
> > addition of LDAP?
> > https://docs.gitlab.com/ee/administration/auth/how_to_configure_ldap_gitlab_ce/
>
> Is there additional benefit to LDAP as compared to standard GL ACL [0]?
> Note only
> So instead of "hey, signup and we give you access", what about the
> addition of LDAP?
> https://docs.gitlab.com/ee/administration/auth/how_to_configure_ldap_gitlab_ce/
Is there additional benefit to LDAP as compared to standard GL ACL [0]?
Note only some roles have "add members" privilege.
I
On 4/6/19 12:09 PM, n...@n0.is wrote:
> How much space for additional harddrives do they have? As a group or
> as association we could certainly pay for more disks if possible.
500 GB /home on sam (~70% used), 8 TB /home on firefly (for now empty).
sam has no empty bays, firefly has some. But
n...@n0.is transcribed 8.0K bytes:
> Devan C. dvn transcribed 6.5K bytes:
> > Hello my fellow GNUnetians,
> >
> > As some of you know, I have been pushing for and working on getting us
> > to CI/CD system based on Gitlab CI. This is pretty much ready to start
> > using and building out the
Devan C. dvn transcribed 6.5K bytes:
> Hello my fellow GNUnetians,
>
> As some of you know, I have been pushing for and working on getting us
> to CI/CD system based on Gitlab CI. This is pretty much ready to start
> using and building out the pipelines for now.
>
> In a previous thread[0] there
Christian Grothoff transcribed 4.5K bytes:
> On 4/5/19 9:20 PM, Devan C. dvn wrote:
> > - wldhx has kindly offered two "Gitlab Runners" for running CI jobs.
> > These will be added as shared runners, to be used by any projects on
> > the instance. This may be changed later to only be shared by
Thanks for the writeup.
My comments below.
> On 5. Apr 2019, at 21:20, Devan C. dvn wrote:
>
> Signed PGP part
> Hello my fellow GNUnetians,
>
> As some of you know, I have been pushing for and working on getting us
> to CI/CD system based on Gitlab CI. This is pretty much ready to start
>
On 4/5/19 9:20 PM, Devan C. dvn wrote:
> - wldhx has kindly offered two "Gitlab Runners" for running CI jobs.
> These will be added as shared runners, to be used by any projects on
> the instance. This may be changed later to only be shared by projects
> under the GNUnet namespace.
Eh, what
37 matches
Mail list logo
