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, olafbuddenha...@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, olafbuddenha...@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, olafbuddenha...@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
