[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

From: David Brownell <dbrownell@users.sourceforge.net>

Start updating DaVinci board support to reduce dependencies on
dm644x chips and EVM-like boards ... beginning with "psc.c",
which hosts a bunch of those dependencies:

 - Pinmux registers and their contents are SoC-specific, and
   are also unrelated to the Power and Sleep Controller.
   
     * Declare more of the pinmux registers;
     * Move their bitfield decls to a public header;
     * Renaming thse bitfields to be clearly SoC-specific.

 - Rename the errata workarounds to be clearly SoC-specific.

 - Add a CONFIG_SOC_DM6446; use it to prevent some mux goofs.

 - Don't include the I2C support if the I2C driver is not enabled.

Plus two minor bugfixes:

 - Correct the PSC_MDSTAT mask ...  it's six bits, not five.
   (Original DM6446 doces said five, FWIW.)

 - Correct the PWREMU_MGT mask ... don't set must-be-zero bits.

The simplest always-correct way to handle pinmux is in board_init()
calls; or possibly in SoC-specific device setup code.  Currently
these chips don't have such SoC-specific support.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
---
 board/davinci/common/psc.c              |   29 ++++++++++++++++-------------
 board/davinci/common/psc.h              |    2 +-
 board/davinci/dvevm/dvevm.c             |    2 +-
 board/davinci/schmoogie/schmoogie.c     |    2 +-
 board/davinci/sffsdr/sffsdr.c           |    2 +-
 board/davinci/sonata/sonata.c           |    2 +-
 include/asm-arm/arch-davinci/hardware.h |   23 +++++++++++++++++++++--
 include/configs/davinci_dvevm.h         |    1 +
 include/configs/davinci_schmoogie.h     |    1 +
 include/configs/davinci_sffsdr.h        |    1 +
 include/configs/davinci_sonata.h        |    1 +
 11 files changed, 46 insertions(+), 20 deletions(-)

--- a/board/davinci/common/psc.c
+++ b/board/davinci/common/psc.c
@@ -26,13 +26,6 @@
 #include <common.h>
 #include <asm/arch/hardware.h>
 
-#define PINMUX0_EMACEN (1 << 31)
-#define PINMUX0_AECS5  (1 << 11)
-#define PINMUX0_AECS4  (1 << 10)
-
-#define PINMUX1_I2C    (1 <<  7)
-#define PINMUX1_UART1  (1 <<  1)
-#define PINMUX1_UART0  (1 <<  0)
 
 /*
  * The DM6446 includes two separate power domains: "Always On" and "DSP". The
@@ -57,7 +50,7 @@ void lpsc_on(unsigned int id)
 
 	while (REG(PSC_PTSTAT) & 0x01);
 
-	if ((*mdstat & 0x1f) == 0x03)
+	if ((*mdstat & 0x3f) == 0x03)
 		return;			/* Already on and enabled */
 
 	*mdctl |= 0x03;
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
 	lpsc_on(DAVINCI_LPSC_UART0);
 
 	/* Bringup UART0 out of reset */
-	REG(UART0_PWREMU_MGMT) = 0x0000e003;
+	REG(UART0_PWREMU_MGMT) = 0x00006001;
 
+#ifdef CONFIG_SOC_DM6446
 	/* Enable UART0 MUX lines */
-	REG(PINMUX1) |= PINMUX1_UART0;
+	REG(PINMUX1) |= DM644X_PINMUX1_UART0;
+#endif
 }
 
 #ifdef CONFIG_DRIVER_TI_EMAC
@@ -145,20 +140,27 @@ void davinci_enable_emac(void)
 	/* Enable GIO3.3V cells used for EMAC */
 	REG(VDD3P3V_PWDN) = 0;
 
+#ifdef CONFIG_SOC_DM6446
 	/* Enable EMAC. */
-	REG(PINMUX0) |= PINMUX0_EMACEN;
+	REG(PINMUX0) |= DM644X_PINMUX0_EMACEN;
+#endif
 }
 #endif
 
+#ifdef CONFIG_DRIVER_DAVINCI_I2C
 void davinci_enable_i2c(void)
 {
 	lpsc_on(DAVINCI_LPSC_I2C);
 
+#ifdef CONFIG_SOC_DM6446
 	/* Enable I2C pin Mux */
-	REG(PINMUX1) |= PINMUX1_I2C;
+	REG(PINMUX1) |= DM644X_PINMUX1_I2C;
+#endif
 }
+#endif
 
-void davinci_errata_workarounds(void)
+#ifdef CONFIG_SOC_DM6446
+void dm6446_errata_workarounds(void)
 {
 	/*
 	 * Workaround for TMS320DM6446 errata 1.3.22:
@@ -180,3 +182,4 @@ void davinci_errata_workarounds(void)
 	 */
 	REG(VBPR) = 0x20;
 }
+#endif
--- a/board/davinci/common/psc.h
+++ b/board/davinci/common/psc.h
@@ -27,6 +27,6 @@ void dsp_on(void);
 void davinci_enable_uart0(void);
 void davinci_enable_emac(void);
 void davinci_enable_i2c(void);
-void davinci_errata_workarounds(void);
+void dm6446_errata_workarounds(void);
 
 #endif /* __PSC_H */
--- a/board/davinci/dvevm/dvevm.c
+++ b/board/davinci/dvevm/dvevm.c
@@ -44,7 +44,7 @@ int board_init(void)
 	 * with pull-up/pull-down resistors) */
 	REG(PINMUX0) = 0x00000c1f;
 
-	davinci_errata_workarounds();
+	dm6446_errata_workarounds();
 
 	/* Power on required peripherals */
 	lpsc_on(DAVINCI_LPSC_GPIO);
--- a/board/davinci/schmoogie/schmoogie.c
+++ b/board/davinci/schmoogie/schmoogie.c
@@ -44,7 +44,7 @@ int board_init(void)
 	 * with pull-up/pull-down resistors) */
 	REG(PINMUX0) = 0x00000c1f;
 
-	davinci_errata_workarounds();
+	dm6446_errata_workarounds();
 
 	/* Power on required peripherals */
 	lpsc_on(DAVINCI_LPSC_GPIO);
--- a/board/davinci/sffsdr/sffsdr.c
+++ b/board/davinci/sffsdr/sffsdr.c
@@ -50,7 +50,7 @@ int board_init(void)
 	/* address of boot parameters */
 	gd->bd->bi_boot_params = LINUX_BOOT_PARAM_ADDR;
 
-	davinci_errata_workarounds();
+	dm6446_errata_workarounds();
 
 	/* Power on required peripherals */
 	lpsc_on(DAVINCI_LPSC_GPIO);
--- a/board/davinci/sonata/sonata.c
+++ b/board/davinci/sonata/sonata.c
@@ -43,7 +43,7 @@ int board_init(void)
 	 * with pull-up/pull-down resistors) */
 	REG(PINMUX0) = 0x00000c1f;
 
-	davinci_errata_workarounds();
+	dm6446_errata_workarounds();
 
 	/* Power on required peripherals */
 	lpsc_on(DAVINCI_LPSC_GPIO);
--- a/include/asm-arm/arch-davinci/hardware.h
+++ b/include/asm-arm/arch-davinci/hardware.h
@@ -44,6 +44,10 @@ typedef volatile unsigned int *	dv_reg_p
 
 /*
  * Base register addresses
+ *
+ * NOTE:  some of these DM6446-specific addresses DO NOT WORK
+ * on other DaVinci chips.  Double check them before you try
+ * using the addresses ... or PSC module identifiers, etc.
  */
 #define DAVINCI_DMA_3PCC_BASE			(0x01c00000)
 #define DAVINCI_DMA_3PTC0_BASE			(0x01c10000)
@@ -160,7 +164,22 @@ typedef volatile unsigned int *	dv_reg_p
 
 /* Miscellania... */
 #define VBPR				(0x20000020)
-#define PINMUX0				(0x01c40000)
-#define PINMUX1				(0x01c40004)
+
+/* NOTE:  system control modules are *highly* chip-specific, both
+ * as to register content (e.g. for muxing) and which registers exist.
+ */
+#define PINMUX0				0x01c40000
+#define DM644X_PINMUX0_EMACEN (1 << 31)
+#define DM644X_PINMUX0_AECS5  (1 << 11)
+#define DM644X_PINMUX0_AECS4  (1 << 10)
+
+#define PINMUX1				0x01c40004
+#define DM644X_PINMUX1_I2C    (1 <<  7)
+#define DM644X_PINMUX1_UART1  (1 <<  1)
+#define DM644X_PINMUX1_UART0  (1 <<  0)
+
+#define PINMUX2				0x01c40008
+#define PINMUX3				0x01c4000c
+#define PINMUX4				0x01c40010
 
 #endif /* __ASM_ARCH_HARDWARE_H */
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -59,6 +59,7 @@
 #define CONFIG_SYS_TIMERBASE		0x01c21400	/* use timer 0 */
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
+#define CONFIG_SOC_DM6446
 /*====================================================*/
 /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */
 /* on Sonata/DV_EVM board. No EEPROM on schmoogie.    */
--- a/include/configs/davinci_schmoogie.h
+++ b/include/configs/davinci_schmoogie.h
@@ -34,6 +34,7 @@
 #define CONFIG_SYS_TIMERBASE		0x01c21400	/* use timer 0 */
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
+#define CONFIG_SOC_DM6446
 /*=============*/
 /* Memory Info */
 /*=============*/
--- a/include/configs/davinci_sffsdr.h
+++ b/include/configs/davinci_sffsdr.h
@@ -35,6 +35,7 @@
 #define CONFIG_SYS_TIMERBASE		0x01c21400	/* use timer 0 */
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
+#define CONFIG_SOC_DM6446
 /* EEPROM definitions for Atmel 24LC64 EEPROM chip */
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN		2
 #define CONFIG_SYS_I2C_EEPROM_ADDR		0x50
--- a/include/configs/davinci_sonata.h
+++ b/include/configs/davinci_sonata.h
@@ -59,6 +59,7 @@
 #define CONFIG_SYS_TIMERBASE		0x01c21400	/* use timer 0 */
 #define CONFIG_SYS_HZ_CLOCK		27000000	/* Timer Input clock freq */
 #define CONFIG_SYS_HZ			1000
+#define CONFIG_SOC_DM6446
 /*====================================================*/
 /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */
 /* on Sonata/DV_EVM board. No EEPROM on schmoogie.    */

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:44 Sun 12 Apr     , David Brownell wrote:
> From: David Brownell <dbrownell@users.sourceforge.net>
> 
> Start updating DaVinci board support to reduce dependencies on
> dm644x chips and EVM-like boards ... beginning with "psc.c",
> which hosts a bunch of those dependencies:
> 
>  - Pinmux registers and their contents are SoC-specific, and
>    are also unrelated to the Power and Sleep Controller.
>    
>      * Declare more of the pinmux registers;
>      * Move their bitfield decls to a public header;
>      * Renaming thse bitfields to be clearly SoC-specific.
> 
>  - Rename the errata workarounds to be clearly SoC-specific.
> 
>  - Add a CONFIG_SOC_DM6446; use it to prevent some mux goofs.
> 
>  - Don't include the I2C support if the I2C driver is not enabled.
> 
> Plus two minor bugfixes:
> 
>  - Correct the PSC_MDSTAT mask ...  it's six bits, not five.
>    (Original DM6446 doces said five, FWIW.)
> 
>  - Correct the PWREMU_MGT mask ... don't set must-be-zero bits.
> 
> The simplest always-correct way to handle pinmux is in board_init()
> calls; or possibly in SoC-specific device setup code.  Currently
> these chips don't have such SoC-specific support.
could you split it in more logical change please
> 
> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> ---
>  board/davinci/common/psc.c              |   29 ++++++++++++++++-------------
>  board/davinci/common/psc.h              |    2 +-
>  board/davinci/dvevm/dvevm.c             |    2 +-
>  board/davinci/schmoogie/schmoogie.c     |    2 +-
>  board/davinci/sffsdr/sffsdr.c           |    2 +-
>  board/davinci/sonata/sonata.c           |    2 +-
>  include/asm-arm/arch-davinci/hardware.h |   23 +++++++++++++++++++++--
>  include/configs/davinci_dvevm.h         |    1 +
>  include/configs/davinci_schmoogie.h     |    1 +
>  include/configs/davinci_sffsdr.h        |    1 +
>  include/configs/davinci_sonata.h        |    1 +
>  11 files changed, 46 insertions(+), 20 deletions(-)
> 
> --- a/board/davinci/common/psc.c
> +++ b/board/davinci/common/psc.c
> @@ -26,13 +26,6 @@
>  #include <common.h>
>  #include <asm/arch/hardware.h>
>  
> -#define PINMUX0_EMACEN (1 << 31)
> -#define PINMUX0_AECS5  (1 << 11)
> -#define PINMUX0_AECS4  (1 << 10)
> -
> -#define PINMUX1_I2C    (1 <<  7)
> -#define PINMUX1_UART1  (1 <<  1)
> -#define PINMUX1_UART0  (1 <<  0)
>  
>  /*
>   * The DM6446 includes two separate power domains: "Always On" and "DSP". The
> @@ -57,7 +50,7 @@ void lpsc_on(unsigned int id)
>  
>  	while (REG(PSC_PTSTAT) & 0x01);
>  
> -	if ((*mdstat & 0x1f) == 0x03)
> +	if ((*mdstat & 0x3f) == 0x03)
>  		return;			/* Already on and enabled */
>  
>  	*mdctl |= 0x03;
> @@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
>  	lpsc_on(DAVINCI_LPSC_UART0);
>  
>  	/* Bringup UART0 out of reset */
> -	REG(UART0_PWREMU_MGMT) = 0x0000e003;
> +	REG(UART0_PWREMU_MGMT) = 0x00006001;
>  
> +#ifdef CONFIG_SOC_DM6446
>  	/* Enable UART0 MUX lines */
> -	REG(PINMUX1) |= PINMUX1_UART0;
> +	REG(PINMUX1) |= DM644X_PINMUX1_UART0;
is this the same for all DM6446?
and the same question for the I2C and EMAC

it will be better to init pio/mux in devices file without redefined it in the
board as done for the at91

Best Regards,
J.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:44 Sun 12 Apr     , David Brownell wrote:

> could you split it in more logical change please

I'll fragment it a bit more, ok.  later.


> > @@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
> >  	lpsc_on(DAVINCI_LPSC_UART0);
> >  
> >  	/* Bringup UART0 out of reset */
> > -	REG(UART0_PWREMU_MGMT) = 0x0000e003;
> > +	REG(UART0_PWREMU_MGMT) = 0x00006001;
> >  
> > +#ifdef CONFIG_SOC_DM6446
> >  	/* Enable UART0 MUX lines */
> > -	REG(PINMUX1) |= PINMUX1_UART0;
> > +	REG(PINMUX1) |= DM644X_PINMUX1_UART0;
>
> is this the same for all DM6446?
> and the same question for the I2C and EMAC

Yes, that's why I did it that way.  PINMUX1 is part
of the DM6446 SoC itself, not an FPGA or CPLD, and
on other SoCs the bits in that register have different
meanings assigned.  UART0 might be in PINMUX4, etc.

(Or, if by "this" you meant the PWREMU_MGMT register,
that's also a yes ... plus, I looked at docs for other
DaVinci chips, and they all have the same definition
for that register.)

 
> it will be better to init pio/mux in devices file
> without redefined it in the board as done for the at91

Agreed, but there's a limit to how much rewriting I can
donate.  There *are* no dm6446-specific "devices" files
in cpu/arm926ejs/davinci yet ... and in fact, most of
that "common" code seems more like it belongs over in
cpu/.../davinci, not board/davinci/common.

(Re the AT91 code, having one file per device type and
SoC member seems absurd to me.  One per SoC seems
about right.)

My DM355 patches won't need such #ifdeffery.

- Dave



> Best Regards,
> J.
> 
> 

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:31 Thu 16 Apr     , David Brownell wrote:
> On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:44 Sun 12 Apr     , David Brownell wrote:
> 
> > could you split it in more logical change please
> 
> I'll fragment it a bit more, ok.  later.
> 
> 
> > > @@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
> > >  	lpsc_on(DAVINCI_LPSC_UART0);
> > >  
> > >  	/* Bringup UART0 out of reset */
> > > -	REG(UART0_PWREMU_MGMT) = 0x0000e003;
> > > +	REG(UART0_PWREMU_MGMT) = 0x00006001;
> > >  
> > > +#ifdef CONFIG_SOC_DM6446
> > >  	/* Enable UART0 MUX lines */
> > > -	REG(PINMUX1) |= PINMUX1_UART0;
> > > +	REG(PINMUX1) |= DM644X_PINMUX1_UART0;
> >
> > is this the same for all DM6446?
> > and the same question for the I2C and EMAC
> 
> Yes, that's why I did it that way.  PINMUX1 is part
> of the DM6446 SoC itself, not an FPGA or CPLD, and
> on other SoCs the bits in that register have different
> meanings assigned.  UART0 might be in PINMUX4, etc.
> 
> (Or, if by "this" you meant the PWREMU_MGMT register,
> that's also a yes ... plus, I looked at docs for other
> DaVinci chips, and they all have the same definition
> for that register.)
> 
>  
> > it will be better to init pio/mux in devices file
> > without redefined it in the board as done for the at91
> 
> Agreed, but there's a limit to how much rewriting I can
> donate.  There *are* no dm6446-specific "devices" files
> in cpu/arm926ejs/davinci yet ... and in fact, most of
> that "common" code seems more like it belongs over in
> cpu/.../davinci, not board/davinci/common.
yes but as it's soc specifc it's not the correct location of the code
we need to move it to cpu/.../davinci
> 
> (Re the AT91 code, having one file per device type and
> SoC member seems absurd to me.  One per SoC seems
> about right.)
If you prefer in one file is fine too

Best Regards,
J.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 17 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > > could you split it in more logical change please
> > 
> > I'll fragment it a bit more, ok. ?later.

Re-worked version coming in X parts, which also include a
patch changing the cpu/arm926ejs/davinci directory to use
the conditional build syntax you asked to see:

 1 - move psc support from board --> cpu
 2 - use conditional syntax, starting with EMAC helpers
 3 - split dm644x-specific bits out from "psc" glue
 4 - fix two dm644x buglets
 5 - add some dm355-specific bits

I'll send a dm335evm patch at some point too, likely after
some of the NAND driver updates implied.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[Hugo Villeneuve]

On Thu, 16 Apr 2009 23:31:12 -0700
David Brownell <david-b@pacbell.net> wrote:

> On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 15:44 Sun 12 Apr     , David Brownell wrote:
> 
> > could you split it in more logical change please
> 
> I'll fragment it a bit more, ok.  later.
> 
> 
> > > @@ -129,10 +122,12 @@ void davinci_enable_uart0(void)
> > >  	lpsc_on(DAVINCI_LPSC_UART0);
> > >  
> > >  	/* Bringup UART0 out of reset */
> > > -	REG(UART0_PWREMU_MGMT) = 0x0000e003;
> > > +	REG(UART0_PWREMU_MGMT) = 0x00006001;
> > >  
> > > +#ifdef CONFIG_SOC_DM6446
> > >  	/* Enable UART0 MUX lines */
> > > -	REG(PINMUX1) |= PINMUX1_UART0;
> > > +	REG(PINMUX1) |= DM644X_PINMUX1_UART0;
> >
> > is this the same for all DM6446?
> > and the same question for the I2C and EMAC
> 
> Yes, that's why I did it that way.  PINMUX1 is part
> of the DM6446 SoC itself, not an FPGA or CPLD, and
> on other SoCs the bits in that register have different
> meanings assigned.  UART0 might be in PINMUX4, etc.
> 
> (Or, if by "this" you meant the PWREMU_MGMT register,
> that's also a yes ... plus, I looked at docs for other
> DaVinci chips, and they all have the same definition
> for that register.)

Hi David,
I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x and also introducing CONFIG_SOC_DM35x, so that we don't have to add a switch statement with all the variants inside one family.

Hugo V.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 24 April 2009, Hugo Villeneuve wrote:
> I would suggest renaming (or adding) CONFIG_SOC_DM6446
> to CONFIG_SOC_DM644x

The updated patchset I sent includes CONFIG_SOC_DM644X:

  http://lists.denx.de/pipermail/u-boot/2009-April/051051.html

I decided to keep the "X" uppercase for consistency
with other CONFIG_* symbols, and Linux.

(Note: that series of five patches goes with two
patches which seem not to have merged yet:

  http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
  http://lists.denx.de/pipermail/u-boot/2009-April/050800.html

Given those, the GIT tree would be one patch away from
basic dm355 evm support.)


> and also introducing CONFIG_SOC_DM35x, 

As explained in

  http://lists.denx.de/pipermail/u-boot/2009-April/051052.html

That's not a good idea.  DM357 is *very* different,
while DM335 is just a DM355 without the MPEG/JPEG
coprocessor.  So again I decided to do exactly what
Linux is doing there:  use a DM355 conditional, and
cope with other chips in that family later, if/when
needed.
  

> so that we don't have to add a switch statement with all
> the variants inside one family.   

You mean, inside the "psc.c" code which is really
not generic PSC stuff but is really SoC-specific
device setup code?  That's why I took the approach
you see in those two patches above:  dm644x.c has
the SoC-specific bits (and dm355.c), while psc.c
keeps the generic bits.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:33 Fri 24 Apr     , David Brownell wrote:
> On Friday 24 April 2009, Hugo Villeneuve wrote:
> > I would suggest renaming (or adding) CONFIG_SOC_DM6446
> > to CONFIG_SOC_DM644x
> 
> The updated patchset I sent includes CONFIG_SOC_DM644X:
> 
>   http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
> 
> I decided to keep the "X" uppercase for consistency
> with other CONFIG_* symbols, and Linux.
Ack
> 
> (Note: that series of five patches goes with two
> patches which seem not to have merged yet:
> 
>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next

>   http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
this is throw Ben tree

Best Regards,
J.

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 24 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:33 Fri 24 Apr     , David Brownell wrote:
> > 
> > (Note: that series of five patches goes with two
> > patches which seem not to have merged yet:
> > 
> >   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
> the Patch series and this has been apply in the u-boot-arm/next

I see that branch now exists ... thanks!  :)

You can expect a basic dm355 evm board patch soonish, then.
No NAND support enabled.


Could you clarify the current merge cycle for me, by the way?
I know u-boot has switched to 2009.{01,03,05,...} releases,
which is a big win from where I sit!, with "rc" tags.

What I'm unclear on is what gets merged for 2009.05 versus
later.  Are these "next" branches for the '05 release (which
hasn't yet hit rc1)?  Or for '07 instead?


> >   http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
> this is throw Ben tree

Actually Ben just acked it ... I think he was expecting
that to go through your ARM tree, since it only affects
DaVinci chips (like dm644x, dm646x, dm365) that integrate
that 10/100 Ethernet controller.

- Dave

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[Ben Warren]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:33 Fri 24 Apr     , David Brownell wrote:
>   
>> On Friday 24 April 2009, Hugo Villeneuve wrote:
>>     
>>> I would suggest renaming (or adding) CONFIG_SOC_DM6446
>>> to CONFIG_SOC_DM644x
>>>       
>> The updated patchset I sent includes CONFIG_SOC_DM644X:
>>
>>   http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
>>
>> I decided to keep the "X" uppercase for consistency
>> with other CONFIG_* symbols, and Linux.
>>     
> Ack
>   
>> (Note: that series of five patches goes with two
>> patches which seem not to have merged yet:
>>
>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>     
> the Patch series and this has been apply in the u-boot-arm/next
>
>   
>>   http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
>>     
> this is throw Ben tree
>
>   
Actually, I asked you to pick it up:

http://lists.denx.de/pipermail/u-boot/2009-April/051076.html

If that's a problem let me know.

regards,
Ben

[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 24 April 2009, Ben Warren wrote:
> 
> >> ? http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
> >> ? ? 
> > this is throw Ben tree
> >
> > ? 
> Actually, I asked you to pick it up:
> 
> http://lists.denx.de/pipermail/u-boot/2009-April/051076.html
> 
> If that's a problem let me know.

... and in fact this discussion branch is moot, since I
now see that patch got merged into the ARM/next branch.

It's missing your (Ben's) ack though.  ;)

- Dave

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Dirk Behme]

Dear Jean-Christophe,

David Brownell wrote:
...
>>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>> the Patch series and this has been apply in the u-boot-arm/next
> 
> I see that branch now exists ... thanks!  :)
....
> Could you clarify the current merge cycle for me, by the way?
> I know u-boot has switched to 2009.{01,03,05,...} releases,
> which is a big win from where I sit!, with "rc" tags.
> 
> What I'm unclear on is what gets merged for 2009.05 versus
> later.  Are these "next" branches for the '05 release (which
> hasn't yet hit rc1)?  Or for '07 instead?

Yes, I have the same questions. I already tried to ask similar, but 
didn't get an answer.

http://lists.denx.de/pipermail/u-boot/2009-April/051111.html

Maybe my wording was a little unclear?

Dirk

Btw.: Now that -next exists, I can't find patch linked above in it, 
though :(

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Ben Warren]

Hi Dirk,

On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme <dirk.behme@googlemail.com>wrote:

> Dear Jean-Christophe,
>
> David Brownell wrote:
> ...
> >>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
> >> the Patch series and this has been apply in the u-boot-arm/next
> >
> > I see that branch now exists ... thanks!  :)
> ....
> > Could you clarify the current merge cycle for me, by the way?
> > I know u-boot has switched to 2009.{01,03,05,...} releases,
> > which is a big win from where I sit!, with "rc" tags.
> >
> > What I'm unclear on is what gets merged for 2009.05 versus
> > later.  Are these "next" branches for the '05 release (which
> > hasn't yet hit rc1)?  Or for '07 instead?
>
> Yes, I have the same questions. I already tried to ask similar, but
> didn't get an answer.
>
> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>
> Maybe my wording was a little unclear?
>
> Dirk
>
> Btw.: Now that -next exists, I can't find patch linked above in it,
> though :(
>

My approach is that once the merge window closes, new patches that are not
bug fixes go into 'next', which is for the release after the current one (in
this case 07).  When the merge window opens again, next goes to master and
the fun starts again.  I can't say for sure if this is how all branches are
handled, though.

regards,
Ben

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 24 April 2009, Dirk Behme wrote:
> Btw.: Now that -next exists, I can't find patch linked above in it, 
> though :(

  http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next

shows it ... "respects SKIP_LOWLEVEL_INIT".  Make sure
to look at the "next" branch there; you can start from

  http://git.denx.de/?p=u-boot/u-boot-arm.git

Then page to the bottom, "heads" --> next, then shortlog.
They're all there, except the dm9000 eeprom bugfix.

- Dave

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[David Brownell]

On Friday 24 April 2009, Ben Warren wrote:
> My approach is that once the merge window closes, new patches that are not
> bug fixes go into 'next', which is for the release after the current one (in
> this case 07). 

Then I'm curious how that dm9000 EEPROM reading bugfix
landed in net/next ... or is the point that the merge
window for 2009.05 is still open, since RC1 hasn't yet
been tagged?

My question on that one is how it ever happened in the
first place!  My thought was that only four boards in
the tree seem to use that driver.  The AT91sam9 board
(whichever) explicitly disables the EEPROM access, as
if maybe it were observed to be broken.  Two of the
other boards are kind of old, maybe not used much.  And
ISTR counting the fourth board as the one I was poking
at, on which the bugfix was developed.



> When the merge window opens again, next goes to master and 
> the fun starts again. ?I can't say for sure if this is how all branches are
> handled, though.

[U-Boot] U-Boot ARM merge strategy

[Dirk Behme]

Hi Ben,

Ben Warren wrote:
> Hi Dirk,
> 
> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme <dirk.behme@googlemail.com>wrote:
> 
>> Dear Jean-Christophe,
>>
>> David Brownell wrote:
>> ...
>>>>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>>> the Patch series and this has been apply in the u-boot-arm/next
>>> I see that branch now exists ... thanks!  :)
>> ....
>>> Could you clarify the current merge cycle for me, by the way?
>>> I know u-boot has switched to 2009.{01,03,05,...} releases,
>>> which is a big win from where I sit!, with "rc" tags.
>>>
>>> What I'm unclear on is what gets merged for 2009.05 versus
>>> later.  Are these "next" branches for the '05 release (which
>>> hasn't yet hit rc1)?  Or for '07 instead?
>> Yes, I have the same questions. I already tried to ask similar, but
>> didn't get an answer.
>>
>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>>
>> Maybe my wording was a little unclear?
>>
>> Dirk
>>
>> Btw.: Now that -next exists, I can't find patch linked above in it,
>> though :(
>>
> 
> My approach is that once the merge window closes, new patches that are not
> bug fixes go into 'next', which is for the release after the current one (in
> this case 07).  When the merge window opens again, next goes to master and
> the fun starts again.

Yes, this is my basic understanding, too.

But there are always these ugly details ;)

- What's about patches that remove dead code, unused macros etc. IMHO 
they can be handled like bug fixes and applied while rc?

- What's about patches that are sent while open merge window or 
before, but need some update cycles and are finalized while rc?

- What about patches which are sent immediately after merge window 
closed (hours - 1 or 2 days)? I already heard something like 'no 
problem if it comes some hours later, if it is fine then I will still 
apply it'.

What I personally find essential for patch submitters is the patch 
dealing by custodian. It should be consistent and by this somehow 
predictable. This helps patch submitters to get a feeling for 'this 
patch has only a chance while merge window is open' or 'it's worth 
sending this patch immediately, it will have a chance to be merge now'.

What confuses me is something like patch A is applied short time after 
sent, patch B will be eventually applied later to next, patch C gets 
no comments. With A and B doing the same stuff, and maybe C sent before A.

> I can't say for sure if this is how all branches are
> handled, though.

Let's wait for Jean-Christophe opinion.

Best regards

Dirk

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Dirk Behme]

David Brownell wrote:
> On Friday 24 April 2009, Dirk Behme wrote:
>> Btw.: Now that -next exists, I can't find patch linked above in it, 
>> though :(
> 
>   http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
> 
> shows it ... "respects SKIP_LOWLEVEL_INIT".  Make sure
> to look at the "next" branch there; you can start from
> 
>   http://git.denx.de/?p=u-boot/u-boot-arm.git
> 
> Then page to the bottom, "heads" --> next, then shortlog.
> They're all there, except the dm9000 eeprom bugfix.

Sorry for being unclear. Yes, your Davinci patches are there. With 
'patch linked above' I meant

OMAP3: Remove legacy NAND defines
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html

which Jean-Christophe mentioned to apply against -next: "will be apply 
on the next".

Or did I miss it in

http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next

again? Please correct me then (and send me some more coffee) ;)

Best regards

Dirk

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Ben Warren]

Hi David,

David Brownell wrote:
> On Friday 24 April 2009, Ben Warren wrote:
>   
>> My approach is that once the merge window closes, new patches that are not
>> bug fixes go into 'next', which is for the release after the current one (in
>> this case 07). 
>>     
>
> Then I'm curious how that dm9000 EEPROM reading bugfix
> landed in net/next ... or is the point that the merge
> window for 2009.05 is still open, since RC1 hasn't yet
> been tagged?
>
>   
In this case a pretty good argument could be made that it's a bug fix 
and not a feature, so can go in 2009.05.  Obviously bugs that break 
builds get more attention than ones that have been in code for a while 
and nobody noticed.  I'll ask Wolfgang to pick it up directly.  As 
you're noticing, how and when patches are picked up is open to many 
interpretations.

regards,
Ben

[U-Boot] U-Boot ARM merge strategy

[Ben Warren]

Hi Dirk,

Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme 
>> <dirk.behme@googlemail.com>wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> David Brownell wrote:
>>> ...
>>>>>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>>>> the Patch series and this has been apply in the u-boot-arm/next
>>>> I see that branch now exists ... thanks!  :)
>>> ....
>>>> Could you clarify the current merge cycle for me, by the way?
>>>> I know u-boot has switched to 2009.{01,03,05,...} releases,
>>>> which is a big win from where I sit!, with "rc" tags.
>>>>
>>>> What I'm unclear on is what gets merged for 2009.05 versus
>>>> later.  Are these "next" branches for the '05 release (which
>>>> hasn't yet hit rc1)?  Or for '07 instead?
>>> Yes, I have the same questions. I already tried to ask similar, but
>>> didn't get an answer.
>>>
>>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>>>
>>> Maybe my wording was a little unclear?
>>>
>>> Dirk
>>>
>>> Btw.: Now that -next exists, I can't find patch linked above in it,
>>> though :(
>>>
>>
>> My approach is that once the merge window closes, new patches that 
>> are not
>> bug fixes go into 'next', which is for the release after the current 
>> one (in
>> this case 07).  When the merge window opens again, next goes to 
>> master and
>> the fun starts again.
>
> Yes, this is my basic understanding, too.
>
> But there are always these ugly details ;)
>
> - What's about patches that remove dead code, unused macros etc. IMHO 
> they can be handled like bug fixes and applied while rc?
>
I agree that cleanup patches should have more flexibility.
> - What's about patches that are sent while open merge window or 
> before, but need some update cycles and are finalized while rc?
>
My policy is to look at the timestamp of the first revision.  If it's 
during the merge window, follow-on versions are OK too.
> - What about patches which are sent immediately after merge window 
> closed (hours - 1 or 2 days)? I already heard something like 'no 
> problem if it comes some hours later, if it is fine then I will still 
> apply it'.
>
Well, since communication about the window state is rare at best, a good 
argument can be made for flexibility here.
> What I personally find essential for patch submitters is the patch 
> dealing by custodian. It should be consistent and by this somehow 
> predictable. This helps patch submitters to get a feeling for 'this 
> patch has only a chance while merge window is open' or 'it's worth 
> sending this patch immediately, it will have a chance to be merge now'.
>
Sure - consistency would be great.  Unfortunately every custodian has 
his own approach and it's a volunteer workforce.  Definitely a goal 
worth pursuing, though.
> What confuses me is something like patch A is applied short time after 
> sent, patch B will be eventually applied later to next, patch C gets 
> no comments. With A and B doing the same stuff, and maybe C sent 
> before A.
>
Yeah, better and quicker feedback is a goal we should all be working 
towards.  Obviously small, trivial patches are easier to review than new 
drivers, and so are typically applied more quickly.
>> I can't say for sure if this is how all branches are
>> handled, though.
>
> Let's wait for Jean-Christophe opinion.
>
> Best regards
>
> Dirk
>
regards,
Ben

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[David Brownell]

On Saturday 25 April 2009, Ben Warren wrote:
> > Then I'm curious how that dm9000 EEPROM reading bugfix
> > landed in net/next ... or is the point that the merge
> > window for 2009.05 is still open, since RC1 hasn't yet
> > been tagged?
> >
> 
> In this case a pretty good argument could be made that it's a bug fix 
> and not a feature, so can go in 2009.05.

Right.  It was one of a handful of bugfixes I've sent;
I think only one minor one remains (adjusting columns
for "mtdpart" output).


> Obviously bugs that break  
> builds get more attention than ones that have been in code for a while 
> and nobody noticed. ?I'll ask Wolfgang to pick it up directly.

Saw that; thanks.


> As  
> you're noticing, how and when patches are picked up is open to many 
> interpretations.

Yes.  The issue is needing to guess what's up ... so for
example, I seem to observe that "merge window closed" must
not be the same as "first RC is out", which isn't how the
Linux process works.  But that's the only example I've
seen for how the new u-boot cycles should work...

- Dave

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Wolfgang Denk]

Dear David Brownell,

In message <200904250003.51845.david-b@pacbell.net> you wrote:
>
> Then I'm curious how that dm9000 EEPROM reading bugfix
> landed in net/next ... or is the point that the merge
> window for 2009.05 is still open, since RC1 hasn't yet
> been tagged?

No. End of merge window and release of -rc1 are completely unrelated.

The merge window for 2009.06 (6, not 5!) was closed on Fri Apr 03,
2009, 23:59:59 CET. We're in bug fixing mode. See also:
http://www.denx.de/wiki/view/U-Boot/ReleaseCycle


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Eeeek!
'eval' on strings should have been named 'evil'.    -- Tom Phoenix in
        <Pine.GSO.3.96.980526121813.27437N-100000@user2.teleport.com>

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Dirk,

In message <49F2B6B9.7040300@googlemail.com> you wrote:
> 
> > My approach is that once the merge window closes, new patches that are not
> > bug fixes go into 'next', which is for the release after the current one (in
> > this case 07).  When the merge window opens again, next goes to master and
> > the fun starts again.
> 
> Yes, this is my basic understanding, too.

Mine, too. Note however that I will not always and not  automatically
and  not exactly at the end of the merge window create a next branch,
but I'm in a somewhat specialposition anyway.

> But there are always these ugly details ;)
> 
> - What's about patches that remove dead code, unused macros etc. IMHO 
> they can be handled like bug fixes and applied while rc?

They can, if the custodian accepts it, and.or if there is consensus on
the ML.

> - What's about patches that are sent while open merge window or 
> before, but need some update cycles and are finalized while rc?

These should go in. People who put a lot of effort in their  planning
should not suffer from the fact that a custodian is slow on answering
or reviewing their patches. Everything that has been sent to the list
before the end of the MW should go in.

> - What about patches which are sent immediately after merge window 
> closed (hours - 1 or 2 days)? I already heard something like 'no 
> problem if it comes some hours later, if it is fine then I will still 
> apply it'.

Patch acceptance is not as critical as a financial transaction, or
such. So if there is a slight delay, the custodian is free to turn a
blind eye and accept it anyway.  The idea of the development process
is to make it foreseeable and plannable, but not to become a PITA or
to slow down development.

It makes much more sense if an engineer spends another day on testing
and cleanup and submits the patch a couple of hours late, instead  of
submitting a green patch which will waste efforts from several prople
during several rounds of review and reposts.

> What I personally find essential for patch submitters is the patch 
> dealing by custodian. It should be consistent and by this somehow 
> predictable. This helps patch submitters to get a feeling for 'this 
> patch has only a chance while merge window is open' or 'it's worth 
> sending this patch immediately, it will have a chance to be merge now'.

But this should be clear: if sent while the merge indow is open, new
stuff can go in. If the MW is closed, new stuff may go into next (if
the respective custodian runs a next branch), otherwise it has to wait
until the next MW.  Bug fixes can go in any time.

> What confuses me is something like patch A is applied short time after 
> sent, patch B will be eventually applied later to next, patch C gets 
> no comments. With A and B doing the same stuff, and maybe C sent before A.

I agree that this is not nice.

In any case,  there  should  be  some  comment  from  the  respective
custodian which makes *clear* what the patch state is. Even a "I have
no  time  now, will look into it later" is better than nothing. Also,
if there are remarks to a patch, these should leave no doubt if  they
were  just  comments and the patch will be accepted anyway, or if the
patch should be reworked/resubmitted, or if the  patch  was  rejected
without chance to be included at all.

> > I can't say for sure if this is how all branches are
> > handled, though.
> 
> Let's wait for Jean-Christophe opinion.

Well, his opinion is one thing. But I think we can also  expect  from
Jean-Christophe  as  ARM  custodian that he delivers clear and under-
standable feedback to all patch submitters.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Make it right before you make it faster.

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Ben Warren,

In message <49F2BED7.9070600@gmail.com> you wrote:
> 
> > - What about patches which are sent immediately after merge window 
> > closed (hours - 1 or 2 days)? I already heard something like 'no 
> > problem if it comes some hours later, if it is fine then I will still 
> > apply it'.
> >
> Well, since communication about the window state is rare at best, a good 
> argument can be made for flexibility here.

While I agree on your comment on flexibility, I strongly repudiate
the statement that the MW state is not clearly communicated. Please
have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and
then tell me what exactly is not clear enough.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'm what passes for a Unix guru in my office. This is  a  frightening
concept. - Lee Ann Goldstein, in <3k55ba$c43@butch.lmsc.lockheed.com>

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Wolfgang Denk]

Dear David Brownell,

In message <200904250105.41050.david-b@pacbell.net> you wrote:
>
> Yes.  The issue is needing to guess what's up ... so for
> example, I seem to observe that "merge window closed" must
> not be the same as "first RC is out", which isn't how the
> Linux process works.  But that's the only example I've
> seen for how the new u-boot cycles should work...

Maybe I pout a little more meaning in the words  "release  candiate".
After  the  end  of  a  merge  window,  there is usually still a long
backlog of patches that has not been merged, and after that there are
several rounds of debugging / bug fixing needed. IMO it makes  little
sense to call anything in this state a "release candiate".

That's why we still have no "rc" in the current release cycle.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I've finally learned what `upward compatible' means. It means we get
to keep all our old mistakes." - Dennie van Tassel

[U-Boot] U-Boot ARM merge strategy

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Ben Warren,
> 
> In message <49F2BED7.9070600@gmail.com> you wrote:
>>> - What about patches which are sent immediately after merge window 
>>> closed (hours - 1 or 2 days)? I already heard something like 'no 
>>> problem if it comes some hours later, if it is fine then I will still 
>>> apply it'.
>>>
>> Well, since communication about the window state is rare at best, a good 
>> argument can be made for flexibility here.
> 
> While I agree on your comment on flexibility, I strongly repudiate
> the statement that the MW state is not clearly communicated. Please
> have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle 

Ups, this link is new to me. Thanks for it :)

> and
> then tell me what exactly is not clear enough.

Yes, you are right, above link is quite clear.

While I didn't know above link, my way to get the recent merge window 
info was to join IRC and to check the recent topic.

Now, talking above about wiki and IRC above, someone might get the 
feeling 'and what's about the mailing list'? Maybe we can help people 
by pushing the available info from IRC/wiki more actively into their 
inboxes? (*)

I could imagine to have 4 or 5 points were an additional mail (besides 
IRC/wiki update) would make sense:

- Some days before merge window opens "merge window opens in t days, 
become ready"
- Version z created. Merge window is open. Will be open until ...
- Merge window will close in some days, please become ready
- Merge window closed now. Next merge window is planned for x, first 
-rc is planned for y.

And if we want to make it perfect, each -rc could get a similar 
announcement, too.

Please note that I don't want to say that this didn't happen in the 
past. I just want to say that there might be the _feeling_ that the 
info isn't there and that people are too lazy to search for it. And 
with this more info on the mailing list could help.

Best regards

Dirk

(*) Well, most probably we should do it less often than RMK does post 
his FAQs on arm-linux-kernel mailing list ;)

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Dirk Behme]

Wolfgang Denk wrote:
> Dear David Brownell,
> 
> In message <200904250105.41050.david-b@pacbell.net> you wrote:
>> Yes.  The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> Linux process works.  But that's the only example I've
>> seen for how the new u-boot cycles should work...
> 
> Maybe I pout a little more meaning in the words  "release  candiate".
> After  the  end  of  a  merge  window,  there is usually still a long
> backlog of patches that has not been merged, and after that there are
> several rounds of debugging / bug fixing needed. IMO it makes  little
> sense to call anything in this state a "release candiate".
> 
> That's why we still have no "rc" in the current release cycle.

Thanks for this info!

This is *exactly* what I meant in the previous mail with "actively 
keep people informed what is going on by posting status info to the 
mailing list".

Thanks and best regards

Dirk

[U-Boot] U-Boot ARM merge strategy

[David Brownell]

On Saturday 25 April 2009, Wolfgang Denk wrote:
> > Yes. ?The issue is needing to guess what's up ... so for
> > example, I seem to observe that "merge window closed" must
> > not be the same as "first RC is out", which isn't how the
> > Linux process works. ?But that's the only example I've
> > seen for how the new u-boot cycles should work...

... although that wiki page you referenced does seem to
have been updated, on 3-April, to say that the next release
got renamed (to 2009.06) and its merge window closed.

I think the questions on this topic reflect a reality that
such status updates aren't yet visible enough.  (The original
question was generic, not ARM-specific.)


> Maybe I pout a little more meaning in the words?"release?candiate".

ISTR that Linus has said on occasion that "RC" doesn't
mean "release candidate"!


> After ?the ?end ?of ?a ?merge ?window, ?there is usually still a long
> backlog of patches that has not been merged, and after that there are
> several rounds of debugging / bug fixing needed. IMO it makes ?little
> sense to call anything in this state a "release candiate".

A Linux RC1 just means "end of merge window, now let's
start fixing all the bugs we've just let in."

You're not actually running the "merge window" quite like
Linux does; that "backlog" is one differentiator.


> That's why we still have no "rc" in the current release cycle.

May be worth reconsidering that, if for no other reason than
to make intermedite milestones less opaque ... example, there
was no suitably titled announcement in the list archives that
the 2009.05 release got re-labeled, but I did eventually find

  http://lists.denx.de/pipermail/u-boot/2009-April/050339.html

When the RC label just means "we only integrate bugfixes now",
that communicates such status with very little work.  If folk
miss some webpage, or mailing list post, they'll still know.

- Dave

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Dirk,

In message <49F2F59A.80509@googlemail.com> you wrote:
> 
> > While I agree on your comment on flexibility, I strongly repudiate
> > the statement that the MW state is not clearly communicated. Please
> > have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle 
> 
> Ups, this link is new to me. Thanks for it :)

Well, I thought it is easy to find. Even google for "u-boot merge
window" lists it as first link.

> Now, talking above about wiki and IRC above, someone might get the 
> feeling 'and what's about the mailing list'? Maybe we can help people 
> by pushing the available info from IRC/wiki more actively into their 
> inboxes? (*)

So what about

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/56294

? 

> I could imagine to have 4 or 5 points were an additional mail (besides 
> IRC/wiki update) would make sense:
> 
> - Some days before merge window opens "merge window opens in t days, 
> become ready"
> - Version z created. Merge window is open. Will be open until ...
> - Merge window will close in some days, please become ready
> - Merge window closed now. Next merge window is planned for x, first 
> -rc is planned for y.

I think that would be serious overkill. If you are interested in the
U-Boot development cycle you can get the information easily - see
above. If you need fine-grained reminders, set up a local reminder
program.

> And if we want to make it perfect, each -rc could get a similar 
> announcement, too.

Would ne not just add a lot of noise to the ML, without any real new
information?

If you want detailed information about each action, please feel free
and register a RSS feed on the git repository.

> Please note that I don't want to say that this didn't happen in the 
> past. I just want to say that there might be the _feeling_ that the 
> info isn't there and that people are too lazy to search for it. And 
> with this more info on the mailing list could help.

Sorry, but I cannot  really  follow  you.  All  the  information  you
request  for seems to be present to me. I have posted this on the ML,
and I update the web page pretty promptly.

I don;t know why you missed the information.

> (*) Well, most probably we should do it less often than RMK does post 
> his FAQs on arm-linux-kernel mailing list ;)

He. At least his "You disturb me. Go away!" message add some spice ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't care.  We don't have to.  We're the Phone Company."

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear David,

in message <200904250555.17450.david-b@pacbell.net> you wrote:
>
> I think the questions on this topic reflect a reality that
> such status updates aren't yet visible enough.  (The original
> question was generic, not ARM-specific.)

I'm not going to push this information down people's throats. I  love
living  free.  Those  who want that information can pick it up, those
who don't will not get bothered.

Is it really too much to ask that people have a look at the U-Boot web
page every now and then? Is it really so difficult to find our when
the merge window ends? Just type "u-boot merge window" at google and
click on the very first link.

> > Maybe I pout a little more meaning in the words?"release?candiate".
> 
> ISTR that Linus has said on occasion that "RC" doesn't
> mean "release candidate"!

He. This is his interpretation, then. I take the freedom to use a
different one :-)

> You're not actually running the "merge window" quite like
> Linux does; that "backlog" is one differentiator.

Well, yes, I know. The tiome when I get the pull requests from the
custodians is another one - being a major contribution to the former.

> > That's why we still have no "rc" in the current release cycle.
> 
> May be worth reconsidering that, if for no other reason than
> to make intermedite milestones less opaque ... example, there
> was no suitably titled announcement in the list archives that
> the 2009.05 release got re-labeled, but I did eventually find
> 
>   http://lists.denx.de/pipermail/u-boot/2009-April/050339.html

Yes, that was when we discussed the change.

I edited the web page within the same hour, IIRC.

> When the RC label just means "we only integrate bugfixes now",
> that communicates such status with very little work.  If folk
> miss some webpage, or mailing list post, they'll still know.

Please allow me to stick with RC = release candidate, i. e. something
that is at least reasonably compile  tested  and  has  at  least  the
majority of patches included.

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A quarrel is quickly settled when deserted by one party; there is  no
battle unless there be two.                                  - Seneca

[U-Boot] U-Boot ARM merge strategy

[Ben Warren]

Hi Wolfgang,

Wolfgang Denk wrote:
> Dear Ben Warren,
>
> In message <49F2BED7.9070600@gmail.com> you wrote:
>   
>>> - What about patches which are sent immediately after merge window 
>>> closed (hours - 1 or 2 days)? I already heard something like 'no 
>>> problem if it comes some hours later, if it is fine then I will still 
>>> apply it'.
>>>
>>>       
>> Well, since communication about the window state is rare at best, a good 
>> argument can be made for flexibility here.
>>     
>
> While I agree on your comment on flexibility, I strongly repudiate
> the statement that the MW state is not clearly communicated. Please
> have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and
> then tell me what exactly is not clear enough.
>
>   
I agree that the web site clearly tells the release cycle timeline, and 
apparently there's lots of chatter on IRC about it, but since the ML is 
supposedly the primary medium for U-boot information it probably 
wouldn't hurt to send an e-mail or two.  I imagine the technology exists 
to make such a thing automatic.  OTOH I know you're a busy guy and 
periodically checking a website should be reasonable.

I'm not trying to be a dick - just expressing my point of view.  I 
should probably make more of an effort to use the IRC channel, since it 
seems that that's where the real action happens.
> Best regards,
>
> Wolfgang Denk
>   
cheers,
Ben

[U-Boot] U-Boot ARM merge strategy

[Jean-Christophe PLAGNIOL-VILLARD]

On 09:07 Sat 25 Apr     , Dirk Behme wrote:
> Hi Ben,
>
> Ben Warren wrote:
>> Hi Dirk,
>>
>> On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme <dirk.behme@googlemail.com>wrote:
>>
>>> Dear Jean-Christophe,
>>>
>>> David Brownell wrote:
>>> ...
>>>>>>   http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
>>>>> the Patch series and this has been apply in the u-boot-arm/next
>>>> I see that branch now exists ... thanks!  :)
>>> ....
>>>> Could you clarify the current merge cycle for me, by the way?
>>>> I know u-boot has switched to 2009.{01,03,05,...} releases,
>>>> which is a big win from where I sit!, with "rc" tags.
>>>>
>>>> What I'm unclear on is what gets merged for 2009.05 versus
>>>> later.  Are these "next" branches for the '05 release (which
>>>> hasn't yet hit rc1)?  Or for '07 instead?
>>> Yes, I have the same questions. I already tried to ask similar, but
>>> didn't get an answer.
>>>
>>> http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
>>>
>>> Maybe my wording was a little unclear?
>>>
>>> Dirk
>>>
>>> Btw.: Now that -next exists, I can't find patch linked above in it,
>>> though :(
>>>
>>
>> My approach is that once the merge window closes, new patches that are not
>> bug fixes go into 'next', which is for the release after the current one (in
>> this case 07).  When the merge window opens again, next goes to master and
>> the fun starts again.
>
> Yes, this is my basic understanding, too.
>
> But there are always these ugly details ;)
>
> - What's about patches that remove dead code, unused macros etc. IMHO  
> they can be handled like bug fixes and applied while rc?
>
> - What's about patches that are sent while open merge window or before, 
> but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to
finish it during the fix window NO
If the patch is really risky it will depends on it
Otherwise ok
>
> - What about patches which are sent immediately after merge window  
> closed (hours - 1 or 2 days)? I already heard something like 'no problem 
> if it comes some hours later, if it is fine then I will still apply it'.
For me when the first version of a is send after the close of the merge and
it's not a bug fix, then it will go to the next MW. The only exception will be
if the patch come from an announce or a thread discussion and/or really improve
U-Boot. Otherwise no exception.
>
For next branch, it will depend if you have big change announce or big patch
series I will create one. Otherwise patch will simply wait until the MW.

For other branch, I'm not really a fan expect if it will help people to work
together an a specific task

Best Regards,
J.

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090425170829.GA30476@game.jcrosoft.org> you wrote:
>
> > - What's about patches that are sent while open merge window or before, 
> > but need some update cycles and are finalized while rc?
> Depends, if the patch is send just before the merge just to have time to
> finish it during the fix window NO

How do you reliably find out that this is the case?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The most difficult thing in the world is to know how to  do  a  thing
and to watch someone else doing it wrong, without commenting.
                                                        -- T.H. White

[U-Boot] U-Boot ARM merge strategy

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:30 Sat 25 Apr     , Wolfgang Denk wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
> 
> In message <20090425170829.GA30476@game.jcrosoft.org> you wrote:
> >
> > > - What's about patches that are sent while open merge window or before, 
> > > but need some update cycles and are finalized while rc?
> > Depends, if the patch is send just before the merge just to have time to
> > finish it during the fix window NO
> 
> How do you reliably find out that this is the case?
the patch is not finish and will clearly not work on the hard
I've no example except a patch will is more a RFC than a really patch I've in
mind

Best Regards,
J.

[U-Boot] U-Boot ARM merge strategy

[David Brownell]

Hi Wolfgang,

On Saturday 25 April 2009, Wolfgang Denk wrote:
> in message <200904250555.17450.david-b@pacbell.net> you wrote:
> >
> > I think the questions on this topic reflect a reality that
> > such status updates aren't yet visible enough.  (The original
> > question was generic, not ARM-specific.)
> 
> I'm not going to push this information down people's throats. I  love
> living  free.  Those  who want that information can pick it up, those
> who don't will not get bothered.
> 
> Is it really too much to ask that people have a look at the U-Boot web
> page every now and then?

It's not on the front page, which is where for example you'll
see status for Linux (www.kernel.org) or GCC (gcc.gnu.org).
And it's not visible in the source tree either.


> Is it really so difficult to find our when 
> the merge window ends?

By observation:  yes.

But also, when you *do* find the Official Statment it does
so in reference to Linux processes ... which make that state
very easy to find, via the "rc1" git tags.


> Just type "u-boot merge window" at google and 
> click on the very first link.

Several other key infrastructure projects make it easy to
find that info even without using a search engine.

As a developer, I'd be more likely to look at the GIT summary
for status of the GIT tree; its normally the first place to
look for such things.


> > > Maybe I pout a little more meaning in the words?"release?candiate".
> > 
> > ISTR that Linus has said on occasion that "RC" doesn't
> > mean "release candidate"!
> 
> He. This is his interpretation, then. I take the freedom to use a
> different one :-)

You won't find SuSE, RedHat, or Canonical using an rc1 kernel
for even a beta distribution ... ;)

 
> > You're not actually running the "merge window" quite like
> > Linux does; that "backlog" is one differentiator.
> 
> Well, yes, I know. The tiome when I get the pull requests from the
> custodians is another one - being a major contribution to the former.

And Linux has had years to develop -- and motivate! -- its
merge procedures ... it's a different team and process.

Processes need constant tweaking though.  And your process
page strongly suggests you're using the Linux processes.
Hence surprise and confusion when you aren't quite doing so,
from folk who use those processes daily.

Easily addressed though ... that web page can point out some
differences.  Make a few small things *obviously* different,
and people will assume that other things may also differ.


> > When the RC label just means "we only integrate bugfixes now",
> > that communicates such status with very little work.  If folk
> > miss some webpage, or mailing list post, they'll still know.
> 
> Please allow me to stick with RC = release candidate, i. e. something
> that is at least reasonably compile  tested  and  has  at  least  the
> majority of patches included.

I couldn't stop you, of course.  All I'm doing is pointing out
what others have also pointed out:  that the current process
is a bit opaque about some key points.  And I'm trying to help
with some small suggestions.

Since you don't want to use an "rc" tag -- even "rc0"? -- maybe
some other git tag could be used to flag "merge window ended".
A "-pre", maybe.  If there's some obvious indicator there, you
wouldn't need to update the wiki except maybe to summarize key
points of the process you want to publicize.  And contributors
wouldn't be scratching their heads, or starting long discussions
on the list.  ;)

- Dave

[U-Boot] U-Boot ARM merge strategy

[David Brownell]

On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> For me when the first version of a [patch] is send after the close of the merge and
> it's not a bug fix, then it will go to the next MW. The only exception will be
> if the patch come from an announce or a thread discussion and/or really improve
> U-Boot. Otherwise no exception.

Wiki might usefully include this as part of that release
cycle page that Wolfgang pointed out:

 * Bug fixes coming in after a merge window closes may
   still be included in the upcoming release if they are
   high enough priority.

 * Other patches coming in after the merge window will be
   held until the next merge window, possibly in a -next
   branch of a custodian tree.

 * Maintainers may, infrequently, make exceptions to those
   merge policies.

It'd still be good to make the "merge window ended" state
more visible, e.g. through *some* GIT tag.  IMNSHO.

- Dave

[U-Boot] U-Boot ARM merge strategy

[Dirk Behme]

Wolfgang Denk wrote:
> Dear Ben Warren,
> 
> In message <49F2BED7.9070600@gmail.com> you wrote:
>>> - What about patches which are sent immediately after merge window 
>>> closed (hours - 1 or 2 days)? I already heard something like 'no 
>>> problem if it comes some hours later, if it is fine then I will still 
>>> apply it'.
>>>
>> Well, since communication about the window state is rare at best, a good 
>> argument can be made for flexibility here.
> 
> While I agree on your comment on flexibility, I strongly repudiate
> the statement that the MW state is not clearly communicated. Please
> have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and
> then tell me what exactly is not clear enough.

With the discussion I think we can answer this question now with a 
short summary:

a) All information is there

b) Some people feel that copying this already available info to 
mailing list would

" ... just add a lot of noise to the ML, without any real new 
information .."

c) On the other hand, some people seem to have the feeling that

"status updates aren't yet visible enough"

"that the current process is a bit opaque about some key points"

"... IRC channel ... it seems that that's where the real action happens"

While my feeling tends to (c), too (this is why I e.g. asked for an 
IRC log), I accept (b) and agree with (a).

Many thanks for this discussion, it already helped a lot, and best regards

Dirk

P.S.: Sorry if I didn't cite your argument or missed an essential one ;)

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear David,

In message <200904251153.51380.david-b@pacbell.net> you wrote:
> 
> > Just type "u-boot merge window" at google and 
> > click on the very first link.
> 
> Several other key infrastructure projects make it easy to
> find that info even without using a search engine.

Come on and be reasonable. Yes, the current release state is not on the
front page. But it is just one click away.

And my reference to google was just because of the argument "difficult
to find".

> As a developer, I'd be more likely to look at the GIT summary
> for status of the GIT tree; its normally the first place to
> look for such things.

I agree fully with this statement. But at the same time I have to
point out that this is exactly where our opinions differ:

- You expect that the U-Boot git repository mirrors the current state
  in the release process, ideally in the same way as Linux handles
  this.

- For me, the current phase of the release process is not necessarily
  reflected by a specific tag on the git tree.

This is a (as I think unavoidable) consequence of the existing
differences in the prcedures:

* In Linux, top-level maintainers will collect patches in their trees
  and send pull requests to Linus as soon as the merge window opens.

  So far, most U-Boot custodians do not work like that; they send
  pull requests only at (or even after) the end of the merge window.

* In Linux, the closing of the merge window is maked by
  the release of the next ="-rc1"

  In U-Boot, "-rc1" will only be released after all (or at least most
  of the) patches that were submitted during the merge window have
  been applied.


> > Well, yes, I know. The tiome when I get the pull requests from the
> > custodians is another one - being a major contribution to the former.
> 
> And Linux has had years to develop -- and motivate! -- its
> merge procedures ... it's a different team and process.
> 
> Processes need constant tweaking though.  And your process
> page strongly suggests you're using the Linux processes.
> Hence surprise and confusion when you aren't quite doing so,
> from folk who use those processes daily.

Well, it's exactly my intention to do things differnetly or to cause
confusion :-(

But the thing is, that we (the custodians and me) are not working
(yet?) as the Linux maintainers do. I hope we can improve.


I am really thankful for this discussion - IIRC this is the first time
ever that suchtopics have been discussed here.


> Easily addressed though ... that web page can point out some
> differences.  Make a few small things *obviously* different,
> and people will assume that other things may also differ.

I tried to make things a bit clearer. Please have a look at
http://www.denx.de/wiki/U-Boot/ReleaseCycle  and
http://www.denx.de/wiki/U-Boot/DevelopmentProcess   and let me know
what's unclear or missing or needs improvement (or, even better, edit
it yourself -it's a wiki after all, where everybody can contribute).

> 
> > > When the RC label just means "we only integrate bugfixes now",
> > > that communicates such status with very little work.  If folk
> > > miss some webpage, or mailing list post, they'll still know.
> > 
> > Please allow me to stick with RC = release candidate, i. e. something
> > that is at least reasonably compile  tested  and  has  at  least  the
> > majority of patches included.
> 
> I couldn't stop you, of course.  All I'm doing is pointing out
> what others have also pointed out:  that the current process
> is a bit opaque about some key points.  And I'm trying to help
> with some small suggestions.

I've tried to explain the reasons for the differences on the web page.

> Since you don't want to use an "rc" tag -- even "rc0"? -- maybe
> some other git tag could be used to flag "merge window ended".

Please see above - I feel it would be wrong, as the "merge window
closed" state is nothing that has a direct representation in our git
tree.

> A "-pre", maybe.  If there's some obvious indicator there, you
> wouldn't need to update the wiki except maybe to summarize key
> points of the process you want to publicize.  And contributors
> wouldn't be scratching their heads, or starting long discussions
> on the list.  ;)

But this discussion is/was a good thing to have!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Open the pod bay doors, HAL."                    - Dave Bowman, 2001

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear David Brownell,
> 
> In message <200904250105.41050.david-b@pacbell.net> you wrote:
>> Yes.  The issue is needing to guess what's up ... so for
>> example, I seem to observe that "merge window closed" must
>> not be the same as "first RC is out", which isn't how the
>> Linux process works.  But that's the only example I've
>> seen for how the new u-boot cycles should work...
> 
> Maybe I pout a little more meaning in the words  "release  candiate".
> After  the  end  of  a  merge  window,  there is usually still a long
> backlog of patches that has not been merged, and after that there are
> several rounds of debugging / bug fixing needed. IMO it makes  little
> sense to call anything in this state a "release candiate".
> 
> That's why we still have no "rc" in the current release cycle.
> 
> Best regards,
> 
> Wolfgang Denk

Make sense on "rc" not really being a release candidate.  How about 
tagging "mc" for "Merge Closed"?

gvb

[U-Boot] U-Boot ARM merge strategy, was: there are non-DM6446 DaVinci chips

[Wolfgang Denk]

Dear Jerry Van Baren,

In message <49F5B6AF.5060606@ge.com> you wrote:
>
> > Maybe I pout a little more meaning in the words  "release  candiate".
> > After  the  end  of  a  merge  window,  there is usually still a long
> > backlog of patches that has not been merged, and after that there are
> > several rounds of debugging / bug fixing needed. IMO it makes  little
> > sense to call anything in this state a "release candiate".
> > 
> > That's why we still have no "rc" in the current release cycle.
...
> Make sense on "rc" not really being a release candidate.  How about 
> tagging "mc" for "Merge Closed"?

OK - but we have not reached that  state  either  yet,  I  think.  As
mentioned before, I have a problem to relate a deadline thing without
any direct impact on the code (as the closing of the merge window) to
a git tag which represents a certain state. "Merge Closed" definitely
represents  such  a  state,  but  then  we could issue "-rc1" as well
(using the same free interpretation as in Linux), and  it  would  not
indicate what has been asked for: the closinf of the MW.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... The prejudices people feel about each other disappear  when  then
get to know each other.
	-- Kirk, "Elaan of Troyius", stardate 4372.5

[U-Boot] U-Boot ARM merge strategy

[Detlev Zundel]

Hi Wolfgang,

>> And if we want to make it perfect, each -rc could get a similar 
>> announcement, too.
>
> Would ne not just add a lot of noise to the ML, without any real new
> information?
>
> If you want detailed information about each action, please feel free
> and register a RSS feed on the git repository.

I think you mean the RSS feeds of the TWiki, right?

Cheers
  Detlev

-- 
In the topologic hell the beer is packed in Klein's bottles.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Detlev,

In message <m2hc0aqetd.fsf@ohwell.denx.de> you wrote:
> 
> >> And if we want to make it perfect, each -rc could get a similar 
> >> announcement, too.
> >
> > Would ne not just add a lot of noise to the ML, without any real new
> > information?
> >
> > If you want detailed information about each action, please feel free
> > and register a RSS feed on the git repository.
> 
> I think you mean the RSS feeds of the TWiki, right?

No, I meant exactly what I wrote - the RSS feed on the git repo
(http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of
the web page) so you get informed when new stuff gets in.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In any group of employed individuals the only naturally  early  riser
is  _always_  the office manager, who will _always_ leave reproachful
little notes ... on the desks of their subordinates.
                                - Terry Pratchett, _Lords and Ladies_

[U-Boot] U-Boot ARM merge strategy

[Detlev Zundel]

Hi Wolfgang,

>> >> And if we want to make it perfect, each -rc could get a similar 
>> >> announcement, too.
>> >
>> > Would ne not just add a lot of noise to the ML, without any real new
>> > information?
>> >
>> > If you want detailed information about each action, please feel free
>> > and register a RSS feed on the git repository.
>> 
>> I think you mean the RSS feeds of the TWiki, right?
>
> No, I meant exactly what I wrote - the RSS feed on the git repo
> (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of
> the web page) so you get informed when new stuff gets in.

Ok, then I simply fail to understand you, as we all agreed that the
state of the project is not to be found in the source repository but on
a TWiki web page.

However, let's move on.

Cheers
  Detlev

-- 
I haven't lost my mind, I know exactly where I left it.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] U-Boot ARM merge strategy

[Wolfgang Denk]

Dear Detlev,

In message <m2iqkpp49c.fsf@ohwell.denx.de> you wrote:
> 
> >> >> And if we want to make it perfect, each -rc could get a similar 
> >> >> announcement, too.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> > No, I meant exactly what I wrote - the RSS feed on the git repo
> > (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of
> > the web page) so you get informed when new stuff gets in.
> 
> Ok, then I simply fail to understand you, as we all agreed that the
> state of the project is not to be found in the source repository but on
> a TWiki web page.

The OP's question was about notification of a "rc" commit in the git
repository. This is something you can find out through the git repo's
RSS.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
ATTENTION: Despite Any Other Listing of Product Contents Found  Here-
on, the Consumer is Advised That, in Actuality, This Product Consists
Of 99.9999999999% Empty Space.