On Tue, Feb 25, 2020 at 9:06 PM Volker Krause wrote:
>
> Given how little practical experience we have with this, I'd be cautious with
> publishing unreviewed raw data though. And that isn't just theoretical.
>
Quite.
Publishing the raw data is a bad idea from a privacy perspective.
On Tue, Feb 25, 2020 at 9:06 PM Volker Krause wrote:
>
> Not publishing the raw data right from the start was mainly a safety measure,
> to give us a chance to review the data and fix de-anonymization issues should
> any have slipped through.
>
> There's also technical limitations, the current
On Thu, Jan 23, 2020 at 3:42 PM Niccolò Venerandi
wrote:
>
> Hi!
> I'm working on adding a kde.org/hardware webpage. You can see screenshot
> here: https://phabricator.kde.org/D26711. What do you think?
> ~Niccolò Venerandi
I think that there may be two different product categories:
-
On Sat, Jan 25, 2020 at 3:11 PM Philippe Cloutier wrote:
> I was going to write the same, but refrained, because in fact this brings
> more questions than it answers:
>
> Who has verified vendor claims before copying them? The one quoted by
> Alexander hasn't even been adapted to our viewpoint.
On Sun, Jan 12, 2020 at 3:19 PM Andreas Cord-Landwehr
wrote:
>
> Hi, after the comments for my initial licensing policy draft, I prepared an
> update:
>
> - current version of the draft: https://community.kde.org/Policies/
> Licensing_Policy/Draft_SPDX_v2
>
One thing that is not entirely clear
On Sun, Jan 12, 2020 at 3:19 PM Andreas Cord-Landwehr
wrote:
> Moreover, I prepared a first version of a licensing howto and added it to the
> guidelines/howto section into the community wiki (please feel free to update/
> extend/clarify it!):
> -
Thanks for your clarifications.
On Sun, Jan 19, 2020 at 5:43 PM Andreas Cord-Landwehr
wrote:
> Is this OK for you that we postpone the above topics for a next iteration of
> the policy? (Nothing prevents from starting a proposal just after the current
> update :) ) Otherwise, these topics would
On Thu, Apr 9, 2020 at 9:04 PM Jens wrote:
>
> I can’t make any calls since the work isn’t on my shoulders but if the Qt
> company are ready to pull this stunt AND then lie about it in the vaguest
> most awkward way of saying “KDE and Qt Free are lying” they will do this
> again and forking,
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote:
>
> To help assist with this, it would be appreciated if all holders of a
> KDE Developer account could please login on our Gitlab instance (at
> https://invent.kde.org/) and ensure they are listed as a 'Developer'
> of the KDE group. You can
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote:
>
> Should anyone have any questions on the above, please let us know.
>
Does the migration also mean that `git.kde.org` push URL will be
retired and would need to be remapped to `invent.kde.org`?
In that case, it would be good to have a
On Sat, Apr 11, 2020 at 8:39 PM Ben Cooksley wrote:
>
> Yes, the hostname git.kde.org will be fully retired as part of this
> transition.
>
> From my understanding kdesrc-build will automatically pick this up
> once we update sysadmin/repo-metadata to show the new repository
> paths.
> This is
On Sat, Apr 11, 2020 at 11:03 PM Michael Pyne wrote:
>
> On Sat, Apr 11, 2020 at 09:25:11PM +0200, Johan Ouwerkerk wrote:
>
> >
> > A cleanup script could be handy. I think kdesrc-build will
> > automatically pick up new repo paths from metadata and that should
> >
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote:
>
> Yes the only reason why a cleanup script might be needed is if the
> logical path used to express the repo in dependency information
> changes at the same time. E.g. suppose a `frameworks/kf5foo` gets
> remapped to `fra
On Sun, Apr 12, 2020 at 1:06 AM Ben Cooksley wrote:
>
> On Sun, Apr 12, 2020 at 11:04 AM Johan Ouwerkerk
> wrote:
> >
> > On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk
> > wrote:
> > >
> > > Yes the only reason why a cleanup script migh
On Fri, Apr 10, 2020 at 4:10 PM Ivan Čukić wrote:
>
> > want use KDE as the "open version of Qt" shop then we should probably
> > first look at the number of fixes to upstream actually made through
> > KDE mirrors directly. I.e. count how many people use KDE repos to
>
> I think I agree with your
On Sun, Apr 12, 2020 at 12:49 AM Johan Ouwerkerk wrote:
>
> >
> > We may need to do on-the-fly conversion of the kde: repo paths if they
> > won't be expressible as 'kde:foo' in the future, but we should have the
> > information needed to do this in kdesrc-build to make
On Tue, Apr 28, 2020 at 1:09 PM Adriaan de Groot wrote:
>
> One actor is "tooling", as Albert has pointed out. Whatever the resulting
> structure is, it needs to be communicated to tool authors on time for tools to
> be updated, released, and rolled out for use. Tools mentioned so far:
> -
On Mon, Apr 27, 2020 at 3:30 PM Luigi Toscano wrote:
>
> Bhushan Shah ha scritto:
>
> > - But most importantly, this breaks with the non-unique leaf repository
> > names feature offered by the proposed structure. So, There could be
> > maui/documentation and wikitolearn/documentation. But we
On Mon, Apr 27, 2020 at 2:32 PM Piyush Aggarwal
wrote:
>
> How long do redirects like this one work? If they will keep working
> indefinitely, then maybe we can have all the repos at flat URLs for once and
> then move them to respective subgroups?
I don't think this works if you want $repo to
On Fri, May 1, 2020 at 6:38 AM Nate Graham wrote:
>
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I
> >> thought it was the common thing to do :?
> >
> > I do too
>
kde.org website
> with your normal KDE credential.
>
Congratulations! It looks pretty slick.
Regards,
- Johan Ouwerkerk
Auth authorization server for obtaining tokens
just fine.
And if that is the case, yeah probably just implement a button which
basically does `xdg-open https://sign-up-url-goes-here`, switch the UI
to a login screen and call it V1 ?
Regards,
- Johan Ouwerkerk
22 matches
Mail list logo
