> I don't have commit access so I'll email it to the list once I've got it put
> together.
Great!
The idea is that we can then have one release coordinator(Rick Altherr) and the
other committers pitch in as well.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG d
On Dec 1, 2008, at 11:20 PM, Øyvind Harboe wrote:
It sounds like there is agreement that we need a release
coordinator. Since
I haven't heard anyone jumping at the chance, I'll throw my name in.
Super!
Can you create a file in svn trunk with a list of things to be fixed?
I think we shoul
> It sounds like there is agreement that we need a release coordinator. Since
> I haven't heard anyone jumping at the chance, I'll throw my name in.
Super!
Can you create a file in svn trunk with a list of things to be fixed?
I think we should have a quality first, no time schedule policy and
a
On Dec 1, 2008, at 10:09 PM, Øyvind Harboe wrote:
Without such a person, the stability of the branch is at risk.
True.
But there also needs to be a consensus about what 1.0 should include.
"The person" could drive such a consensus of course.
--
Øyvind Harboe
http://www.zylin.com/zy1000.
rick> Then you probably haven't seen 'make distclean' either
Oh I have - and things deep in the bowels of GDB and GCC In fact, I
have my own "googlewhack"
So that -it remains a google wack, I must spell it out... goto google
and type my name, the digit 1, a space, and the word y a i p.
Sometim
Oyvind> But there also needs to be a consensus about what 1.0 should
include.
Getting "consensus" is the best choice of action.
I think what we in the USA call - a "Laundry List"
A big list of things to do, you do not do them all.
You do the most pressing ones.
The important thing is
Oyvind> But there also needs to be a consensus about what 1.0 should
include.
Getting "consensus" is the best choice of action.
I think what we in the USA call - a "Laundry List"
A big list of things to do, you do not do them all.
You do the most pressing ones.
The important thing is
On Dec 1, 2008, at 3:41 PM, Duane Ellis wrote:
Theodore A. Roth wrote
I just did a 'make distcheck' on the 1.0 branch and it failed.
Thanks.
And I've used GNU and LINUX stuff since Slackware-95 - and I still to
this day - I come across stuff I had never seen before.
-Duane.
Theodore A. Roth wrote
>> I just did a 'make distcheck' on the 1.0 branch and it failed.
Thanks.
And I've used GNU and LINUX stuff since Slackware-95 - and I still to
this day - I come across stuff I had never seen before.
-Duane.
___
Openocd-deve
> Without such a person, the stability of the branch is at risk.
True.
But there also needs to be a consensus about what 1.0 should include.
"The person" could drive such a consensus of course.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash p
On Dec 1, 2008, at 12:10 PM, Rick Altherr wrote:
There is never a good time to make a branch. That's why you choose
tools that allow easy merging between branches and the trunk. I
wouldn't say that the 1.0 branch was cut too early. It isn't
entirely clear that all of the changes committe
> But easy to rectify with a merge rather than recutting the branch. Also,
> just the commits related to the syntax changes can be merged in without
> taking all the other changes made to ToT. Just because the syntax changes
> should be taken for 1.0 doesn't mean everything else in HEAD should be
>
> Spen: Should we delete the 1.0 branch for now and cut a new
> one once it is time?
>
> Porting back from svn trunk makes little sense at this point
> since we have changed the syntax so much and I'd be very much
> against using the old syntax in the 1.0 release
>
> --
we could delete
On Dec 1, 2008, at 12:16 PM, Øyvind Harboe wrote:
There is never a good time to make a branch.
True, but there is such a thing as a bad time to make a branch.
Cutting the 1.0 release *before* we have the syntax changes in was/
is a
bad time.
--
Øyvind Harboe
http://www.zylin.com/zy1000
> There is never a good time to make a branch.
True, but there is such a thing as a bad time to make a branch.
Cutting the 1.0 release *before* we have the syntax changes in was/is a
bad time.
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash p
On Dec 1, 2008, at 11:54 AM, Øyvind Harboe wrote:
Subversion makes it very easy to merge from trunk to branch. If
_all_ of
the changes made to trunk should be pulled into the branch, it can
be done
with 2 commands while recreating the branch takes 4. Someone
should review
the changes com
> Subversion makes it very easy to merge from trunk to branch. If _all_ of
> the changes made to trunk should be pulled into the branch, it can be done
> with 2 commands while recreating the branch takes 4. Someone should review
> the changes committed since the branch was made and make a list of
On Mon, Dec 1, 2008 at 8:37 PM, Theodore A. Roth <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 11:27 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
>> Is this broken in svn trunk?
>>
>> If it doesn't work in svn trunk, then, for sure, it won't work in the
>> 1.0 branch.
>
> Yes, it is broken in
On Mon, Dec 1, 2008 at 11:27 AM, Øyvind Harboe <[EMAIL PROTECTED]> wrote:
> Is this broken in svn trunk?
>
> If it doesn't work in svn trunk, then, for sure, it won't work in the
> 1.0 branch.
Yes, it is broken in trunk. Attached is a patch against trunk. Ignore
the previous patch since this one i
On Dec 1, 2008, at 11:27 AM, Øyvind Harboe wrote:
Is this broken in svn trunk?
If it doesn't work in svn trunk, then, for sure, it won't work in the
1.0 branch.
Spen: Should we delete the 1.0 branch for now and cut a new one once
it is time?
Porting back from svn trunk makes little sense
Is this broken in svn trunk?
If it doesn't work in svn trunk, then, for sure, it won't work in the
1.0 branch.
Spen: Should we delete the 1.0 branch for now and cut a new one once it is time?
Porting back from svn trunk makes little sense at this point since we
have changed the syntax so much an
Hi,
On Mon, Nov 24, 2008 at 3:24 AM, Spen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have created a release 1.0 branch:
> svn://svn.berlios.de/svnroot/repos/openocd/branches/openocd_1_0_branch
> if no major issues are found after say 1 month then we will tag a release.
>
> I can test the st/pic32 targ
Øyvind Harboe wrote:
>> For 1.0, do we want to consider removing support for all the old syntaxes?
>
> Yes! :-)
I would also suggest to only support the new syntax (and make sure all supplied
example files use it ;-)). A 1.0 release sounds like a good point for such a
cut.
cu
Michael
_
>
> For 1.0, do we want to consider removing support for all the
> old syntaxes? Being a major release (i.e. the first one),
> such a change would be reasonable. The downsides are the
> loss of immediate backwards compatibility with old config
> files. The manual already contains an appendi
>
> Another thing about testing for 1.0.
>
> *Before* reporting bugs on 1.0, check that it works in SVN trunk.
>
> We aren't fixing bugs in 1.0, we're backporting fixes from
> SVN HEAD, maybe.
>
currently we have a 1.0 branch - until we finally tag a 1.0 release any
major bugs will be merged
> For 1.0, do we want to consider removing support for all the old syntaxes?
Yes! :-)
Another thing about testing for 1.0.
*Before* reporting bugs on 1.0, check that it works in SVN trunk.
We aren't fixing bugs in 1.0, we're backporting fixes from SVN HEAD, maybe.
--
Øyvind Harboe
http://www.
On Nov 24, 2008, at 3:24 AM, Spen wrote:
Hi,
I have created a release 1.0 branch:
svn://svn.berlios.de/svnroot/repos/openocd/branches/openocd_1_0_branch
if no major issues are found after say 1 month then we will tag a
release.
I can test the st/pic32 targets, if anyone has any free time t
Spen wrote:
> I have created a release 1.0 branch:
> svn://svn.berlios.de/svnroot/repos/openocd/branches/openocd_1_0_branch
> if no major issues are found after say 1 month then we will tag a release.
>
> I can test the st/pic32 targets, if anyone has any free time to check other
> targets that wou
Hi,
I have created a release 1.0 branch:
svn://svn.berlios.de/svnroot/repos/openocd/branches/openocd_1_0_branch
if no major issues are found after say 1 month then we will tag a release.
I can test the st/pic32 targets, if anyone has any free time to check other
targets that would be good.
Like i
29 matches
Mail list logo
