On 7/1/06, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
On Sat, 1 Jul 2006, Ulf Lamping wrote:
> Kukosa, Tomas wrote:
> > Would not it be better to make /trunk-1.0 as late as we have implemented
all features planned for 1.0.0?
> > Then the /trunk-1.0 would continue only with bug fixies.
> >
> > I am affraid when we make /trunk-1.0 now we will come to the same
conclusion during next release, i.e. to forgot /trunk-1.0 and use /trunk.
> >
> I had a similar feeling.
>
> Looking at the way the story went: the work of copying over from the
> experimental to the stable branch was an overhead that caused a lot of
> confusion and unpleasant work.
>
> So in my eyes it was a try that failed. However, doing the same mistake
> again would be dumb, as I don't see any reason that it will work the
> next time.
>
> The purpose of the stable branch was to raise the quality of the release.
>
> We might take other mechanisms:
> - a zero compiler warning tolerance (difficult as we compile on several
> different platforms)
> - a requirement to provide capture files (for fuzz-testing)
> - release more often (to provide at least fixes for the known and
> currently fixed bugs)
> - don't accept substantial changes near release time (no new dissectors,
> ...)
>
> I know that the "renaming session" took a lot of recent effort, but I
> think the former method of simply release often did a better job than
> the current "splitted branches" solution.
>
> Regards, ULFL
FULL ACK.
Having a develoment trunk and release branches just take more management
around the time of the branch. Calm down on the new stuff, focus on
bugfixes then branch and work only on the stability of the branch. Have a
look at the Linux kernel development process, they face the same problems.
ACK
It also only works when you have a large number of maintainers.
I would estimate that we only have 6-8 periodically active
maintainers, say 6 active ones at any given time (hands up whoever is
always active, im not :-( ) and 1.2MLOC or 200KLOC per active
maintainer at any given point in time.
I'd say we try someting like more automated that more closely aligns
to our aailable resources:
something like :
1, scrap the stable branch altogether
2, make a new automatic pre-release using the buildbot every monday
based on whatever is in current svn.
3, 2 weeks prior to a real release announce that "careful, new release
comunig up in X days, please dont do any destabilizing changes now
for a while".
Also, I would really like if bugzilla could be changed to REQUIRE an
example capture for all "wireshark crashes" bugs that are reported.
I would also really like a VPN/VNC accoutn for the win32 buildbot to
grab stacktraces for captures that dont work well on win32.
Contrary to popular belief, memory management on linux kernels for
redhat 7.1 is different from the one on windows
and many memory related issues just can not be reproduced under a
modern linux install such as rh71
best regards
ronnie s
Thanx,
Jaap
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
