RE: [java-gnome-hackers] Looking forward

[Jeffrey M. <Jef...@Br...>]

> I agree with Mark: do you remember how many bug reports we 
> have had when
> we released 0.8.2 (and joined the official bindings)?
> We couldn't take care of our users whining for a 0.8.3 
> release, cause we
> were in business with 2.5.3.

Perhaps a good compromise is for us to target a 2.6.1 release
one month from the release of 2.6.0.  During that time we can
just focus on the Lazy Event Registration, GDK enhancements,
gconf enhancements and bug fixes.  We would not create a branch
in the code until that release went out.  

> I think, maybe, we should look more to the practical 
> aspect...(really no offense intended:))
> We should ask ourselves: do we need 64-bit support? Who is 
> going to use
> it in the near future? Is someone managing to build a useful app with
> it? (well not that I want a promise of faith but maybe someone could
> have been hired to write something with it (like Bob Fischer with the
> iPaq...))
> What I say is that if we are going to add 64 bit support only because
> having it is fine, perhaps we could work on the existing code to fill
> the holes that are present in the bindings, instead. (like DnD...)
> In this way, I hope we'll see more applications spreading 
> out, cause our
> users will have a stronger and more complete library to play with.

My main concern is that the 64-bit fix will be fairly intrusive
into our code.  I fear that the longer we wait the more difficult this
change will become.  If everybody feels we should put this off then
I am ok with that.

> My point is that it's better to keep fixing bugs for the 2.6 release
> while our users will ask for them. Then we could accept 
> patches for the
> 0.8 branch but we should explicitly encourage people to use 
> 2.6, because
> of the large changes that have been done.
> 
> I'm tempted to say that Jeff, Mark and Jonas could take the devel
> branch, and work on adding new modules , on keeping in sync with
> gnome,and on adding 64bit support (if it's really needed), 
> because this
> is the more work, while the others and I should maintain the stable
> branch (with a lot of help from you of course...:)).
> But since I understand that, at least Mark and I are a bit under
> pressure with the uni, I don't know if this idea could fit at the
> moment...
> So maybe the best solution now is to wait until the gnome-2.7 release
> cycle to add new modules and 64bit support. In this way we can start
> from a heavily fixed version of j-g-2.6.X without the need of
> backporting anything. When the 2.7 branch will start, then I 
> could take
> care of backporting eventual fixes in the 2.6, but since it has just
> passed a six months bug-busting period, hopefully there will 
> be few bugs
> to fix between 2.7 and 2.8.

The majority of the bugs that will be found will need to be fixed
in 2.7 and 2.6.  We clearly need somebody on the team appointed
the stable release maintainer.  This person will need to backport
fixes to the 2.6 branch and make periodic releases.  I think this 
should not be a full time effort so this person could also work
on the development releases when not working on stable releases.
This would start after the release of 2.6.1 (around the middle of
May).  

> I would take care of fixing the stable branch, and I think 
> this implies
> also implementing DnD...but are you talking about to get it fixed
> *before* we release final? Because, unfortunately, I will 
> find a bit of
> time only after 17th.

I think DnD is something we should try to get working during
the 2.7 development effort.  Here I am talking about both
Widget and TreeView DnD.  There is already a lot of code here
but it is incomplete.  We should also add Clipboard support as
well.

-Jeff








 NOTE: THIS IS A CONFIDENTIAL COMMUNICATION. This transmission is intended
only for the use of the individuals or entity to which it is addressed. If
you are not the intended recipient, or the person responsible for delivering
the message to the intended recipient, please return or delete it
immediately. Although this e-mail and any attachments are believed to be
free of any virus or other defect, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by us for
any loss or damage arising in any way from its unauthorized modification or
use.