> Packs are the only really significant new user feature awaiting release. > I'd hold the release for them - what's the hurry ?
Releases are sign of vitality for both users and developers. As someone who has maintained some Perl projects for several years, I've learned it's a morale booster for contributers to make a contribution, and see that quickly turned around and appear in a release. Related to that, people also like to see their names appear in the ChangeLog, as a contribution they point to with pride. (And perhaps something they whould show to a new employeer as evidence of skill). Right now the darcs "NEWS" file doesn't provide any direct credit to the contributors for a release. I recommend listing the contributors here in some form. It could either list names next to each feature, as some do, or at the bottom of a release section, it could say: "Thanks to XXX, YYY, ZZZ and the darcs community for their contributions for to this release." Who following along here would prefer to their name in the ChangeLog? Who here would like to see their contribution released sooner rather than later? I appreciate the concern about a buggy or underwhelming release, but that's not the only public perception and motivation issue to be balanced here. Check out the top item from the darcs blog: http://blog.darcs.net/ It's a "weekly" news item, but it's dated back to July (a bad sign). The top item is an announcement that 2.8 will appear in August, but August has come and gone with no follow-up (another bad sign). The darcs blog should be immediately updated with a status update of some sort to adjust expectations. I had thought darcs was a time-based release cycle, in which case major features are not always to be expected, just that the release appears on time. Whatever the reason for the delay or the new release plan, *something* should be made public to update expectations about the new release. As it stands on the blog, it looks like darcs suddenly went dormant in July. What I saw from the ChangeLog review was very different story-- there about 1,000 patches that are basically read to be released in a new version! > And in any case I > wouldn't ship them in a .1 bugfix release. This could be a matter of framing, then. I've found you can release alphas, betas and release candidates all year long, but there's no substitute for the kind of feedback you'll get once you declare something stable. Sometimes the fastest route to a stable product is to declare it stable, get some real-world feedback, and quickly incorporate refinements. Frame it that --packs *are* in the 2.8 release, but are not on default as experimental feature with some known issues that need refinement. Use the release as a platform to call on developers and users to help with those refinements. I think it would be great motivation for developer to get the remaining bugs fixed, if they could have the feature being used by real-users, with the expectation that their fixes could be quickly turned around into a follow-up release. I also disagree that "--packs" would be the only thing of interest to users. In my ChangeLogging, I found a number of new user-visible subcommands that were added, removed or changed. There are really a number of things happening with this release. Perhaps I could summarize the user-visible stuff in a blog post which could both increase interest among users, and help motivate developers to wrap things up. It seems like some sort of concrete plan towards release is needed. Pointing to the tagged issues in the bug tracker may be perfect, but one can see what stands between now and release. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
