Retiring from uClibc development

Mon Apr 3 10:39:17 UTC 2006

Steven,

your dev process looks a lot like IBM/Rational's UCM process, with which
I've had a very good experience.

UCM actually goes a step further: developers ALWAYS work in a developer
branch (called developer stream).
And each feature/bug fix gets promoted (merged) to the main branch only
after it has passed a pre-defined set of QA checks, e.g. asking the mailing
list to test and review.
While a feature is pending review, the developer carries on working on a
second development branch.

Would it be feasible to publish this on the uClibs website as THE dev
process for uClibc contributors?

-----Original Message-----
From: uclibc-bounces at uclibc.org [mailto:uclibc-bounces at uclibc.org] On Behalf
Of Steven J. Hill
Sent: 03 April 2006 03:02
To: Rob Landley
Cc: uclibc at uclibc.org
Subject: Re: Retiring from uClibc development

Rob Landley wrote:
> 
>>Also realize that I haven't stopped my own development for uClibc.  It 
>>just takes place in my own tree.  When we release something linked 
>>with it, the patches will be made available and integrated.  But I 
>>can't ethicly (at least in my code of ethics) justify handing out bug 
>>fixes to my employer's competitors until necessary.
> 
> Disturbing trend.
>
Careful of your hypocrisy my friend. I know d*** well how things work at
TimeSys. They have patches that are not released to the general community
because customers have requested that they do not or that they are delayed.
It is no different than what I am doing for NPTL or what Manuel is doing in
his private tree. If a customer is paying, like it or not, you are ethicly
bound to fulfill their wishes.

> Query: is there going to be a 0.9.29 release?  If the objection is 
> that psm was destabilizing a tree that's trying to be cleaned up for a 
> release, that's an understandable objection.  If the objection is that 
> uClibc is expected to have every daily snapshot work because it no 
> longer cuts releases (ala buildroot), and using the last released 
> version is no longer really a viable option anymore, that's not really a
very appealing model.
> 
Let me spell this out for everyone, for the....oh...I don't know, about the
10th time I think. I do not expect buildroot to be buildable and correct
every single day of the week. That is unrealistic. What I do expect is that
if someone wants to commit code and the code are large feature changes or
touches a lot of files, that they do it in their own branch first. Next,
they should ask people on the list to check out their branch and test it
before committing any code. Once approved, it can be put to the trunk. What
should have happened was that Peter should have been given his own branch to
start with and been asked to work there for a while to prove himself. That
is the whole problem and why this thread has gone on. We want more
developers for uClibc. We do not want sloppy developers running amok in the
main trunk. We want people to follow a process of working in a branch,
testing and then committing. buildroot should build completely with your new
feature addition or touching of a ton of files. That is not too much to ask.
If you cannot abide by those rules, then you post patches to the mailing
list and you should not have commit access. Hopefully this should clear
things up. I do not how to make it any simpler.

-Steve
_______________________________________________
uClibc mailing list
uClibc at uclibc.org
http://busybox.net/cgi-bin/mailman/listinfo/uclibc

 ###  OXFORD INSTRUMENTS   http://www.oxford-instruments.com/  ### 

Unless stated above to be non-confidential, this E-mail and any 
attachments are private and confidential and are for the addressee 
only and may not be used, copied or disclosed save to the addressee.
If you have received this E-mail in error please notify us upon receipt 
and delete it from your records. Internet communications are not secure 
and Oxford Instruments is not responsible for their abuse by third 
parties nor for any alteration or corruption in transmission. 