On Sat, 2014-01-11 at 10:03 -0700, EBo wrote: > On Jan 11 2014 6:19 AM, Chris Morley wrote: > > ... > >> > >> I think we are in prefect agreement. All I meant is to not commit > >> non-compilable code. But I would argue that this should be a pull > >> operation -- Lets say you have a branch dealing with TP, then you > >> get it > >> working and tested by a couple of people, then you send a pull > >> request > >> to Seb. He then merges it back into master for inclusion and wider > >> distribution and testing. > >> > > > > ah yes non compilable code is a no no for sure. That is surely a > > thing nice about the buildbots - you find out about this quickly. > > I've > > had code work great on my system but breaks on another. > > Right now I can push a 'feature' branch to the buildbot to check it > > before including it in master - but I have push access. > > fair enough. I know that non-compilable code will get pushed from time > to time (as shit always happen), but I think the point is clear. > > > I should have explained the release manager part better ( only so > > the discussion assumptions are close to reality ). > > In my experience here, after a release candidate in branched off, > > master is free to be developed. There has been little restriction on > > what > > goes in and no one-person merges work in to it. There is no master > > manager. > > I think this is a problem. How about the next (future) branch release > manager manages master until they spin off. So, if there is anyone > willing to take over what will become 2.7 or 3.0, they manage master > until we spin off the one after 2.6. Who is it that is championing the > universal build (or is that something still slated for 2.6)? Seb? > > > The release manager decides what else gets included in a release > > candidate. > > Agreed. > > > Usually only bug fixes, sometimes small atomic features can be added, > > eg new components. This is the stability and release phases. > > > > The pull request to master is a problem, as we have discussed. > > with no master manager or other point of contact, there is no way > > to make this happen or find out why it won't or can't happen. If you > > have push access you can do things right away, if not ..... > > Hopefully we can make this situation better as we go. > > It will not get better until until some change is made. What other > ideas are there to fix the issue? > > >> Setting it up on the buildbot is an interesting idea. That would > >> imply > >> that each test branch needs a champion to setup the buildbot, and > >> thwack > >> the code. It would be a little extra work for them, but would save > >> Seb > >> some time if it is agreed that after testing and the pull request > >> comes > >> that the test branch is as close to the current tip of the master as > >> possible (so very few changes necessary). > >> > > > > When I said a test branch, I meant a single branch. > > so there would be the current release, master and testing > > in degrees of less stability. > > fair enough. I was thinking that multiple test branches would allow > single ideas to be pulled in. I doubt that there will be more than a > few at any given time, but this too needs a manager and I would suggest > that it be the person that is championing the idea (because they have > the skin in the game). > > > In my mind the difference between master and testing is that testing > > work > > doesn't automatically go into master. Is this how Debain's SID works? > > This could backfire too as stuff could get left in testing forever if > > no one > > takes the reins of moving stuff to master. > > that is why I suggest designating champions. > > >> > Interesting you say that. > >> > 2.4 has about 19 unreleased bug fixes. > >> > The last fix was 19 months ago. > >> > I would say support has ended for it. > >> > >> This needs to be formally decided. Also, if there are only 19 > >> unreleased bug fixes, how much time would it take to release them, > >> and > >> formally put the code to bed. Before doing that we should ask if > >> there > >> is anyone who REALLY needs 2.4, and is willing to commit some > >> resources > >> (time or money) to have it continue to be maintained? > >> > > > > Chris Radek is the release manager of 2.4. > > My personal feeling is 2.4 should be considered end of life. > > Releasing the last bug fixes would be fine (most are actually doc > > fixes) > > Chris? Since you are the release manager, what are your thoughts? Are > you up for a final buttonup minor revision and then EOL 2.4? > > EBo --
Just to confuse the issue further: maybe the names of the branches are not as explanatory as they could be and should be modified; alpha, developmental/evolutionary, beta:tested but not necessarily solid, testing: stable but not necessarily totally solid, release; ready for general use. Sorry, I just had to rock the boat. ;-) Dave > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
