From kde-core-devel Tue Jun 14 15:42:55 2011 From: Martin =?ISO-8859-1?Q?Gr=E4=DFlin?= Date: Tue, 14 Jun 2011 15:42:55 +0000 To: kde-core-devel Subject: Re: Re: KDM plans and lightDM Message-Id: <3544706.GCHJfV9fSx () martin-desktop> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=130806643932318 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2559229.HXSeUtVgfZ" --nextPart2559229.HXSeUtVgfZ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday 14 June 2011 10:35:49 Harald Sitter wrote: > On Tue, Jun 14, 2011 at 8:16 AM, Martin Gr=C3=A4=C3=9Flin wrote: > > On Mon, 13 Jun 2011 16:29:45 -0400, Shaun Reich > > wrote: > >> > >> lightDM is also headed by my dear friend Canonical, as is clearly = seen. > > > > Serious question: does anyone know if it requires Canonical's copyr= ight > > assignment to contribute to lightDM? If yes we can stop any further= > > discussion right here IMHO. >=20 > robert_ancell: ahoy, is LightDM covered by the > canonical contributor agreement? > apachelogger, no > robert_ancell: ever going to be? > apachelogger, no > apachelogger, the greeter we develop will be afaik, > but the rest of it not Thanks for asking >=20 > > There are of course more issues to think about when considering usi= ng > > something in our workspace that's developed by Canonical. What abou= t we need > > changes Canonical does not like for what reason ever? Who of us can= work > > with launchpad and bazaar? It's not the environment we are used to = work with > > (same true for GNOME devs who want to participate in development). = Personal > > opinion: if Canonical wants other to use it as real cross-desktop, = the first > > step should be move the code into freedesktop's git repository. >=20 > Indeed, issues worth considering. >=20 > I personally believe that "wanting to have something the other party > does not" is really a global issue to all of free software. If I want= > Amarok to be able to remote control my space ship, but the Amarok > developers do not, then there is little I can do about that as a > non-contributor. Well, except for trying to convince them from the > long-term advantage that such a feature would provide. If however I > would want Phonon to have such a feature, it is more likely to get > accepted as I am contributor to Phonon. I suppose it is a bit of a tw= o > class society for every project those-that-do-stuff vs. > those-that-don't. While we should keep this in mind, I do not > generally think that it is something to base decisions on. From the > preemptive fear of not having 100% of control we'd otherwise have to > clone every library we use. Well, actually even the OS. Hello KDEOS ;= ) I don't think a comparison with libraries holds. We use libraries to bu= ild applications including=20 the DM. But the DM is part of our workspace offering. Without a DM we n= o longer provide a=20 complete workspace experience. So this is a completely different toppic= and cannot be=20 compared with our policies for libraries and other OS integration. To my knowledge this would also be a novelty that we replace a part of = our workspace with=20 a 3rd party application. As a workspace developer I consider the possibility to align all our wo= rkspace applications to=20 our needs as very important. Let's just consider we would want to start= into an activity from=20 the DM... My arguments might seem far*fetched, but from an integrated w= orkspace=20 development point of view, they aren't (at least IMHO). >=20 > I agree with your argument that code should be hosted in a FDO git > repo, though I personally believe that Launchpad is from a managemen= t > perspective much easier to use for small projects as it puts every > aspect of management into the hands of the project itself (commit > access to repos, bug management etc. etc.). So, I can completely > understand why one would be using LP even as a freedesktop.org > project/thing, even if I find it not sensible at all to do this while= > using the freedesktop.org website, thus fragmenting one's project > *shrug*. > But generally speaking I also see this is as a non-issue in terms of > the discussion at hand. The hosting system in particular is an > implementation detail of forming grounds to collaborate on. Now, to > ask anyone to use a ground we are familiar with (vs. one the other > party is), we'd first have to know that we want to collaborate. Agreed that this is only relevant for the case that we want to use ligh= tDM. > At any > rate it probably does not make sense to take such things into account= > for any technical discussion as long as the system in use is easily > accessible. Otherwise all of free software would be using Git, not > because it is superior, but simply because everyone else does. Actually I think from a workspace point of view it is a technical issue= if one of our=20 applications is hosted in a version control system that is not git. Esp= ecially if it is a bizarre one=20 that is only used by one distribution. It means that not each workspace= developer is able to=20 easily check out the sources and apply patches. So yes, sounds very muc= h like an issue to=20 me. Cheers Martin >=20 > regards, > Harald --nextPart2559229.HXSeUtVgfZ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAk33gX8ACgkQqVXwidMiVrqM+wCfYJ+n7Uw0Z/CGMM4YTsgLbNa+ ekYAn0Go5WMkE22ouECgdW/oppzcFl+v =7e+P -----END PGP SIGNATURE----- --nextPart2559229.HXSeUtVgfZ--