Hi everybody, Lately, we have been working on ways to make darcs development go faster. Our goal here is to increase the number of expert darcs hackers with time to work on the project. To achieve this, we intend to give developers better feedback (growing them into experts) and in more timely fashion (so that they can work more quickly). Here are the changes we think will help us get there:
Development model ----------------- 1) David Roundy will be the maintainer of the new darcs unstable repository. This will be made available shortly at http://darcs.net/unstable 2) Eric Kow will be the maintainer of the stable repository http://darcs.net 3) Patches will typically flow from unstable into stable. However, if Eric feels that patch is obvious and not likely to require discussion, he will apply it directly to stable. For the moment, Eric only considers code comments, documentation and test suite modifications to be obvious. 4) The stable repository will be tightly kept in synch with unstable repository. Patches should make it from unstable to stable within the same day unless either David or Eric feel they are not yet ready for stable. 5) This has always been true, but it's worth stressing again. *Everybody* is encouraged to review incoming patches. This extra review helps contributors because they get more than one perspective on the code, and also because it helps patches to get accepted faster. Also, reviewing patches is one of the best ways for you to to learn about darcs! 6) Eric will also be serving as the new release manager. 7) Darcs will now be switching to a new time-based release model with new releases coming out every six months. The first release in this cycle will be in January 2009. In the meantime, we will work towards getting an intermediary release out to fix bugs in 2.0.2 and to provide some performance improvements through http pipelining. How this will help ------------------ We hope that these changes will have the following effects on our community: * Small 'obvious' patches that help us improve our infrastructure or documentation will be fast-tracked into the stable repository. This This allows us to more quickly get `safe' changes and clear bugfixes into the hands of our users. * Having a stable branch relieves some of the pressure for contributed code to be perfect. We know some developers feel that getting patches into darcs is too difficult, and hope that having the unstable branch can help some code become a part of darcs. But let us stress one point: we do not intend to give up on the rigorous reviewing of patches, so please do be prepared to answer questions and resubmit patches as usual! * Tight synchronisation between stable and unstable means that we can have greater confidence the stable code can be well tested (before, people interested in darcs would mostly use the unstable repository), and also allow people to contribute to the stable branch directly (because unstable won't be so far from stable as to cause trouble) * Time-based releases (in conjunction with quarterly darcs hacking sprints) will force us to finish a small number of key goals at a time. Users will see more regular progress from the community, and we will hopefully see them using our more recent work. We hope you'll like these changes. Please let us know what you think! Thanks, David and Eric -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9
pgpSv9fqi8Uqa.pgp
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
