Re: Better collaboration with distributions [Novell response]

Hi Frederic,

sorry for the late answer, but after my FTO quite some email backlog together with the currently on-going preparation of the next Service Pack has taken its
toll on my responsiveness.

On Dec 03, 10 15:06:46 +0800, Frederic Muller wrote:
> Dear Stefan and Scott,
> I am contacting you on behalf of the GNOME community in order to get
> initial feedback on an improved collaboration effort between GNOME and
> the downstream projects supporting us.
> As GNOME contributor base is slowly but surely growing we have been
> thinking of allocating some resources on this topic. Our initial
> objectives are to find out what we could be doing to simplify and ease
> your work related to GNOME integration in general and some specific
> issues such as better communication, help with accepting patches and
> sharing information between distributions on those issues. We already
> have a mailing list but little is happening there, so we must be
> out on something.
I'm glad to give you some answers here. The timing is quite good, as we have
done a major (unusual) act this year: We did a major GNOME version update when
we released SLED 11 SP1.
With SLED 11 we had shipped GNOME 2.24, which we decided to upgrade to GNOME
2.28 (with a few exceptions of packages) with SP1.
We encountered quite some difficulties with some packages, but mostly it went
fine. A major part of that was the fact that HAL is now going to be replaced
with various *kits. When the time came to decide if we go with GNOME 2.28, we came to the conclusion that we cannot switch to DeviceKit - nor e.g. PolicyKit
2. this was the major pain we experienced - most other stuff was no problem.
Especially the backward compatibility of the base libs (glib2, gtk2) was one of
the major points we looked at, as we needed to make sure that Third-Party
Applications would still run. Problematic e.g. here was the deprecation of
eel/libeel, which was no longer able to build with GNOME 2.28.

> Some of the initial information we'd like to gather are related to long
> term support of specific GNOME releases:
> 1. What version(s) of GNOME do you maintain in a stable fashion?
Currently for the Enterprise Products:
  SLE 10 SP3 (SP4 upcoming): 2.12
  SLE 11 SP1: 2.28 [We had switched here as said from 2.24 to 2.28]

> 2. How much work does this represent?
  With SLE 10 we spend only a limited time anylonger - it's mostly spend on
  bugfixing, with most of the work being backporting known fixes that are
  either easy to backport or have a very high security imact. We try to
  encourage our customers to switch to SLED 11 SP1.

With SLED 11 (and SPs) we te amount of work is quite big with some parts, as we are on one hand closer to the current upstream, but on the other hand have
  significant differences (udev, DeviceKit, PolKit come to mind).

In addition, we need to implement new stuff that is not present in upstream - some enhancements for NetworkManager. this puts us of course sometimes into the situation that we are too far away from upstream code to "simply submit"
  code to upstream - we need either to create it for the upstream part and
backport it, or forwardport it from out version. Both with its own advantages
  and disadvantages, of course.

> 3. Do you feel there is duplication of work between what you do and
> other distribution do?

  Scott has most likely a better feeling here, but I'll give a comment :)
We encourage everybody to put fixes upstream if they are not already there. In some cases we only apply/work on fixes (and feature implementations) if we know that upstream is ok with the way it is done. In some we are adding at least a workaround if we know that upstream has not yet decided on a 'best

> 4. How do you see a potential collaboration between all of "us"
> (upstream and downstream projects)?

I personally think we could all profit from it. The biggest problem I see is the different timelines we all have, with our deadlines for releases varying quite a lot. This might make co-ordinating difficult (e.g. I doubt it that we
  could agree on a 'long-term-suported' version that is used in all major
  distributions. But I'm willing to be proved wrong :)

> 5. We are definitely aware that today each of us use a different bug
> tracking system. Do you see any possible technical solution that could
> address this specific issue?
Frankly speaking - I doubt from past experiences to some degree that there is
  a good solution for everybody. We had it in the past here at Novell, when
  several different bugtracking systems were "unified" to one bugzilla. the
  screams and shouting in some parts about that were big, but there was the
  company need to make things simplier and easier for all.
We have also some partner bug tracking systems incorporated (with proxies) into that bugzilla, to enhance and ease information flow. This is working ot
  a certain degree quite good, but sometimes we see where its limits are.

  BUT while I have my doubts, I think some "Master" upstream bug tracking
  system where all "downstream" bugsystems are connected to or incorporated
  would be an interesting thing.

> There are probably more things to be discussed, but before continuing
> the discussion among the GNOME people we believe it would be great to
> gather some initial responses and see what you would be expecting or
> needing from the GNOME project. Should there be any extra comments you
> feel is important to convey please do feel free to let us know.
Well, as mentioned above, the biggest concern we always have with updates is
"Are we still compatible with the old library versions, where Third-Party
Certifications may impact us?"
In addition, changes in the package dependencies and renames of packages have
been proven to be a pain for us. I'm not saying we had seen this a lot from
GNOME, or that it's unsolvable on our side, but just wanted to mention it :)

> I look forward to hearing from you at your convenience and remain
> available for further clarification if needed.
I hope the comments help you to understand our needs a little bit better. I'm
convinced that there's quite more to add, but the important thigns should be
covered above.
Let me know if you have more questions or suggestions how to improve co-operation.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]