Date: Sat, 29 Jul 1995 11:18:59 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: paul@FreeBSD.org Cc: jcargill@cs.wisc.edu, jkh@time.cdrom.com, hackers@FreeBSD.org Subject: Re: New 2.1.0-950726-SNAP available - come 'n get it! Message-ID: <199507291818.LAA04233@gndrsh.aac.dev.com> In-Reply-To: <199507291403.PAA06144@server.netcraft.co.uk> from "Paul Richards" at Jul 29, 95 03:03:33 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > In reply to Rodney W. Grimes who said > > > > Names (if Jordan agrees with the proposal) will become: Jordan has agreed and reviewed the change to newvers.sh, I will be commiting it shortly. > > X.Y-BRANCH: ... > > X.Y-BRANCH-SNAPMMDDYY: This was changed to X.Y-BRANCH-MMDDYY (ie, we drop the word SNAP from it, SNAP's are identified by the fact they have a -date on the end of them). > > X.Y-RELEASE: > > This is a release, this requires a commit to build > > a proper release src tree so that things built with > > that src tree also say ``RELEASE''. This will appear > > briefly at the end of a -stable branch as the release > > is merged and such before -STABLE rolls up to the > > next version and all the numbers get bumped by the > > person doing the cvs ops such as tree tagging. [Humm.. > > perhaps the branch should be called ``STABALIZING'' :-)] > > >From a gnats point of view there's a few things I'd like to see. > > If there's a unique release name then we can segragate reports in the > database on a per-release basis. This would include alpha and beta > releases so when we finally adopt a proper release process those who have > alpha or beta copies will have the PR's labelled as such and we can > look up just bug reports for any particular cycle of a release. I am not so sure that we ever want to again call releases ALPHA, BETA, DELTA, etc. The above -MMDDYY gives us the equivelent functionality without the assumption it will always be Alpha, Beta, Release. I am not sure we want gnats to file bug reports by release version as often bugs apply to multiple versions and or releases and need to be handled properly to fix all applicable branches. I do agree we should probably seperate gnats reports by ``CURRENT'', ``STABLE'', or ``RELEASE'' but that is as fine grain as we should get. With the current branching of the cvs tree we can now also do post release critical bug fixes and actually release real src code diff bug fixes quite easily (ie, 2.1-RELEASE.BUGFIX1) though this will require additional man power to manage. The tools are there, we have the branches, we will have the tags, etc. This is a new level of service that has not been done in the past as it was hard to do without the branches, it is a level of service I think our customer base would just _love_ to have. With an inverted .depend tree (something I would love to have) you can even go from src patch to set of effected binaries and produce minimal binary upgrade kits when practical). > Gnats is currently very broken in this respect because releases go out the > door without the send-pr version getting bumped. That part should be easily fixed now with the new version of src/sys/newconf.sh for build time data, and using uname for run time data. I would like to see send-pr report both, as the build time of send-pr can give a clue about the base binary set, and the run time uname data lets us know which kernel at least. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507291818.LAA04233>