Re: Source repositories, unionmount code

[Sergiu Ivanov]

Hello,

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

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

Hm, I guess I have the habit of thinking about it in the wrong way: it
has never occurred to me that I'm a Hurd *contributor* :-)

Anyway, I've created the master-unionmount branch in the unionfs git
repository.
 
> 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.

That's interesting, I have never heard of this convention.  It sounds
pretty nice and I think I'll follow it when appropriate.  Thank you
for the suggestion :-)
 
> 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).
 
Yeah, that's right: after some definite moments I could only keep
track of the latest versions of the patches by looking into my local
repository.  I'll keep this strategy in mind and will try to use it
when appropriate.
 
> 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:
> 
> > 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.

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

That's a pretty constructive position :-) My problem was (I hope it is
not any more) that I treated Savannah as exhibition site for results,
not progress.  However, if intermediate stuff may also be kept there
(in personal branches), I will use the Savannah repositories.
 
> On Mon, Sep 07, 2009 at 11:00:40PM +0300, Sergiu Ivanov wrote:
>
> > 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?

This is clear.  Squashing down the history is a good thing for me,
because there are many marks of my former execrable git knowledge in
it:-)
 
> 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.)
 
I think I can understand this argument pretty well.
 
> > 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.

I think I'll try to move nsmux further in my spare time when my head
is working and will do cleanups when I'll be tired.  I don't usually
code seriously when I'm really tired, because I often have to undo
things afterwards, so cleanups shouldn't be chipping off valuable
time.
 
> > 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.

Does this mean that a special repository will be created for nsmux on
Savannah?

Regards,
scolobb