[Mageia-dev] unity on mageia

Fri Sep 14 11:42:29 CEST 2012

Hi Damian,
+
+'Twas brillig, and Damian Ivanov at 12/09/12 11:33 did gyre and gimble:
+> My name is Damian Ivanov. Xiao-Long Chen and me are the maintainers of
+> unity desktop environment for openSUSE and Fedora
+
+Thanks for writing and getting in touch!
+
+It's certainly an interesting proposal, but it's really one that opens a
+box of many more related questions, some of which I'll try and touch on
+below.
+
+1. External Repositories
+
+The "Here is my PPA where I do x, y and z" style approach to software
+repositories is always one we've deliberately avoided. It's creates
+significant problems for our (relatively) small teams when doing QA and
+addressing bug reports. For example if a user is using third party
+software and they open a bug report, the Triagers and packagers need to
+be aware of that, but it's often something users do not know to
+highlight or the decide by themselves that it's "not relevant" (when, in
+fact, it often can be due to some obscure library that is loaded
+dynamically that messes up the whole stack).
+
+It also creates significant problems on upgrades, if they have upgrade
+one package to a non-official version, that then might affect the rest
+of the distribution when it comes time to upgrade.
+
+None of the problems here are insurmountable, but they do exist and if
+we are to continue to produce a quality product, we need to keep a
+strong hold on the reigns with regards to this kind of stuff.
+
+
+2. If external repositories are to be discouraged then the next obvious
+step is to try an incorporate it in Mageia repos directly. However,
+unity in particular is a pretty onerous package when it comes to
+non-upstream modifications to other packages. This is Canonical's choice
+when they designed things this way. I'd rather see more upstream
+collaboration, and I'd personally want Mageia to encourage that general
+principle, not sign up to the policy that downstream divergence is OK
+and something to be supported and encouraged. For this reason, for me
+personally, I'd exclude Unity from Mageia official repositories until
+the patches can be properly upstreamed. This is a primarily politically
+reasoned decision. I don't like divergence and I favour collaboration.
+
+
+3. Ignoring the above points and thinking more practically, would you
+propose to use the same specs for Fedora, OpenSuse and Mageia for the
+packages or would you use separate ones? Sorry if this is stated already
+and I'm just blind! If they are the same, then I suspect this would
+cause even more issues as the distros obviously diverge in their
+packaging structure.
+
+
+4. How do you handle automatic rebuilds when a package changes? e.g.
+when we change our official gtk, I presume you would want to
+automatically rebuild yours too? Also what if lower level things change,
+e.g. automated provides/requires extraction stuff provided at a lower
+level. I presume all this stuff "just works" in OBS?
+
+
+5. Regarding using OBS generally for Mageia, I would not personally be
+against it in principle, but there are lots and lots of barriers there.
+We do already have a working build infrastructure and we can control it
+and have experience of fixing, tweaking it etc. We know it's quirks.
+With OBS it would be like starting again. That's not to say it wouldn't
+be the "right choice", but it could very easily not be the "right choice
+right now". It would take the primary sysadmins to be really
+enthusiastic and keen on any transition and know exactly what benefits
+it would bring us. Although I can't speak for everyone, I just don't
+think there is enough in the way of resources right now for that to be
+the case.
+
+
+6. While I'm sure the web interface is nice, I presume it must link
+directly to a RCS in the background? e.g. we'd need it to hook into our
+subversion system right now. AFAIUI OBS had a some crazy custom RCS
+behind it. Is this now more generic? Can it hook up to subversion and/or
+git these days, how would it deal with user authentication?
+
+
+7. There is a large part of me that wants to avoid adding everything and
+anything to Mageia just because we can. Even although this is community
+lead, and community driven, if we end up adding everything and anything
+we could easily end up being a jack of all trades and a master of none.
+We already have, IMO, too many options in some cases. Look at the login
+manager world, we have about five or six of those and only one is
+actually the one I'd want to use and that's GDM. The reason being that
+it is being proactive in genuinely solving the problems of today. We
+already have issues with most of the other DMs because they are not
+doing PAM correctly or are only half integrated. It's a lot of effort to
+keep up with things and unless upstream are being proactive (which many
+are not) then it falls to the downstream to pick up the slack. I
+personally have no interest in lightdm, slim, lxdm etc. but yet I seem
+to have to look at bug reports concerning them. Adding more stuff will
+inherently make things harder to deal with unless there is a
+corresponding increase in talented and pro-active contributors too!
+
+
+Just as a final note, I would like to thank you for your interest here.
+It's important to note that I'm all for collaboration and for
+encouraging contributions to Mageia whatever they are. I don't want some
+of my own, personal opinions to put anyone off, but I do want people to
+appreciate the broad reasons for such concerns (which I'm sure are
+shared by others too) and what would need to be done to address them to
+everyones ongoing satisfaction.
+
+All the best
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+colin(at)mageia.org
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+