[sldev] [IDEA][META] hg branch for trivial changes
sllists at boroon.dasgupta.ch
Fri May 1 06:26:33 PDT 2009
I plan to clone http://bitbucket.org/lindenlab/http-texture/ to have a
place to collect trivial changes to the viewer code base, such as fixing
typos or indentation. Before I do so, I'd like to hear your opinion
Past and current situation
If I remember correctly, Linden Lab once discouraged us from sending
them indentation-only patches, because the overhead to review and import
them was too much in relation to the benefit of such changes. Instead we
should clean up code while working on the specific parts for bigger bugs
of features. This is quite some while ago, so I don't know if that's
still the current recommendation.
However, this neglects that working on such small and trivial changes
gives new and unexperienced (potential) contributors the opportunity to
get to know the source while not having to fear to break something.
Also, while the individual trivial changes are probably rather
unimportant, together they should greatly improve the experience of
both, developers working on "real" features and bug fixes, as well as
the casual reader of the code who tries to figure out how something works.
So I'll keep a public clone of LL's most active public hg branch
(currently http-texture) where such trivial changes will be collected.
If you have such a change (or several), send me a pull request
(preferred) or a patch. LL can then regularly pull from my clone and
review several such changes in batch. To make it possible to do this in
some fast-forward manner at LL's side, I'll review the changes I'll pull
myself and filter them according to the following principles:
* functional triviality, which means
o no change in behavior of the viewer (e.g. fixing indentation
of a non-python source file) or
o change towards the expected/wanted behavior when it is
relatively save to assume nobody is relying on the current
unexpected/faulty behavior (e.g. fix a typo in debug output)
* code triviality
o the functional triviality should be trivial to see (i.e.
major code refactoring doesn't qualify for this branch)
* creative triviality
o LL should be able to safely apply the changes, even with no
contribution agreement from the contributing developer on file.
Of course, because I'm not LL's legal department, I'll have to guess
about the last point, but I think knowing that I already have checked
and decided about that issue for the changes in my clone will still save
LL some time when reviewing those changes.
I'll keep this in FAQ/Q&A style, only that I've invented all the
Aren't these rules too strict?
I recognize they're rather strict, but they're probably necessary to
guarantee the changes can be imported by LL as quickly as possible.
Also, I think there are very much potential changes that match these
strict restrictions, so having a branch for them might be worthwhile.
Why no major refactoring? That's important, too.
Yes, it is. But it's harder to review and will in most cases warrant its
own branch. Remember, with hg, branching is almost free and merging,
while still work, is much easier.
Why not just collect patches for such changes in a PJIRA
issue, and have LL import that?
While creating a patch and creating a hg changeset is about the same
amount of work, managing patches, applying them for testing and
combining them is very tedious. Also, we would have to either keep one
issue constantly open or create a new one from time to time, which both
makes triages more complicated which shouldn't be needed at all for the
changes in question.
How will your judgment save LL any time? They'd either have to
trust you or review everything as accurately as they would
Of course, because my contributions up to now where rather marginal, LL
doesn't have any reason to trust my judgment initially. I hope they'll
start pulling from my clone just for the convenience of having all these
changes available at a single location. I'll give my best to prove
myself worthy of being trusted, so they can pull more and more "blindly"
after some time.
You'll personally review everything? That doesn't scale!
Once the work gets to much for me alone (or even before), I can invite
other contributers as reviewers if I trust them by giving them
commit/push permissions to the clone. If even that doesn't scale anymore
(which won't be any time soon), we can easily switch to cascaded review
as used by the linux kernel where everyone pulls from repositories they
trust until stuff ends up in the 'central' one.
What should we name that clone/branch? "slviewer-cleanup" doesn't quite
fit, because there will be some changes qualifying for this branch which
aren't pure cleanup. "slviewer-trivial" sounds like a trivial
implementation of an SL viewer, which this won't be, as it'll build on
the current code base.
Until the move to hg is completed, will LL keep the http-texture
branches in the SVN and hg repositories in sync enough?
Would this branch and process actually be useful for LL and/or the OSS
Please let me know what you think!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SLDev