Hello all, I am still trying to *properly* get started on some bug-squashing, and document the procedures (or update existing texts) as HOW-TOs on the Wikis for the benefit of other newbie-contributors (including myself when I forget some steps).
So far the Wikis tell us how to set up the compiling environment, clone a repository and compile the code in the resulting workspace. They even go as far as suggesting ways to bring attention to these changes, i.e. publish a webrev, gain a few LGTMs and submit an RTI. However, it seems likely that newbie-contributors (like me) would first start with bite-sized bugs (like me), so the workflow of having several one-hour tickets in progress per person seems realistic. So, say I want to squash a few small bugs (i.e. some manpage updates and some 3rd party software basic integrations, or some Makefile tweak, or whatever). Such bite-sized bugs are so small that work on each bug takes a small time, while waiting for public approval can take some days. Reasonably, I'd want to churn out several webrevs, each dealing with its (small) bug in parallel - perhaps of interest to different teams of reviewers on different mailing lists, and not serialize these works (squash one, review, revise, RTI, only then squash a second bug...) - such serialization would be wasteful as in "killing time and losing enthusiasm". Now, it seems proper that works on different bugs should take place in different repo clones, or different branches of one, so that a full diff (webrev) would only pick out the changes relevant to that one bugfix. Especially since after reviews and fixups there would be several local repo commits regarding evolution of development on this one bug. While it seems possible to repeat the public repo-cloning approach in several different directories, this is wasteful on disk space(*) and internet traffic, and generally seems a wrong way to go. Then again, maybe it is not, and real people do just that? (*) A forward-thinking admin would likely pull a public repo into a ZFS dataset, then make its snapshot, and then clone it for each such unrelated subproject of his. Still seems like a wrong hassle misusing source-control management systems ;) Hence the questions: how do advanced programmers here tackle the matters of repo branching or whatever needs to be done to do more than one work (have more than one ticket open) at once? I plan to try out the responses and aggregate them into a Wiki page for the illumos and/or OpenIndiana wiki... Thanks in advance, //Jim Klimov _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
