Luca Ferretti | 1 Dec 01:00 2011
Picon

Re: Boxes and 3.4

2011/11/30 Andrew Cowie <andrew <at> operationaldynamics.com>:
> On Wed, 2011-11-30 at 14:15 +0100, Luca Ferretti wrote:
>
>> And, in suborder, why can't Boxes be simply a non-core, featured
>> application, just like GIMP or Simple Scan?
>
> Because there's a big difference between an integrated, designed,
> polished, documented and translated GNOME app and something that happens
> to use GTK, right?

Not sure, but maybe you missed the point of that examples. The key is,
in effect, the current integration of Boxes (or the feauture that
Boxes provide) in GNOME desktop. I feel Boxes is just a stand alone
application that allows you to perform tasks unrelated to the audiece
we want to target. On the other side and as example of integration,
the current Vino/Vinagre couple can allow you to share a screen using
our chat application Empathy, a feature useful non-tech people too.
Maybe Boxes will be able to do the same, but personally I don't have
any urge to include it here and now as _core_ module or feature of
GNOME.

> Just because it isn't targeted at core audience doesn't mean that it
> shouldn't be an awesome part of GNOME if you happen to be in an
> alternate space. You know, like IT professionals?

Well, we had many discussions about "stuff not targeted at core
audience" in the past months, and they are still not part of GNOME
design ;)

>
(Continue reading)

Sriram Ramkrishna | 1 Dec 01:46 2011

Re: Boxes and 3.4


However, I don't want too see Boxes as a solution, it's just a tool
that will allow you to use VMs and remote machines.
It could be a plus when we'll release a full GNOME OS, but when this
will occur IT professionists and tech enthusiast people will show more
interest in supported protocols (vnc, rdp, ...) and virtualization
infrastructure than in integrated appearence of a frontend.

BTW: planned protocols? The design page simply says "Connecting to a
work machine from home"


Out of curiosity, does Boxes have every machine as a task or is Boxes just one task?  For instance, I tend to connect to many machines, I switch between them using alt-tab.or the overview.  I get the impression that Boxes puts all the machines in one box and then you manage within that?

(as an aside, I would be interested in an integrated ssh solution if you're out to please sysadmin like myself)

sri 
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Jason D. Clinton | 1 Dec 02:51 2011

Re: Boxes and 3.4

On Wed, Nov 30, 2011 at 16:32, Andrew Cowie <andrew <at> operationaldynamics.com> wrote:
On Wed, 2011-11-30 at 14:15 +0100, Luca Ferretti wrote:

> And, in suborder, why can't Boxes be simply a non-core, featured
> application, just like GIMP or Simple Scan?

Because there's a big difference between an integrated, designed,
polished, documented and translated GNOME app and something that happens
to use GTK, right?

That's the distinction between Featured Apps and everything else in the world. Core is for, well, core OS and desktop functionality that everyone can't do without. The only thing requiring approval today is Platform and Core.

It certainly belongs in the apps moduleset where it is now so that it can facilitate easy jhbuilding. There's no approval required for the apps moduleset nor for Feature Apps (which is only a marketing distinction).

Boxes looks wonderful.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Zeeshan Ali (Khattak | 1 Dec 03:49 2011
Picon

Re: Boxes and 3.4

On Thu, Dec 1, 2011 at 12:32 AM, Andrew Cowie
<andrew <at> operationaldynamics.com> wrote:
> On Wed, 2011-11-30 at 14:15 +0100, Luca Ferretti wrote:
>
>> And, in suborder, why can't Boxes be simply a non-core, featured
>> application, just like GIMP or Simple Scan?
>
> Because there's a big difference between an integrated, designed,
> polished, documented and translated GNOME app and something that happens
> to use GTK, right?
>
> Just because it isn't targeted at core audience doesn't mean that it
> shouldn't be an awesome part of GNOME if you happen to be in an
> alternate space. You know, like IT professionals?
>
> We're getting *ransacked* out there in discussions in LUGs around the
> world (e.g. [1]) because power users are trying GNOME 3 have found it
> totally interferes with their accustomed workflows. Unhappy campers. If
> people in LUGs have the idea that GNOME 3 is no use for them, do you
> really think they're going to push for its adoption in the wider company
> that they have to support?
>
> So the whole discussion about whether Boxes is core or not is
> ridiculous. If it meets the standards of being a good GNOME app (HIG, oh
> HIG, where art thou HIG) then it should be endorsed and promoted.
> Period.

While I greatly appreciate your support for Boxes here, I must inform
you that Boxes is *not* targeted for IT professionals. For that we
have virt-manager and oVirt.

Regarding the rationale of Boxes as a core app, I think we definitely
need something to nicely handle insertion of an OS installer or live
media. The best thing to do in that scenerio is the creation and
launch of a VM (box) and Boxes already does that for you. Without
Boxes as part of every GNOME installation, we won't have this working
out of the box and bore the users by showing them files on the media.

--

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
Zeeshan Ali (Khattak | 1 Dec 03:59 2011
Picon

Re: Boxes and 3.4

On Thu, Dec 1, 2011 at 4:49 AM, Zeeshan Ali (Khattak)
<zeeshanak <at> gnome.org> wrote:
> On Thu, Dec 1, 2011 at 12:32 AM, Andrew Cowie
> <andrew <at> operationaldynamics.com> wrote:
>> We're getting *ransacked* out there in discussions in LUGs around the
>> world (e.g. [1]) because power users are trying GNOME 3 have found it
>> totally interferes with their accustomed workflows. Unhappy campers. If
>> people in LUGs have the idea that GNOME 3 is no use for them, do you
>> really think they're going to push for its adoption in the wider company
>> that they have to support?
>>
>> So the whole discussion about whether Boxes is core or not is
>> ridiculous. If it meets the standards of being a good GNOME app (HIG, oh
>> HIG, where art thou HIG) then it should be endorsed and promoted.
>> Period.
>
> While I greatly appreciate your support for Boxes here, I must inform
> you that Boxes is *not* targeted for IT professionals. For that we
> have virt-manager and oVirt.

   Don't get me wrong please. I'm sure Boxes *will* satisfy many IT
professionals as well and we will try our best to support their
use-cases as long as those use-cases do not conflict with that of a
typical end-user.

--

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
Johannes Schmid | 1 Dec 08:00 2011
Picon

Re: Boxes and 3.4

Hi!

> Regarding the rationale of Boxes as a core app, I think we definitely
> need something to nicely handle insertion of an OS installer or live
> media. The best thing to do in that scenerio is the creation and
> launch of a VM (box) and Boxes already does that for you. Without
> Boxes as part of every GNOME installation, we won't have this working
> out of the box and bore the users by showing them files on the media.

Be honest, how often have you inserted an OS installer or live media in
your life. Even as a power user I haven't use my DVD drive for probably
the last half year. I don't think this is a typical day-to-day use case.

Anyway, as Matthias already pointed out, Boxes is fine in the moduleset it
currently is in.

Regards,
Johannes
Frederic Peters | 1 Dec 10:00 2011
Picon

Re: Boxes and 3.4

Jason D. Clinton wrote:

> > Because there's a big difference between an integrated, designed,
> > polished, documented and translated GNOME app and something that happens
> > to use GTK, right?
> >
> 
> That's the distinction between Featured Apps and everything else in the
> world. Core is for, well, core OS and desktop functionality that everyone
> can't do without. The only thing requiring approval today is Platform and
> Core.
> 
> It certainly belongs in the apps moduleset where it is now so that it can
> facilitate easy jhbuilding. There's no approval required for the apps
> moduleset nor for Feature Apps (which is only a marketing distinction).

Thanks for bringing this as that was certainly the plan but (by lack
of resources in the marketing team?) it fell down and we got back to
square one with the release team "somehow" handling applications, in
this case "Boxes".

"Somehow", because we didn't redefine criterias, in terms of
documentation, schedule, all the things we had before. If people wants
the release team to handle apps, we should get back to some processes.

So I guess my questions are about roles, marketing team? release team?
and consequences.

        Fred
Jason D. Clinton | 1 Dec 17:58 2011

Re: Boxes and 3.4

On Thu, Dec 1, 2011 at 03:00, Frederic Peters <fpeters <at> gnome.org> wrote:
Jason D. Clinton wrote:

> > Because there's a big difference between an integrated, designed,
> > polished, documented and translated GNOME app and something that happens
> > to use GTK, right?
> >
>
> That's the distinction between Featured Apps and everything else in the
> world. Core is for, well, core OS and desktop functionality that everyone
> can't do without. The only thing requiring approval today is Platform and
> Core.
>
> It certainly belongs in the apps moduleset where it is now so that it can
> facilitate easy jhbuilding. There's no approval required for the apps
> moduleset nor for Feature Apps (which is only a marketing distinction).

Thanks for bringing this as that was certainly the plan but (by lack
of resources in the marketing team?) it fell down and we got back to
square one with the release team "somehow" handling applications, in
this case "Boxes".

"Somehow", because we didn't redefine criterias, in terms of
documentation, schedule, all the things we had before. If people wants
the release team to handle apps, we should get back to some processes.

When did this happen? I admit I've been a bit disconnected for a few months but even if the Featured Apps didn't get updated, it was never intended to be an exhaustive list. In fact, I explicitly stated in the announcement (with blessing from the Release Team) that there was no mechanism by which to apply for "featured" status and it was to be construed as nothing more than what it was: purely a marketing designation. There were only 8 Featured Apps the 3.0 and 3.2 release (these eight http://www.gnome.org/applications/) *and* we still had an apps moduleset for both releases.

So what has changed? I think that there's some confusion here and I'd like to clear it up. As far as I know, everything is just fine: Featured Apps is a marketing function and apps moduleset can include anything to facilitate jhbuilding.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Frederic Peters | 1 Dec 20:00 2011
Picon

Re: Boxes and 3.4

Jason D. Clinton wrote:

> When did this happen? I admit I've been a bit disconnected for a few months
> but even if the Featured Apps didn't get updated, it was never intended to
> be an exhaustive list. In fact, I explicitly stated in
> the announcement (with blessing from the Release Team) that there was no
> mechanism by which to apply for "featured" status and it was to be
> construed as nothing more than what it was: purely a marketing designation.
> There were only 8 Featured Apps the 3.0 and 3.2 release (these eight
> http://www.gnome.org/applications/) *and* we still had an apps moduleset
> for both releases.

But what's the meaning of the apps moduleset? It is not about featured apps,
as you wrote earlier:

    This list is not jhbuild-maintained because it is a function of
    marketing, not development. The list of featured applications is
    maintained on our web properties and has nothing to do with any
    official module status.

    -- http://git.gnome.org/browse/jhbuild/commit/?id=12a0bd91

And applications got out of release team scope in the announcement
you refer to:

    Release Team continue to administer the formal new module proposal
    process for Core (that is, everything which would be considered part
    of "GNOME OS" and is currently in the Core moduleset)

    -- https://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00045.html

But despite that announcement, most of the application module
maintainers continued to follow the release schedule, and were part of
releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/)

Again, the question, what's the meaning of the apps moduleset? It's
been the place for "a serie of applications" handled by the release
team, remnants of the old modulesets, but doesn't it lack some more
formal definition?

If it's applications released by the GNOME project, shouldn't we get
back some release criteria?

If it's just to facilitate jhbuilding, what's the difference between
the -apps and the -world modulesets?

> So what has changed? I think that there's some confusion here and I'd like
> to clear it up. As far as I know, everything is just fine: Featured Apps is
> a marketing function and apps moduleset can include anything to facilitate
> jhbuilding.

Well, there was the moduleset reorg announcement, but after that we
also had 8 months of practice, and they don't quite fit, because in
some sense, what has changed? nothing, applications still wanted to be
under the GNOME shelter, and the release team kept offering that.

We put up a "feature proposal period" in place, and applications kept
being proposed, and that discrepancy is part of this thread, Vincent
wrote: "I said that I didn't feel Boxes should be tracked as a feature".

        Fred
Jason D. Clinton | 1 Dec 21:21 2011

Re: Boxes and 3.4

On Thu, Dec 1, 2011 at 13:00, Frederic Peters <fpeters <at> gnome.org> wrote:
But despite that announcement, most of the application module
maintainers continued to follow the release schedule, and were part of
releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/)

Yes, we want that and we get it without having to fight about Vinagre vs. Boxes, for example. GNOME's process is a great set of best practices to follow without having to involve the release team in picking GNOME favorites (eg. The One True Music Player). And because it gives GNOME translation and documentation teams an implicit schedule they can rely on.

Want to be part of GNOME? Join are community and you are. Want to be a GNOME App? Follow our practices and you are.


Again, the question, what's the meaning of the apps moduleset? It's
been the place for "a serie of applications" handled by the release
team, remnants of the old modulesets, but doesn't it lack some more
formal definition?

It shouldn't be handled by the release team because that gets us in to these threads all over again which was entirely the point of implementing this change. If that's been going on, it really shouldn't be.

The i18n coordinators add modules to Damned Lies; the Documentation coordinators (eg. Shawn) track the Mallard work across modules; in the same way, the release team or anyone with git access, really, can and should be encouraged to add their build instructions to the apps moduleset.


If it's applications released by the GNOME project, shouldn't we get
back some release criteria?

Module maintainers release their modules; GNOME provides infrastructure and a community.


If it's just to facilitate jhbuilding, what's the difference between
the -apps and the -world modulesets?

That should be fixed, I agree.


Well, there was the moduleset reorg announcement, but after that we
also had 8 months of practice, and they don't quite fit, because in
some sense, what has changed? nothing, applications still wanted to be 
under the GNOME shelter, and the release team kept offering that.

We put up a "feature proposal period" in place, and applications kept
being proposed, and that discrepancy is part of this thread, Vincent
wrote: "I said that I didn't feel Boxes should be tracked as a feature".

If that's what happened then did we ever /really/ implement the change that we all agreed on? 

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Gmane