Working with branches after 4.6

Brian J. Tarricone bjt23 at cornell.edu
Sun Feb 22 06:38:36 CET 2009


On Sat, 21 Feb 2009 09:24:48 +0530 Biju Chacko wrote:

> Brian J. Tarricone wrote:
> > Stavros Giannouris wrote:
> > 
> >> How about using transifex[1] for this, which is made to solve this
> >> exact problem?
> > 
> > Actually, looking at it, transifex doesn't seem to solve this
> > particular problem.  It still appears to require that all the
> > individual translator contributors have login credentials to the
> > source repository, which means we'd still have to set up
> > fine-grained permissions for the git repos.  Not saying transifex
> > isn't a good idea, but it doesn't solve any new problems with the
> > git transition.
> 
> What has worked for me in similar situations is to not worry about 
> fine-grained permissions. Being given access should be enough
> validation that a translator *isn't* an idiot or malicious.

Sorry, but I'm a firm believer in the principle of least privilege.
Cleaning up and tightening permissions on our svn repos has been on my
todo list for a while; I decided I'd postpone until we switch to git.

> And if occasionally somebody goofs up -- hey -- it's a
> version-control system, just revert it!

Unfortunately that's not always so straightforward with git.  I'm
reminded of a semi-recent incident with nouveau's git repo, where
someone (innocently) messed up and the master branch got pointed to...
nowhere.  It took some intervention on the server by an admin to fix
it.  Restricting the set of what people can do to only what they need
to do preemptively avoids a host of problems, many of which you
wouldn't even think of beforehand.

> I'm guessing that trusting people to do the right thing will reduce
> the overall effort.

It's not that I don't trust people (well, I don't, always, but that's
not the point), but people screw up -- it's human nature.  I'd rather
put things in place up front to help mitigate those possibilities.

> PS: Alternatively, since it's git, it should be fairly easy to make a 
> relatively small number of people (2 or 3) conduits for all patches.
> If it works for the Kernel it should work for us.

Yeah, it's true... but that's how we used to do things, at least where
i18n stuff was concerned.  And that was a mess -- there was a huge lag
between translators submitting updates and the updates landing in
cvs/svn.  We don't have the kind of bandwidth for these things that
Torvalds does.  (Also remember that lately his job is basically *only*
to merge patches.  From what I recall he writes very little code of his
own these days.)

	-brian



More information about the Xfce4-dev mailing list