One problem I see is that many of the crash bugs in bugzilla can not be reproduced on linux/unix-x32 which seems to be
a common platform.
In particular some crashes can only be reproduced on win32 platforms and if lacking the development environment and
debugger for that platform ...
Would it be possible to open the w32 buildbot slave up for VNC access so that those win32-disadvantaged of us could access a
real win32 host to work on those bugs?
It would obviously require VNC ontop of something like OpenVPN or similar.
On 3/15/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
Gerald Combs wrote:
> The next big step in improving Ethereal's security is to branch off a
> stable release.
>
> Ethereal changes quite a bit over time. The
> "patch-ethereal-x-to-y.diff.bz2
" files that accompany each release
> typically exceed 200,000 lines. For some perspective, this is more
> lines of "diff -u" than Apache has lines of code (~ 130,000).
>
That's really a lot, I'm surprised ...
> A side effect of this high rate of change is the introduction of bugs
> (some of them security-related). While a release might fix several
> vulnerabilities, it will typically introduce several more.
>
Ack, that's the way it was in the past all the time.
> Once the Coverity defect count goes to zero I plan on creating a stable
> branch, which shall only receive bug fixes.
What about the bugzilla entries. I just had a look and marked all bugs
as critical which are causing a crash,
there are ten critical ones left.
However, who will actually do the bug fixing in the branches? Let's be
honest: We currently cannot (or don't want to?) keep pace with the new
bugzilla bugs rushing in. And there are not that many developers really
fixing bugs of the existing code base.
> I'd like to call it "0.99"
> and use it to create a "1.0" branch some time in the future, like so:
>
> 1.0---
> /
> 0.99.0 0.99.1 0.99.x---- 1.1or2.0
> / / / /
> 0.10.14 0.99------------------- ?.0 ?.1 ?.x--
> / / / / /
> -------------------------------------------------------> Trunk
>
>
Why creating another
1.0 branch instead of simply continuing the 0.99?
Once there's the 1.0 out there's no reason to maintain the 0.99 branch.
We can continue with 1.0.1 and so on for the stable versions.
Please don't underestimate the effort which each new branch (not
creating but maintaining it). I'm doing this all day and it can be
*very* annoying. So preventing too many branches is usually a good idea.
> Why 0.99/1.0? Whether we like it or not, people have been treating
> Ethereal as if it's "1.0" and have been using it in production
> environments for a very long time. Calling it "alpha" or "beta" quality
> with version numbers like 0.10.8
defies reality.
>
Ack
BUT: We shouldn't try to get a release without having release quality.
That includes IMHO at least security related things like privilege
separation and the updater function for the Win32 platform finished.
> I'm not sure what to call any unstable releases that come from the trunk
> _after_ the 0.99 branch, however.
>
Why not following the usual way "odd" for development and "even" for
releases, with a 1.2 or 2.0 for the next release and so on.
0.99.0 0.99.1 1.0.0 1.99.0 2.0.0
/ / / / /
0.10.14 0.99--------------------- 1.1.0 1.1.1 1.99--------- 2.1.0 2.1.1
/ / / / / / /
---------------------------------------------------- ... -----------------------------> Trunk
However, I'm *really* unsure if we can provide the effort of maintaining
both the developer and the release version. After a relative short time,
both versions will differ a lot, so merging changes from the release to
the devel or vice versa are practically impossible, resulting in having
to code two implementations for a bug fix (doing bug research twice,
etc.), which is obviously annoying.
Another problem is: When to release a new stable version? Doing a
release too late results in a lot of double effort and releasing it too
early results in several new fresh bugs.
Maybe I'm looking at things to complicated and this will work perfectly :-)
Regards, ULFL
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
