Re: [GnomeMeeting-devel-list] Re: Remove GnomeMeeting from Gnome module list?

[Christopher Warner <zanee kernelcode com>]

You know Damien, this whole argument and discussion isn't constructive
at all. No one has stepped up to assert and respond to these claims that
GnomeMeeting is causing problems. There is no history of such thing, no
one has ever contacted you except for one party and I just don't see any
resolutions being proposed by the accusing party.

What we need is:

1. What is the exact problem and how we can fix it. If the problem is
that there is to be a new release of GnomeMeeting everytime Gnome is
released then obviously that cannot be done.

2. What else is there that is causing problems, Who are having these
problems and can they be cc'd or can we contact them as to these
problems so they can be fixed.

If none of that is provided, this discussion is a practice in futility.
It's really starting to sour me to the whole Gnome project and attitude.
I've been using Gnome since its inception and to see items like this
that don't improve the project in any fashion or streamline anything; is
telling of current leadership. Especially if something that is really
not an issue is being discussed in such length. Volunteering ones time
and efforts in light of all this becomes not only inherently difficult
but stressful at the same time. The bureaucracy involved for this
"issue" is alarming.

So; with that said can the above two points be provided because all of
this talk and I'm still confused as to what exactly the problem is and
how one would rectify it. Is it that one needs a new GnomeMeeting every
release? Danilo, what would you be satisfied with? A new version every
release?



On Wed, 2005-01-19 at 12:28 +0100, Damien Sandras wrote:
> Hi Mark,
> 
> Le mercredi 19 janvier 2005 à 11:13 +0000, Mark McLoughlin a écrit :
> > Hi Damien,
> >
> > 
> > 	So, I think what's more important to us is not that modules make a
> > release for each GNOME release, but that if they are being actively
> > developed then they make a release. The philosophy is very much that the
> > GNOME schedule should not be feature based, but time based. If some
> > GnomeMeeting features weren't ready for GNOME 2.8, I would have expected
> > those features to be disabled, the rest of the work stabilised and a
> > release made for GNOME 2.8.
> > 
> 
> Really that was not possible. I was still working on that. Disabling the
> new address book code meant reinserting the old code. It was easier to
> keep 1.0.2 than reinsert the old address book code together with the new
> features. I would have spent 2 weeks doing that and at least 1 week
> stabilizing the rest, I can not afford that given my relatively weak
> spare time.
> 
> The problem is the same with SIP. I can not release a version that
> half-works just to be in time with GNOME 2.X.
> 
> Again, if it is preferable for GNOME to remove GM from the modules list
> because of that, then that is perfectly OK with me. GnomeMeeting will
> stay in the GNOME CVS, keep the bugzilla and mailing lists on gnome.org,
> but evolve totally separately. I'm not against this, it will put less
> pressure on my shoulders.
> 
> > 	The external library issue is hard - I don't know how you deal with
> > that. Maybe not use any new APIs from that library until a somewhat
> > stable release of those new APIs have been made?
> > 
> 
> We are in general working with their CVS, and when we consider it is
> ready for us, we ask for a new release. If it is possible to do a new
> release, then they do it. If not, then we delay our own release. 
> 
> I'll take the SIP port as an example. I'm contributing to the evolution
> of the new APIs for SIP, so I can not really wait until they do a stable
> release or those new APIs never get tested, and it leads to problems and
> undiscovered bugs when releasing.
> 
> I'm not trying to be stubborn or uncooperative here, but there are
> things I can do, and others I can not do.
> 
> If the things I can not do are an obstacle for GNOME, then I will accept
> the removal of GnomeMeeting from the modules list. 
> 
> If the release team decides it is not an obstacle, then I will keep
> doing my best, but the best I can do is promise to do a new minor
> release when GNOME is released.
> 
> I have absolutely no idea when GM 2.00 with SIP support will be ready.
> That's a complete rewrite, even for the H.323 part. It is a good example
> that shows that I can not, in this case, promise a release in sync with
> the GNOME release, and that I can not remove unstable features as
> currently 1.2 working features are broken with all our changes to add
> SIP. Six months are not enough when you are beginning such big changes
> and working only a few hours every night and all week-ends.
> 
> > Cheers,
> > Mark.
>