(Whoops, forgot to reply all.) I have the pkgsrc and DragonFly release stuff both in there because they affect each other. I don't have a problem with 6 month release cycles, but there's nothing supporting a need for it. - we've had a number of releases where we delayed well past it.
Tracking what's stable at time of release is what I do now. Which works for the release versions, but perhaps not for non-release. I've always been worried about breakage with that. I'd rather have two DragonFly categories: One where the long term support where there's always packages and any system updates are minor, to guarantee a stable platform. The other, where there's clear expectations the user will update the system and pkgsrc on a semi-regular basis. This is, I think, sort of like Debian 'stable' and 'unstable', in a broad way. The goal here is to have release strategy match the usage patterns I've observed in general. On Sun, Sep 11, 2011 at 12:11 AM, Chris Turner <c.tur...@199technologies.com> wrote: > 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. > > for really-long-term-release: > > 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 > > for head-builds: > > 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 > > cheers, > > - Chris >
