Re: Source repositories, unionmount code

[Thomas Schwinge]

Hello!

On Sat, Oct 24, 2009 at 07:56:30AM +0200, olafBuddenhagen@gmx.net wrote:
> 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?...

Well, why not?  Also, this is suggested on
<http://sources.redhat.com/glibc/wiki/GlibcGit>, ``Branch Name Space
Conventions'' (proposed by Roland if I recall correctly) -- though not
used a lot in the glibc repository.  If you have information what other
project are doing, then please tell.


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

As I said before: ``nsmux is buildable these days simply by: configure &&
make''.

> 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

I don't intend to accept any patches (as I see no compelling advantage to
do so) for integrating it into the Hurd proper's build system.

> -- so I have been postponing my testing until it's done...

Sorry Olaf, but don't you rather want to try to be a bit more open-minded
towards this changed building situation, instead of maintaining that
digging-in-your-heels attitude?  What's the benefit?


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

Then I say that you're simply not too much interested in the package you
decided not to compile.


> Admittedly, I'm not much of a contributor; and this is probably part of
> the reason why...

Actually, you're much of a contributor!  Let me thank you again for the
marvelous mentoring work you've been doing for the GSoCs!  Really!


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

While that is true in general, we simply don't have the resources to give
a helping hand to every potential new contributor -- simply because all
our time is limited.  All this would work out if people were helping
themselves, but what we see in most cases is that it is you, Samuel, me,
plus a few others who are answering beginners' (installation) questions
on the mailing lists.  That's also the reason why the help-hurd list is
mostly dead, which I understand to be the list where GNUbies help other
GNUbies -- which just doesn't happen too much.

Lowering barriers for playing with Hurd features certainly is the right
thing to do, but what we can't relieve others of is showing a certain
amount of persistence and self-interest.


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

Perhaps it boils down to this: I simply made a decision.  You may like it
or not.  You may be able to talk me into doing it another way; that may
be easier with some real arguments; or it may not be possible.

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

Again, this is of course true in general, but didn't we also say that
it'd be fine for software packages that are newly created, that all the
various debugging-helping commits / printfs / etc. are simply taken out
once the package is supposed to be made available to the general public,
and that all development commits are then compressed into one big ``here
I am'' commit?


Regards,
 Thomas

signature.asc
Description: Digital signature