DragonFly versioning plan
c.turner at 199technologies.com
Sat Sep 10 21:15:39 PDT 2011
On 09/10/11 20:28, Justin Sherrill wrote:
Here's the problems I'm trying to fix:
think it makes sense to separate the pkgsrc-tracking issues from
the system-release issues as much as possible - these seem a bit
bound up together in the proposal from what I can see
- I've been building pkgsrc quarterly releases for binaries, which is
fine, but it would also be nice to have pkgsrc-current reports to show
how much breakage there would be.
seems like the need for this was bound up with pkgsrc building troubles -
not sure why the ~6/mo cycle is a problem in-and-of-itself otherwise
unless I am mistaken?
yeah - I think the 'preview' stuff is pretty much unused though..
also - too much drift/delta between head and branches makes both bug MFC's
and pkg assuptions break, etc..
for the pkgsrc-branching-vs-df-release:
why not just 'only track whatever is latest stable pkgsrc at time of release' ?
this prevents the problems of needing 2x stable pkgsrc builds for a given release -
if people want new packages ... see 'for head-builds' below
build 'latest current pkgsrc' and 'latest stable pkgsrc'
this isolates pkgsrc instability from git-tip DF users, but
still allows testing / showing 'what will break' in pkgsrc-head
having accidentally tried pkgsrc-head a few times I don't like the idea
of imposing either 'whatever is in pkgsrc head' or '2y old release' on
new/binary users.. personally I'll keep building my packages from stable though..
I don't think we care so much about paying attention / testing pkgsrc-current
vs latest-stable-release breakage - unless I'm mistaken.
the biggest issue imho is getting fixes upstream into pkgsrc and how that
ties into the pkgsrc relases - but I don't have to maintain the build setup :D
and I haven't tried too hard - simply maintained my own '/usr/pkgsrc/local' grab bag
which has long been on my todo list to get merged (aah life circumstances) - having
some kind of 'coordination effort' about this I think would help here but maybe
that's me being lazy and not getting involved with the pkgsrc people.. hmm
also - maybe moving / standardizing the pkg-build scripting in-tree would ease
administration of the builds? e.g. where it's pretty straightforward to reproduce
the 'official build' setup, etc more people can contribute / test / reproduce, etc.
I am admittedly not as involved with things these days as I'd like to be
so .. not sure of all the issues that relate w/r/t build setup .. but..
some 2c I suppose
More information about the Kernel