Re: Source repositories, unionmount code

[olafBuddenhagen]

Hi,

On Mon, Sep 28, 2009 at 10:16:15AM +0200, Thomas Schwinge 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:

> Simply let branches like SAVANNAH_LOGIN/* be our way of having a
> personal repository.

Is it really a good idea to use slashes in branch names?...

(Otherwise I'm fine with this approach -- though I still think it's
really a kludge.)

> > > 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?

Perhaps someone will *eventually*, and then the situation would be
somewhat different indeed. (Assuming the packages get installed by
default.)

But that's not what we have now. And we have interesting new translators
that want to be first class citizens *now*, not 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?

Short answer: it's easier for me, because it's the way I'm used to.

Also, we agreed during last year's GSoC that we will handle it like this
for all projects, and Sergiu has constantly been promising to do it soon
-- so I have been postponing my testing until it's done...

> On Mon, Sep 07, 2009 at 10:44:00PM +0300, Sergiu Ivanov wrote:
> > On Mon, Sep 07, 2009 at 01:53:08AM +0200, olafBuddenhagen@gmx.net
> > wrote:

> > > 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.

I for my part am not afraid to compile source code, and yet I'm
generally reluctant to try new things that require any investment,
unless I have some compelling motivation to do so...

Admittedly, I'm not much of a contributor; and this is probably part of
the reason why... But then, even if it's a smaller barrier for other
potential contributors, it's still a barrier. (And barriers add up.)

We need to work on lowering barriers as much as possible, rather than
trying to argue them away. The former does actually help, while the
latter is pointless exercise.

This "we are interested in master developers" attitude is just bullshit.
*Every* interested person is immensly important in building momentum;
even if it's only by showing presence on IRC, or by writing a blog post
about an interesting translator that was so easy to run...

> On Mon, Sep 07, 2009 at 11:00:40PM +0300, Sergiu Ivanov wrote:

> I still have to see a compelling argument why *all* Hurd code should
> be made part of the big existing Hurd code conglomerate.

It's been like that up till now; so it's actually *you* who needs to
show a compelling argument why it should be changed... :-)

Of course that doesn't mean that I have no compelling arguments... But
we have been discussing this in another thread, which I still need to
follow up on.

> > 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.

This is not a good approach IHMO. Leaving cleanups for later never
works. By the time we decide to "promote" the code, the person might
simply not be available anymore, or reluctant to do the cleanups... It
considerably lowers the chance of code ever actually going mainstream.

This is why I decided to require reviews for all patches this year:
having just a few patches that are ready for upstream inclusion is more
valuable than having a heap of code that will never make it upstream.

(Of course I didn't expect that I will be so bad at reviewing the
patches in a timely manner :-( )

-antrik-