Hi,
On Mon, 30 May 2011 13:42:19 -0500
Norbert Thiebaud
wrote:
> after that, cherry pick, and never ever merge one way or the other.
> (iow the 3.X branch diverge from that point on)
What could still be done though is to do throw-away-merges: Merge them
without pushing, just to see that nothing
On Mon, May 30, 2011 at 1:07 PM, Michael Meeks wrote:
>
> On Mon, 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:
>> Also: 3.3.3 codefreezed today with another ~35 most likely rather
>> important commits. Are those merged back to master (or manually
>
> I would hope these are all cherry
On Mon, 2011-05-30 at 19:13 +0200, Bjoern Michaelsen wrote:
> Also: 3.3.3 codefreezed today with another ~35 most likely rather
> important commits. Are those merged back to master (or manually
I would hope these are all cherry-picked back from a more recent branch
(personally).
Hi Kendy,
On Mon, 30 May 2011 18:07:34 +0200
Jan Holesovsky wrote:
> So - as long as you don't force people to do this [ie. don't force
> this as a rule, but instead let them decide if they are willing to
> wait for the merge of the branch into the master (working mostly on
> the branch before t
Hi Bjoern,
On 2011-05-30 at 11:19 +0200, Bjoern Michaelsen wrote:
> > Personally, I think I'd still recommend working on master if possible
> > and make changes against that rather than compound the complications.
>
> /me too. But I think I made that point sufficiently clear already in
> the ESC
On Mon, 30 May 2011 09:55:37 +0100
Caolán McNamara wrote:
> Personally, I think I'd still recommend working on master if possible
> and make changes against that rather than compound the complications.
/me too. But I think I made that point sufficiently clear already in
the ESC call.
Best,
Bjo
On Sun, 2011-05-29 at 11:09 -0700, John LeMoyne Castle wrote:
> The fixes in this area seem to be done and applied only in 3.4 rc2. From
> looking in other areas of work on rc2, I think I am seeing the same patching
> pattern where the rc is ahead of master. And AFAIK they are all about to
> roll
Hi all,
I did some work on LibreOffice in late 2010. Returning now I see that the
timed release schedule has created several branches that correspond to the
various release configurations. All well and good. The issue I am
experiencing is related to the various issues with standard functionalit
