On 09:57 Fri 17 Jun , Øyvind Harboe wrote: > > so we do two tree the next tree (yours) and the release tree > > > > if multiple maintainer eed to merge code together they will send it the the > > RM > > in his next branch > > > > the description will be what must follow the release tree for the other tree > > the maintainer manage his own way > > I am struggling a bit following the above, but I think we agree: > > - development goes on in master like it always has done > - you create a fork at the openocd mirror and create a release branch there. > You pick whatever you want from the master branch or whatever patches > posted that you think should go in and generally run the release cycle. in my point of view each need at least the Acked-by of SOB of one Maintainer at least as we need to trace who ack and apply what
As done in the kernel people that write the patch need to put there sob Maintainer that apply to patch the sob too Maintainer or people that ack a need the Acked-By in the commit If someone test Tested-By if someone review Reviewed-By the key point is to trace the patch work flow > - once you're done with the release, I pull it from you and push it to > the official openocd repository. I think it will be good that the development tree will not be the official release tree. > > The advantage of this approach is that we can work independently > and that you can get started today, we both have everything we need. > For intrusive and dangerous changes, we should synchronize, but most > changes to OpenOCD are small these days. Tomek's work excepted... So we officialized this before Sunday you send me the official pull request for the 0.5.1-rc1 and then until the next merge window only fix pull request can be send to me or pull request for the next branch for the next merge window I'll send an e-mail every rc and release but it will be good to have a list of maintainer that can send such kind of request with the area they are responsible of if possible a MAINTAINER file as done in the linux kernel Best Regards, J. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
