Time to flush developer accumulated patches?

Time to flush developer accumulated patches?

[Marco Costalba]

Reading mailing list threads it is becoming common these days to hear
about contributors with patches ready to be sent as soon as 1.5.4 is
out.

Would be a good idea to open a new branch new_stuff as a target for
this pending stuff?

I understand that you want people focused on fixing bugs, but I also
understand that people don't ;-)

Opening a new_stuff branch could have the following benefits:

- Give more time to fix bugs before 1.5.4 is out without stopping
people from having fun and reduce the pressure to release.

- Reduce the merging impact when master reopens because patches are
already merged in new_stuff and developers have already taken care of
conflicts

- Do not slow down the wheel: I can develop some patches and keep them
myself, but until are not discussed in the list and eventually got in
master has little meaning to continue develop additional stuff.

- Perhaps it's lack of reviewing time on your side that worries you
(as is normal because we are on bug fixes mode in master) but upgrade
from new_stuff to master would be not automatic nor guaranteed but at
least people have an idea at what's going on and can keep contributing
in code and ideas.


Comments?


Marco

Re: Time to flush developer accumulated patches?

[Wincent Colaiuta]

El 20/1/2008, a las 11:10, Marco Costalba escribió:

> Reading mailing list threads it is becoming common these days to hear
> about contributors with patches ready to be sent as soon as 1.5.4 is
> out.
>
> Would be a good idea to open a new branch new_stuff as a target for
> this pending stuff?
>
> I understand that you want people focused on fixing bugs, but I also
> understand that people don't ;-)
>
> Opening a new_stuff branch could have the following benefits:
>
> - Give more time to fix bugs before 1.5.4 is out without stopping
> people from having fun and reduce the pressure to release.
>
> - Reduce the merging impact when master reopens because patches are
> already merged in new_stuff and developers have already taken care of
> conflicts
>
> - Do not slow down the wheel: I can develop some patches and keep them
> myself, but until are not discussed in the list and eventually got in
> master has little meaning to continue develop additional stuff.
>
> - Perhaps it's lack of reviewing time on your side that worries you
> (as is normal because we are on bug fixes mode in master) but upgrade
> from new_stuff to master would be not automatic nor guaranteed but at
> least people have an idea at what's going on and can keep contributing
> in code and ideas.

We already have two such branches: next and pu.

Here's an old version of a mail from Junio describing the different  
branches; I know he's sent out newer ones but this it he one that I  
could lay my hands on:

http://article.gmane.org/gmane.comp.version-control.git/39954

Cheers,
Wincent

Re: Time to flush developer accumulated patches?

[Marco Costalba]

On Jan 20, 2008 11:18 AM, Wincent Colaiuta <win@wincent.com> wrote:
>
> We already have two such branches: next and pu.
>

Yes of course, the name of the branch is not the point here, I
purposely choose an unrealistic name 'new_stuff' to underline this,
sorry if it was not clear.

Re: Time to flush developer accumulated patches?

[Steffen Prohaska]

On Jan 20, 2008, at 11:10 AM, Marco Costalba wrote:

> Reading mailing list threads it is becoming common these days to hear
> about contributors with patches ready to be sent as soon as 1.5.4 is
> out.
>
> Would be a good idea to open a new branch new_stuff as a target for
> this pending stuff?

I don't think this is a good idea ...


> I understand that you want people focused on fixing bugs, but I also
> understand that people don't ;-)
>
> Opening a new_stuff branch could have the following benefits:
>
> - Give more time to fix bugs before 1.5.4 is out without stopping
> people from having fun and reduce the pressure to release.

... because I believe it is a good thing to keep the pressure
to release.  The 1.5.4 cycle already became quite long.


> - Reduce the merging impact when master reopens because patches are
> already merged in new_stuff and developers have already taken care of
> conflicts
>
> - Do not slow down the wheel: I can develop some patches and keep them
> myself, but until are not discussed in the list and eventually got in
> master has little meaning to continue develop additional stuff.

Isn't this the idea: slow down a bit, focus on fixing bugs instead
of developing new stuff, and release 1.5.4.


> - Perhaps it's lack of reviewing time on your side that worries you
> (as is normal because we are on bug fixes mode in master) but upgrade
> from new_stuff to master would be not automatic nor guaranteed but at
> least people have an idea at what's going on and can keep contributing
> in code and ideas.

Isn't this the purpose of pu?

	Steffen

Re: Time to flush developer accumulated patches?

[Johannes Schindelin]

Hi,

On Sun, 20 Jan 2008, Marco Costalba wrote:

> Reading mailing list threads it is becoming common these days to hear 
> about contributors with patches ready to be sent as soon as 1.5.4 is 
> out.

Which is good.

> Would be a good idea to open a new branch new_stuff as a target for this 
> pending stuff?

No.  The purpose of the rc cycle is to _stabilise_ things, which means 
that people should _focus_ on stabilising things.

If you give them enough to play with, they just get sidetracked, and the 
stabilisation is left to... Junio.  Which is not only hard on our good 
maintainer, but outright mean.

Ciao,
Dscho

Re: Time to flush developer accumulated patches?

[Junio C Hamano]

"Marco Costalba" <mcostalba@gmail.com> writes:

> I understand that you want people focused on fixing bugs, but I also
> understand that people don't ;-)

Current policy during rc stabilization period is roughly:

 - No new feature is accepted, starting early in the rc cycle;

 - An intrusive fix is sent back and requested to be rewritten
   as minimum "fix" without enhancements, starting mid rc cycle;

 - I do not want to take patches early.

The third point is a double-edged sword:

 - Developers can easily get distracted when encouraged to do
   new things.  That's human nature.  Everybody finds doing new
   things more interesting than finding and fixing existing
   bugs.

   This is especially true if the fix is about somebody else's
   code and the breakage does not affect you.  Even your own
   earlier half-baked-hack that has not been discovered by other
   people is often not interesting to fix (once discovered, the
   embarrassment factor tends to make it a higher priority).

   However, we won't have enough good people who know the
   codebase and are capable of fixing existing bugs if they all
   go and work on "other" things.

 - Developers tend to notice _existing_ breakage more easily
   when given a chance to play with _existing_ code (either
   enhancing the existing code, or adding new call sites to the
   existing API).  And one way to encourage playing with
   _existing_ code is to to encourage developing on top of it.

In earlier releases, I used to keep 'next' open during the
freeze.  I think it had the effect of encouraging new things too
much without having enough side-effect (from the point of view
of a person who wants to do new things) of uncovering and fixing
existing issues (which is the primarily desired effect during
the stabilization).

This time I have been deliberately playing differently to strike
the balance a bit differently:
 
 - In order to discourage new things, I do not accept patches
   early.

 - In order not to discourage new things too much, I try to give
   brief feedback, and add them to "What's not in 'master', and
   likely not to be until 1.5.4".

Another practical reason I do not take patches early is because
it is a time drain.  Taking patches early means it will increase
the merge impact _before_ 1.5.4.

Now that high level description out of the way, let's see what
you said:

    - Give more time to fix bugs before 1.5.4 is out without stopping
    people from having fun and reduce the pressure to release.

That is precisely what I want to discourage.

    - Reduce the merging impact when master reopens because patches are
    already merged in new_stuff and developers have already taken care of
    conflicts

Bogus.

When two or more new things are outstanding, and if I take
patches early, 'next' needs merge resolution.  You are arguing
to take my time away from what matters to 1.5.4 during the
stabilization period, and instead encourage people to have fun
and get distracted.

Post 1.5.4 if one series contradicts/conflicts with another, I
can just say "I have decided to take that series and your series
conflicts with it.  Please rebase", to shift the burden to the
contributor of the second series.  If I do that before 1.5.4,
that means I will not just encourage but actively ask the second
contributor not to work on uncovering and fixing existing issues
but spend time on new things.

Do you think that helps the stabilization period in _any_ way?

    - Do not slow down the wheel: I can develop some patches and keep them
    myself, but until are not discussed in the list and eventually got in
    master has little meaning to continue develop additional stuff.

That's exactly the point of stabilization freeze.  You can
develop and keep developing.  I have a few topics myself that
are backburnered, and I occasionally visit them when I am bored.
However, I try not to distract others with the series.  Please
try to do the same.

Time to flush Mr. Hammano?

[Quim K Holland]

"Marco Costalba" <mcostalba@gmail.com> wrote:

 Reading mailing list threads it is becoming common these days to hear
 about contributors with patches ready to be sent as soon as 1.5.4 is
 out.

 Would be a good idea to open a new branch new_stuff as a target for
 this pending stuff?

Back when Mr. Torvalds was still leading the development there was not this stupid stability freeze and many useful patches were accepted every day.  For the past few months Mr. Hammano has not been adding much useful code himself, did not join interesting discussions such as Unicode normalization issues, nor gave much useful comments on patches. He has mostly been busy rejecting useful patches and sending not so useful comments.

Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the project leader?  I do not mean any disrespect to Mr. Hammano, but don't people think he outlived his usefulness as the project leader?

Re: Time to flush Mr. Hammano?

[David Kastrup]

Quim K Holland <qkholland@gmail.com> writes:

> "Marco Costalba" <mcostalba@gmail.com> wrote:
>
>>  Reading mailing list threads it is becoming common these days to hear
>> about contributors with patches ready to be sent as soon as 1.5.4 is
>> out.
>
>>  Would be a good idea to open a new branch new_stuff as a target for
>> this pending stuff?
>
> Back when Mr. Torvalds was still leading the development there was not
> this stupid stability freeze and many useful patches were accepted
> every day.  For the past few months Mr. Hammano has not been adding
> much useful code himself, did not join interesting discussions such as
> Unicode normalization issues, nor gave much useful comments on
> patches. He has mostly been busy rejecting useful patches and sending
> not so useful comments.
>
> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the
> project leader?  I do not mean any disrespect to Mr. Hammano, but
> don't people think he outlived his usefulness as the project leader?

As far as I count as "people", I'd say you are plain nuts.  And it is
not like I remember any useful contribution of yours, anyhow.

In my opinion, JH is doing a splendid job.  You don't seem to have
watched it too closely, though.  You are not even able to spell his
name, and you obviously have no clue about the state of affairs anyway.
If you think you can do a better job, feel free to do so: since git is
developed using distributed version control, everybody can make his own
forks and still continue sharing code and patches.  We have this
situation with the Linux kernel (where we have Linus kernels, Morton
kernels, Molnar kernels and so on), all quite amicably.

A similar branching out is not really visible for git itself (apart from
the msys-git branch which is slated for eventual reintegration), and
that's exactly because Junio's work leaves so very little to be desired.

-- 
David Kastrup

Re: Time to flush Mr. Hammano?

[Junio C Hamano]

Please stop feeding a troll already.

Re: Time to flush Mr. Hammano?

[Imran M Yousuf]

On Jan 21, 2008 5:36 PM, David Kastrup <dak@gnu.org> wrote:
> Quim K Holland <qkholland@gmail.com> writes:
>
> > "Marco Costalba" <mcostalba@gmail.com> wrote:
> >
> >>  Reading mailing list threads it is becoming common these days to hear
> >> about contributors with patches ready to be sent as soon as 1.5.4 is
> >> out.
> >
> >>  Would be a good idea to open a new branch new_stuff as a target for
> >> this pending stuff?
> >
> > Back when Mr. Torvalds was still leading the development there was not
> > this stupid stability freeze and many useful patches were accepted
> > every day.  For the past few months Mr. Hammano has not been adding
> > much useful code himself, did not join interesting discussions such as
> > Unicode normalization issues, nor gave much useful comments on
> > patches. He has mostly been busy rejecting useful patches and sending
> > not so useful comments.

I can personally give witness to Junio Hamano's discussion and
extremely detailed discussion on patches I sent out and it is more
elaborate than I would have given in reply. If he has not replied to
any of your patch that is because he probably missed it, a resend or a
reminder wont harm; we should all understand the workload involved
with a successful project as git.

> >
> > Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the
> > project leader?  I do not mean any disrespect to Mr. Hammano, but
> > don't people think he outlived his usefulness as the project leader?
>

At least get the name right next time. I hope Linus does not read it,
because I cant imagine what he would reply :).

> As far as I count as "people", I'd say you are plain nuts.  And it is
> not like I remember any useful contribution of yours, anyhow.
>
> In my opinion, JH is doing a splendid job.  You don't seem to have
> watched it too closely, though.  You are not even able to spell his
> name, and you obviously have no clue about the state of affairs anyway.
> If you think you can do a better job, feel free to do so: since git is
> developed using distributed version control, everybody can make his own
> forks and still continue sharing code and patches.  We have this
> situation with the Linux kernel (where we have Linus kernels, Morton
> kernels, Molnar kernels and so on), all quite amicably.

I tend to agree with David, it is very easy and convenient to
criticise someone despite his brilliant work. if one feels that a
patch will be extremely helpful for one, he/she can easily take and
integrate it with his/her own codebase install it and use it, in fact
thats what I do as I have two installations of git.

>
> A similar branching out is not really visible for git itself (apart from
> the msys-git branch which is slated for eventual reintegration), and
> that's exactly because Junio's work leaves so very little to be desired.
>
> --
> David Kastrup
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Imran M Yousuf

Re: Time to flush Mr. Hammano?

[Paolo Ciarrocchi]

On Jan 21, 2008 12:15 PM, Quim K Holland <qkholland@gmail.com> wrote:
> "Marco Costalba" <mcostalba@gmail.com> wrote:
>
>  Reading mailing list threads it is becoming common these days to hear
>  about contributors with patches ready to be sent as soon as 1.5.4 is
>  out.
>
>  Would be a good idea to open a new branch new_stuff as a target for
>  this pending stuff?
>
> Back when Mr. Torvalds was still leading the development there was not this stupid stability freeze and many useful patches were accepted every day.  For the past few months Mr. Hammano has not been adding much useful code himself, did not join interesting discussions such as Unicode normalization issues, nor gave much useful comments on patches. He has mostly been busy rejecting useful patches and sending not so useful comments.
>
> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the project leader?  I do not mean any disrespect to Mr. Hammano, but don't people think he outlived his usefulness as the project leader?

I'm strongly against your proposal, I think Junio is doing a _great_ work.


Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Re: Time to flush Mr. Hammano?

[Juanma Barranquero]

On Jan 21, 2008 12:15 PM, Quim K Holland <qkholland@gmail.com> wrote:

"stupid stability freeze", "not been adding much useful code himself",
"not join interesting discussions", "nor gave much useful comments on
patches",  "mostly been busy rejecting useful patches and sending not
so useful comments"

> I do not mean any disrespect to Mr. Hammano

You sure have a funny way to do so. If you do show disrespect someday
I hope I'll be around to see it...

             Juanma

Re: Time to flush Mr. Hammano?

[Johannes Schindelin]

Hi,

On Mon, 21 Jan 2008, Quim K Holland wrote:

> Back when Mr. Torvalds was still leading the development there was not 
> this stupid stability freeze and many useful patches were accepted every 
> day.  For the past few months Mr. Hammano has not been adding much 
> useful code himself, did not join interesting discussions such as 
> Unicode normalization issues, nor gave much useful comments on patches. 
> He has mostly been busy rejecting useful patches and sending not so 
> useful comments.
> 
> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the 
> project leader?  I do not mean any disrespect to Mr. Hammano, but don't 
> people think he outlived his usefulness as the project leader?

$ git log --all --author=Quim|wc
      0       0       0

Can I vote you off this list?

I would call you "idiot" if that did not hurt _my_ karma,
Dscho

Re: Time to flush Mr. Hammano?

[Rogan Dawes]

Quim K Holland wrote:
> "Marco Costalba" <mcostalba@gmail.com> wrote:
> 
> Reading mailing list threads it is becoming common these days to hear
>  about contributors with patches ready to be sent as soon as 1.5.4 is
>  out.
> 
> Would be a good idea to open a new branch new_stuff as a target for 
> this pending stuff?
> 
> Back when Mr. Torvalds was still leading the development there was
> not this stupid stability freeze and many useful patches were
> accepted every day.  For the past few months Mr. Hammano has not been
> adding much useful code himself, did not join interesting discussions
> such as Unicode normalization issues, nor gave much useful comments
> on patches. He has mostly been busy rejecting useful patches and
> sending not so useful comments.
> 
> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the
> project leader?  I do not mean any disrespect to Mr. Hammano, but
> don't people think he outlived his usefulness as the project leader?

That's Mr Hamano (one 'm'), and personally, I think that only when you 
have contributed to this project yourself, would you have a leg to stand 
on when you criticise him.

As an observer, I think that Junio is doing a superb job of managing the 
sometimes quite torrential flow of patches contributed to git. As Linus 
himself has often said (Paraphrased, of course):

The role of the maintainer is often more to *reject* patches than to 
accept them, so as to maintain the quality of the code base.

Having said that, the amount of *constructive* criticism that 
accompanies those rejections is amazing. Often I have seen multiple 
pages of response to a 2 line patch, so that the contributor (and other 
observers) can better understand the reason for the rejection, and how 
to construct a better patch that would be accepted.

Regards,

Rogan

Re: Time to flush Mr. Hammano?

[David Tweed]

One other point no-one has mentioned: even if Junio were to be doing
more stabilisation than normal in a project (and I don't think he is),
version control software is one of those things like a filesystem
where paying attention to stability is really important. Unlike a
buggy music player (say), a buggy git could destroy everything up to
your last backup.

I appreciate all the work everyone in the community is currently doing
on stabilisation.

-- 
cheers, dave tweed__________________________
david.tweed@gmail.com
Rm 124, School of Systems Engineering, University of Reading.
"we had no idea that when we added templates we were adding a Turing-
complete compile-time language." -- C++ standardisation committee

Re: Time to flush Mr. Hammano?

[Marco Costalba]

On Jan 21, 2008 12:15 PM, Quim K Holland <qkholland@gmail.com> wrote:
> "Marco Costalba" <mcostalba@gmail.com> wrote:
>

......cut a load of sh...t

> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the project leader?  I do not mean any disrespect to Mr. Hammano, but don't people think he outlived his usefulness as the project leader?
> -

I'm really sorry you used my argumentations and trasform them in a
full load of bullshi..t.

If I had only imagined somthing like this I would never posted in first place.

The man you can't even write his name correctly is one of the best
maintainers we can have. And we' ve been very lucky for this.

I can number a lot of reasons for this, but you really don't deserve it.

It's not a problem of how many patches you have posted, IMHO everyone
could express his ideas regardless of the weight of his contribute to
git.

But, also if you had posted thousand patches this don't give you the
right to speak like this.

Marco

Re: Time to flush Mr. Hammano?

[Jakub Narebski]

Quim K Holland <qkholland@gmail.com> writes:

> Back when Mr. Torvalds was still leading the development there was
> not this stupid stability freeze and many useful patches were
> accepted every day.  For the past few months Mr. Hammano has not
> been adding much useful code himself, did not join interesting
> discussions such as Unicode normalization issues, nor gave much
> useful comments on patches. He has mostly been busy rejecting useful
> patches and sending not so useful comments.
> 
> Can we vote Mr. Hammano out and ask Mr. Torvalds to come back as the
> project leader?  I do not mean any disrespect to Mr. Hammano, but
> don't people think he outlived his usefulness as the project leader?

First, Linus Torvalds passed maintaining git to Junio C Hamano because
he wanted to concentrate on Linux kernel; distributed version control
tool is just the means to do that.  I don't think Linus would want to
be back to maintaining git: it is a hard work.

Second, development and development speeds differ from the "creating"
pre-1.0 stage (for git when it was being written and then maintained
by Linus), and the mature development / improvement stage (for git
being maintained by Junio).

Third, git is now in feature freeze before main release, so it is
better that Junio concentrates on fixing bugs than on longish
discussions or new features.


Last, you don't follow netiquette: you don't know how to cite / quote
properly, you didn't word-wrap what you have wrote, you don't
contribute neither to discussion nor git code.

Have a nice life... in killfile!

-- 
Jakub Narebski
Poland
ShadeHawk on #git