Re: Time to flush developer accumulated patches?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux