Re: Better collaboration with distributions [Novell response]

[Frederic Muller <fredm gnome org>]

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
missing
> > 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
what
> > 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
  approach'.

> > 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.

	ciao,
	  Stefan