I meant nope, no objections -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
On Thu, Mar 5, 2015 at 10:49 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > +1 > > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber > <http://www.tomitribe.com> > > 2015-03-05 10:48 GMT+01:00 Mark Struberg <strub...@yahoo.de>: > > > So was there a final conclusion? > > I get it that it makes sense to create a stabilisation branch shortly > > before really rolling a release (kind fo RC builds). This is basically a > > release branching attempt. > > But as we lack of a ReleaseManager who _reviews_ and pulls over all those > > changes on a daily basis I thin there is just no justification for this > > development branch thingy. > > > > Any objections to merge development into master? > > > > LieGrue, > > strub > > > > > > > Am 31.01.2015 um 13:36 schrieb Thiago Veronezi <thi...@veronezi.org>: > > > > > > Oh... I see. I'm not talking about feature implementation. I'm talking > > > about the release process and release branches. > > > I don't like a branch per feature either. :) We don't need that. > > > > > > > > > On Sat, Jan 31, 2015 at 7:31 AM, Mark Struberg <strub...@yahoo.de> > > wrote: > > > > > >> If you push it to github or attach it as patch you will get help. > > >> That was also the way it used to be with SVN. And it would even be ok > to > > >> grant an ASF colleague rights to your github repo or pull a fix from > > him. > > >> > > >> Of course it would be even better if we could have such branches in a > > >> 'sandbox' repo on ASF hardware. But we don't have those YET... :) > > >> > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > >> > > >> > > >> > > >>> On Saturday, 31 January 2015, 13:28, Romain Manni-Bucau < > > >> rmannibu...@gmail.com> wrote: > > >>>> No help yes. That is what we should target anyway. > > >>> > > >>> And removing a remote temp branch is not bad. > > >>> > > >>> Mark got a good proposal with staging mirrors of main asf repos. > > >>> > > >>> Le 31 janv. 2015 13:22, "Thiago Veronezi" <thi...@veronezi.org> > > >>> a écrit : > > >>> > > >>>> @Romain: if we are talking about temp remote branches, it implies > > later > > >>>> removal of this branch [bad] otherwise we end up with dead branches > > >> [bad]. > > >>>> If we are talking about local or remote branches that can be used by > > >> only > > >>>> one person, it implies no help from the other developers [bad]. > > >>>> > > >>>> > > >>>> > > >>>> On Sat, Jan 31, 2015 at 4:46 AM, Romain Manni-Bucau > > >>> <rmannibu...@gmail.com > > >>>>> > > >>>> wrote: > > >>>> > > >>>>> @Thiago: not exactly since we do it in temp branches which could > even > > >>> be > > >>>>> private > > >>>>> Le 31 janv. 2015 10:32, "Mark Struberg" > > >>> <strub...@yahoo.de> a écrit : > > >>>>> > > >>>>>>> The "Apache Way” is not a set of rules. The Apache Way > > >>> is > > >>>>>> > > >>>>>>> community over code. That’s it. Nothing else. > > >>>>>> > > >>>>>> > > >>>>>> Alan, it is important but all that comes only _after_ some very > > >>> basic > > >>>>>> legal rules we have to follow. > > >>>>>> Those are not many, but they exist. E.g. if a PMC doesn't > > >>> like to > > >>>> follow > > >>>>>> the license and marks guidelines then it will simply get shut > > >>> down by > > >>>>>> board. And I'm glad that we don't have such issues at > > >>> TomEE. > > >>>>>> > > >>>>>> > > >>>>>> To understand the importance of code provenance you just need to > > >>> look > > >>>> at > > >>>>>> the current subpoena we have to handle: > > >>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > https://blogs.apache.org/foundation/entry/the_apache_software_foundation_subpoenaed1 > > >>>>>> > > >>>>>> So it is really _very_ important for the foundation to have a > > >>> very good > > >>>>>> SCM history which can stand the proof of court! > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> LieGrue, > > >>>>>> strub > > >>>>>> > > >>>>> > > >>>> > > >>> > > >> > > > > >
