From: Junio C Hamano Date: Mon, 03 Oct 2005 04:00:12 GMT Subject: Re: What to expect after 0.99.8 Message-ID: <7vfyrjw8qb.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <4340A01F.7040901@gmail.com> A Large Angry SCM writes: > If you were to publish the ToDo to the mailing list once a week it might > encourage more of those patches you want to accept. Hmph. I tend to dislike periodical posting that is more often than once a month. >> * Accept patches to finish missing docs. > > A list of missing, incomplete, and/or wrong docs in the ToDo file would > help focus effort when people (like me) have space cycles. Well, the thing is, I am not good at documentation, especially when I have other interests, and once I start writing a list of missing or incomplete docs, my interests _will_ shift to fill in those gaps and I will end up doing them myself, which means I would not have a chance to place the list in the TODO file. >> Technical (heavier) >> ------------------- > ... >> * Maybe a pack optimizer. > > Huh? Given a set of objects and a set of refs (probably a handful branch heads and point release tags), find a set of packs to allow reasonably minimum download for all of these classes of people: (1) somebody cloning the repository from scratch, (2) somebody who tends to follow the master branch head reasonably closely, (3) somebody who tends to follow only the point releases. >> * Internally split the project into non-doc and doc parts; add >> an extra root for the doc part and merge from it; move the >> internal doc source to a separate repository, like the +Meta >> repository; experiment if this results in a reasonable >> workflow, and document it in howto form if it does. > > I think this is a bad idea. The docs should be part of the project > (repository and head) as the code. Otherwise, they'll become even more > out-of-sync. The point was to make it possible to fork that part off to somebody else; then I do not have to maintain Documentation directory myself anymore, just like I simply slurp the latest gitk from Paul and not worry about it ;-). >> Technical (trivial) >> ------------------- >> > ... >> * 'git merge-projects'? > > Huh? Subject: Re: Merges without bases References: <1125004228.4110.20.camel@localhost.localdomain> Date: Thu, 25 Aug 2005 15:26:36 -0700 Message-ID: <7vvf1tps9v.fsf@assigned-by-dhcp.cox.net>