Re: All stable flatpak builds moved to flathub

[Alejandro HC]

>
> I do understand that some small projects with limited workforce will
> need to rely on third parties and in that I see value in what Flathub
> is right now, but:
> * I don’t think there should be a single “Flathub” (as a repo hosting
> platform), but that Flathub itself should indeed be the way to
> discover the platforms[0].
> * I don’t think GNOME apps should have been moved away from GNOME
> infrastructure[1]. Yes, anyone can host their own repository, but if
> even GNOME didn’t bother why would anyone else?
>
>

This makes me think a little. Before I thought that flathub would be a site
that would allow me to find applications in flatpak format from anywhere,
for example if Steam had its own repo, I could find it anyway in flathub,
however, now I see that developers "must" host their applications in that
repository ... what sets it apart from the Canonical Snap store in practice?

I understand the advantages of having everything in one place as a
repository, but I thought that flathub would follow a more open model and
could discover third-party apps repos.

Those are my two cents as a user.

*Hugo*
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gjs 1.51.2

[philip . chimento]

On Tue, Nov 14, 2017 at 4:26 AM Emmanuele Bassi  wrote:

> On 14 November 2017 at 03:20,   wrote:
> > On Mon, Nov 13, 2017 at 4:41 AM Michael Catanzaro <
> mike.catanz...@gmail.com>
> > wrote:
> >>
> >> On Sun, Nov 12, 2017 at 10:44 PM, Philip Chimento
> >>  wrote:
> >> > From now on we'll be taking GitLab merge requests instead of Bugzilla
> >> > patches. If you want to report a bug, please report it at GitLab.
> >>
> >> The Bugzilla product is still active... this needs to be disabled, or
> >> people will continue to use it.
> >
> >
> > I assume it's possible to disable new bugs being reported while keeping
> the
> > old ones open?
>
> Yes, it's the default behaviour on GNOME's Bugzilla instance.
>
> Just close the product for new bug reports, and edit the description
> to point to the GitLab issues page.
>
> Alberto's script will do this automatically when moving bugs from
> Bugzilla to GitLab.
>

I never did get the "gjs developer" bit flipped on my Bugzilla account, can
anyone help?

Philip C
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: All stable flatpak builds moved to flathub

[Alexandre Franke]

Let me start by making it clear that I am a huge fan and advocate of
Flatpak and that I am mostly expressing concerns here.

Please keep in mind while reading this thread that this is not only a
technical matter, but also one of policies and guidelines.


On Mon, Nov 13, 2017 at 1:21 PM, Alexander Larsson  wrote:
> Flatpak itself is completely decentralized, in that anyone can (and do)
> create repos that anyone can install from. All these are on equal level
> in the CLI and in terms of features, and none are installed by default.

Right, we all agree on that.


> However, this leads to a pretty crappy user experience both for users
> who have to hunt for trustworthy repos all over the net, and for
> developers who each have to play sysadmin and maintain the
> infrastructure for a repo.

So basically we’re not using what makes the strength of flatpak
because it’s hard?

I do understand that some small projects with limited workforce will
need to rely on third parties and in that I see value in what Flathub
is right now, but:
* I don’t think there should be a single “Flathub” (as a repo hosting
platform), but that Flathub itself should indeed be the way to
discover the platforms[0].
* I don’t think GNOME apps should have been moved away from GNOME
infrastructure[1]. Yes, anyone can host their own repository, but if
even GNOME didn’t bother why would anyone else?


> So, the middle-road we've chosen for flatpak is to have one repo that
> has some level of review/testing that has most apps, so that people can
> get started easily.

Flatpak is seen and advertised by many as a way to shift the balance
from distributions to upstream developers. By going back to a single
repository, you’re cancelling that effect to some extent. Upstream
developers used to depend on distribution packagers to be shipped, now
they are depending on Flathub people to either review a PR or packing
it flat themselves.

Instead of a central repository, Flathub could have been a search
engine, or directory, or DHT, or… any similar mechanism that would
solve the problems you highlight without losing its potential.


> I'm not sure what you mean by "federation",

Hopefully I’ve cleared up what I meant now.


> but we don't plan to ever
> have one locally defined remote name resolve to a multitude of
> independent app sources. We are however working on distributing that
> repo, so that you can have e.g. a local, partial mirror, even ones
> discovered via avahi. However, each remote name is tied to one GPG key,
> so the source of the original builds are always one entity.

“Each remote name” doesn’t mean much when everyone hosts their
applications on the same remote and there is little incentive to do
otherwise.


On Mon, Nov 13, 2017 at 1:24 PM, Simon McVittie  wrote:
> The flatpak tool and library already support just as much federation as
> e.g. apt, git or jhbuild- you can add as many remotes as you want.

That is not federation though, but I grant you it’s decentralization.


> Apps and their runtimes don't even have to come from the same place:
> for example, an app that is not hosted on Flathub itself can use the
> freedesktop and GNOME runtimes from Flathub.

Yes, and that part is great.


> If there is something else that you think flatpak should do to support
> federation, I'd suggest opening a feature request.

Sure, but I don’t believe a vague and unspecific feature request would
get us anywhere, which is why I asked first if there was anything
planned on this topic. I also don’t know what form that would take,
although I risked some suggestions above, and I don’t have the deep
technical knowledge of the flatpak architecture that you and others
here have, so I would be hard pressed to tell you what you need to
implement.


> That doesn't mean that some level of centralization isn't helpful from a
> UX point of view.

Sure.


> Analogously, GNOME uses decentralized tools (git,
> jhbuild and a web browser), but requires official GNOME modules to
> be hosted on git.gnome.org,

which is mirrored at least on Github

> track their bugs on Bugzilla

and I wish there was a way to work with those in a decentralised
manner (but the sad state of decentralised bugtrackers is off-topic
but in a nutshell “why can I `git commit` on a train but not
read/comment on a bug report?”) (that concern is also valid for Gitlab
if/when we switch to it)

> and release via download.gnome.org;

which, I believe, has mirrors? To be honest, like most people, I don’t
get my GNOME software from there so I don’t really think about that as
a problem.


> apt can install packages from anywhere, but Debian
> doesn't really support installations where packages didn't all come
> from the Debian archive, and Ubuntu doesn't really support installations
> where packages didn't all come from the Ubuntu archive; and so on.

Right. And that’s a bit of a tangent. GNOME could say they don’t
support Flatpaks that don’t come from the GNOME 

Re: gjs 1.51.2

[Emmanuele Bassi]

On 14 November 2017 at 03:20,   wrote:
> On Mon, Nov 13, 2017 at 4:41 AM Michael Catanzaro 
> wrote:
>>
>> On Sun, Nov 12, 2017 at 10:44 PM, Philip Chimento
>>  wrote:
>> > From now on we'll be taking GitLab merge requests instead of Bugzilla
>> > patches. If you want to report a bug, please report it at GitLab.
>>
>> The Bugzilla product is still active... this needs to be disabled, or
>> people will continue to use it.
>
>
> I assume it's possible to disable new bugs being reported while keeping the
> old ones open?

Yes, it's the default behaviour on GNOME's Bugzilla instance.

Just close the product for new bug reports, and edit the description
to point to the GitLab issues page.

Alberto's script will do this automatically when moving bugs from
Bugzilla to GitLab.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gjs 1.51.2

[Simon McVittie]

On Tue, 14 Nov 2017 at 03:20:12 +, philip.chime...@gmail.com wrote:
> On Mon, Nov 13, 2017 at 4:41 AM Michael Catanzaro 
> wrote:
> 
> On Sun, Nov 12, 2017 at 10:44 PM, Philip Chimento
>  wrote:
> > From now on we'll be taking GitLab merge requests instead of Bugzilla
> > patches. If you want to report a bug, please report it at GitLab.
> 
> The Bugzilla product is still active... this needs to be disabled, or
> people will continue to use it.
> 
> I assume it's possible to disable new bugs being reported while keeping the 
> old
> ones open?

That functionality should be available to Bugzilla administrators,
although I'm aware most Bugzilla instances are patched and I'm not sure
which functionality comes from patches or plugins. On bugs.freedesktop.org
it's called "Open for bug entry" when editing a product, or "Enabled
For Bugs" on a component or version. Is that any help?

smcv
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list