Source repositories, unionmount code

[Thomas Schwinge]

Hello!

Instead of following up to each email individually, I'll combine some
answers in here.


On Sun, Sep 06, 2009 at 11:45:34AM +0300, Sergiu Ivanov wrote:
> On Sat, Sep 05, 2009 at 04:04:19PM +0200, Arne Babenhauserheide wrote:
> > How did the GSoC work out?  
> 
> antrik gave me a passing final evaluation, so (at least formally) the
> GSoC was a success.

Congratulations!

> In my local repositories I have a working
> implementation of what I understood was expected of me.  However, I'm
> not sure as to whether these changes should all go in the public
> unionfs git repository or not :-(

There is absolutely no reason why they shouldn't go into the Hurd
repositories at Savannah.  Please, everyone, realize that these
repositories are mainly to be *USED* by *YOU*, the developers, and
they're only secondary to be used for publishing a crystal-clear /
no-error changeset history.  Please *ACTIVELY USE* the machinery that we
provide.  It really seems totally absurd to me that you, one of the few
active Hurd code contributors would (have to) publish his stuff on a
third-party server (github, gitorious).

And if you're afraid or installing stuff into master or master-TOPIC
branches, then we can also use the scheme à la SAVANNAH_LOGIN/WHATEVER
for branch names.  What you do on the scolobb/WHATEVER branches is
totally your own business.

Even for publishing the various variants of your patches in the progress
of development, I'd have used scolobb/unionmount-FEATURE-mark1 .. mark23
branches (or scolobb/unionmount-FEATURE-2009-07-07...) (each of them
based on the then-current unionfs master) instead of only publishing the
in email.  Email is fine for discussing patches (which we've successfully
been doing), but also for creating a bit of a mess and losing track of
the whole thing (which we've successfully been doing).


On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafBuddenhagen@gmx.net wrote:
> On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote:
> > On Sun, Sep 06, 2009 at 12:20:11PM +0200, Arne Babenhauserheide wrote:
> > However, I'd say that we somehow failed to discuss how exactly to make
> > the code public :-(
> 
> Actually, we did discuss it. We agreed that it is fine for now to have a
> unionmount branch in the main unionfs repository -- though ultimately I
> want to see both as part of the main Hurd tree...

Why, oh why?


> However, only approved patches should go into the main unionmount
> branch. So what to do with those that still need review/fixing? Usually
> each such patch series would go into a topic branch in a personal
> repository. Unfortunately Savannah doesn't offer personal repositories;
> so this leaves us with two options: putting the topic branches in the
> main repository as well; or putting them in some other repository, e.g.
> on gitorious...

As I said above: main repository, but personal branch(es).  Simply let
branches like SAVANNAH_LOGIN/* be our way of having a personal
repository.  And this is not common: other project are also working like
this.


> > I'm rather inclined to consider that shipping unionfs and nsmux with
> > LiveCDs and QEMU images is not an imperative to encourage their
> > testing.  Potential users could just as well download the code or
> > clone the repositories locally.
> 
> Yes, they could. But it's a *considerable* barrier. In practice, it
> simply means that hardly anybody will do it, so it's left to rot -- just
> like all the stuff in hurd-extras...

Part of this is simply a packaging problem -- that is, that these
translators are in fact not packaged for Debian.  Can't someone simply do
this eventually?


> > Note that as opposed to some other translators (like Zheng's
> > eth-multiplexer), both unionfs and nsmux were designed to be
> > stand-alone,
> 
> ...which is the reason why I still haven't tested nsmux -- I'm still
> waiting for you to integrate it in the Hurd tree

That doesn't make any sense.  If you're interested: just get the source
code and run make.  Why does it need to be part of the Hurd code
conglomerate in order for you being able to test it?  And yes: they
should remain stand-alone.  I will integrate these packages into our git
repositories soonish.


On Mon, Sep 07, 2009 at 10:44:00PM +0300, Sergiu Ivanov wrote:
> I'd rather refrain from pushing my personal topic branches to the
> unionfs repository -- this does smell of something like messing things
> up.

And why exactly?  Again: these repository infrastructure is meant to *be
used*, to *be worked with*, for enabling us, the developers, to *make
progress*!  (And only secondary for showing to the world our (few) nice
almost-perfect changesets.)


> On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote:
> > > I'm rather inclined to consider that shipping unionfs and nsmux with
> > > LiveCDs and QEMU images is not an imperative to encourage their
> > > testing.  Potential users could just as well download the code or
> > > clone the repositories locally.
> > 
> > Yes, they could. But it's a *considerable* barrier. In practice, it
> > simply means that hardly anybody will do it, so it's left to rot -- just
> > like all the stuff in hurd-extras...
> 
> Hm, you are probably right, but it's still hard for me to comprehend
> the attitude of a potential user who would test something they have in
> the LiveCD and wouldn't do that with something that's a single
> git-clone away :-(

Indeed.  The type of contributors that we're mostly interested in are
those who are not afraid of compiling the source code themselves.  All
the others may still be valuable, but it's the former kind that we're
*interested* in, and which will be able to contribute without in-depth
training.


On Mon, Sep 07, 2009 at 11:00:40PM +0300, Sergiu Ivanov wrote:
> On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafBuddenhagen@gmx.net wrote:
> > On Sun, Sep 06, 2009 at 02:30:46PM +0300, Sergiu Ivanov wrote:
> > > Note that as opposed to some other translators (like Zheng's
> > > eth-multiplexer), both unionfs and nsmux were designed to be
> > > stand-alone,
> > 
> > ...which is the reason why I still haven't tested nsmux -- I'm still
> > waiting for you to integrate it in the Hurd tree, as I requested again
> > and again.
> 
> Yep, I can't say I don't remember that you have been asking me to do
> this for a long time already.

I don't see the point and I won't push this to the master branch.  I
still have to see a compelling argument why *all* Hurd code should be
made part of the big existing Hurd code conglomerate.


> Firstly, as I have already said (and as you have already seen), the
> majority of my commits to my nsmux repository are very ugly.
> Everything is on a single branch, the commits are not grouped together
> by functionality, etc.  I remember someone (either you or Thomas)
> suggesting to throw away this dirty history and just start doing
> normal source code management from what I have now.  Is this an
> option, or should I try to tidy up the repository, or should I leave
> things as they are?

Do not spend time on cleaning it up.  What would be the benefit?  Do you
want to document the steps it takes to develop a translator, and then
evolve that into a translator design and programming book?  (Which would
be a possible goal, but isn't yours as far as I know.)  Or are you / we
more interested in the first working version of the translator, for then
using that one as a basis for further commits?

See, the separate-commit-per-change thing is good for two reasons, as
Olaf also already said: for the sake of it a.k.a. showing the world how
nicely we can do; allowing easy regression testing.  Neither of them is
really compelling in your case.  (And again, of course it is nevertheless
good to practice working in precisely this way -- which you have done --
but there's no need to retrofit anything like this.)


> Another serious issue is that my source code is full of weird stuff:
> comment lines, improperly formatted comments, etc.  Should I try to
> correct these?  If so, how should this go: a clean-up patch or a patch
> series?

I'd suggest to simply not care about this for now.  We'll care about this
as soon as we promote your code into some official position.

> And the last question is about the integration itself: how exactly do
> I take my nsmux git repository and integrate it into the Hurd git
> repository?

You don't; I'll do.  But not into the main Hurd repository.


Regards,
 Thomas

signature.asc
Description: Digital signature