Here's a summation of the thread, just cause it got long, cause some of my original ideas have changed based on feedback, and the results affect everyone:
- I'm proposing changing how we do releases and handle pkgsrc releases, since they affect each other. I'd like to move to a 1 year+ time between stable releases, and generally point people at dragonfly-current for normal installs unless they require something as stable as possible for production. - This will require more MFCs back from current to stable. It will require less release work, and reduce the amount of work required to sync binary pkgsrc packages. - I would switch to building pkgsrc binaries of the latest stable quarterly pkgsrc release on DragonFly stable only. (They would be usable on DragonFly-current without spurious warnings at this point, assuming the major release number for DragonFly is the same on stable and current) - I would build pkgsrc-current on DragonFly-current, catching any problems in compilation sooner. We have several wrinkles that have prevented this, listed with mitigating factors - - pkg_install will refuse to install binary packages built on a newer release of pkg_install, so it requires manual intervention to move between quarterly releases. I think that will be solved either in pkgsrc (talking to Joerg S. about it) or as a feature of pkgin (talking to iMil about it). - The intersection between 6-month DragonFly releases and 3-month pkgsrc quarterly releases made timing difficult. Going to a rolling release makes synchronization issues happen less often, or go away, depending on how smoothly we can build. - Less releases means less press from a version number change, but I'd argue they aren't that effective, especially when we don't a major feature to match the number change. I would argue that we need to trumpet new features, as vkernels or Hammer are far more complex than a version bump. Any other feedback? Francois, you had the longer list of objections; does this feel more like it's on the right track?
