On 11/07/2013 01:50 AM, Thomas Petazzoni wrote:
> Dear czankel,
>
> On Wed, 06 Nov 2013 12:05:02 -0800, czankel wrote:
>
>>> I've seen both the ARC port (from Vineet) and the Xtensa NPTL support
>>> (from Chris), but I don't think the uClibc community should wait
>>> indefinitely for more and more features to show up and get merged
>>> before doing a release. Let's release 0.9.34 with the current feature
>>> set, and plan a 0.9.35 release not too late after that with the ARC
>>> port and Xtensa NPTL support added, for example.
>> Given that NPTL support for Xtensa is ready to go (Baruch did actually 
>> also a lot of work), and ARC support is also ready, 

But it still needs some review and so far I've got none.

>> it would be great to 
>> get them in before any lengthy RC-cycle, where we might want to hold off 
>> adding large features to the master until the final 0.9.34 release.
>>
>> So, I guess it depends on what state uClibc is in. If it's stable, 
>> couldn't we then just release 0.9.34 and open it up immediately for 
>> 0.9.35? If it needs some time for testing and possible bug fixing, we 
>> should probably add all pending (larger) features, and have a longer RC 
>> cycle.
> It's just that I think feature-based releases is a never-ending story.
> The current feature set hasn't moved too much for a while, so it would
> be good to make a release out of it, and as soon as 0.9.34-rc1 is out,
> re-open the tree to merge more features: stabilization of 0.9.34 and
> integration of additional features for 0.9.35 can take place in
> parallel.

I agree with Thomas. What matters in the end is that code is merged in mainline.
Build systems such a buildroot anyways allow tip snapshot for build so that 
should
be good enough.

-Vineet
_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc

Reply via email to