Hi,
No one has had the time to get the ethereal/wireshark configuration
reading stuff sorted out. Anyone have any idea how invasive that would be?
Maybe a waiting point for 0.99.2 branch, which cannot be released without
this anyway, IMHO.
Thanx,
Jaap
On Mon, 10 Jul 2006, Gerald Combs wrote:
> Done:
>
> http://wiki.wireshark.org/Development/IljasBugList
>
> I've made a pass through the list and checked in changes, but it would
> be nice if others could do so.
>
> I'll create the 0.99.2 trunk later today, along with 0.99.2pre1.
>
> ronnie sahlberg wrote:
> > can you put iljas list on a wiki so one can remove each item from
> > the list as they are addresses?
> >
> >
> > On 7/10/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> >> Hi List!
> >>
> >> The current release situation is unsatisfying IMHO.
> >>
> >> The last official release is the Ethereal 0.99.0 version from April 24,
> >> 2006 which is about 10 weeks ago and contains some frequently reported
> >> (and quite annoying) bugs in the win32 export functions (and obviously
> >> elsewhere).
> >>
> >> The official note of the Wireshark switch was at Jun 7, 2006, more than
> >> a month ago.
> >>
> >> But we still don't have an official Wireshark release!!!
> >>
> >>
> >>
> >> There are some known bugs (e.g. the list from Ilja van Sprundel) that
> >> would be nice to be fixed before the next release, of course.
> >> Unfortunately, nobody seems to have the time or motivation to fix them
> >> (including myself) :-(
> >>
> >> However, the reported bugs are certainly in the 0.99.0 release as well,
> >> so every user will be vulnerable to them right now, if we release a new
> >> version or not.
> >>
> >> Releasing a new version would:
> >> - don't confuse our users with the current situation!!! (try to explain
> >> this to someone else and you know what I mean)
> >> - make the new name better known
> >> - release the fixes we've already done (so we won't get repeated bug
> >> reports at least for them)
> >>
> >> So what are we waiting for?
> >>
> >> Waiting for all bugs to be fixed before a new release might not be the
> >> right thing to do, as it postpones the release for fixes we've already
> >> done and there are a lot of them since the last official release.
> >>
> >> The saying "release early, release often" has it's reasons. Getting back
> >> to a release cycle of about 4-6 weeks (which we've done some time ago)
> >> seems to work better IMO.
> >>
> >> Regards, ULFL
> >>
> >> P.S: If the effort to release a new version is too high, then the
> >> release process should be simplified or automated (I guess that Gerald
> >> is still a bit busy from moving) ;-)
> >> P.P.S: One of the reasons I'm complaining is: I'm currently postpone the
> >> committing of some substantial changes to the DCOM dissector for some
> >> weeks now, as I thought we would get a new release shortly. I've
> >> postponed them as they will certainly introduce new bugs. Hmmm, now I
> >> don't have a good backup concept for these changes and setting up my own
> >> subversion server to keep these changes will probably end up in my own
> >> private Wireshark fork (which I really don't like to have).
> >>
> >> _______________________________________________
> >> Wireshark-dev mailing list
> >> Wireshark-dev@xxxxxxxxxxxxx
> >> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >>
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>