[oi-dev] Procedural question for developers: working on several bugs in parallel

[Jim Klimov]

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