Udev in b6_0: to be or not to be

Matthew Burgess matthew at linuxfromscratch.org
Tue Jun 1 12:19:34 PDT 2004

On Tue, 1 Jun 2004 14:06:54 -0500
"Larry Lawrence" <larry at linuxfromscratch.org> wrote:

> "Matthew Burgess" <matthew at linuxfromscratch.org> wrote in message
> news:20040601194613.3b517a31.matthew at linuxfromscratch.org...
> >>The differences of opinion really do
> > > come down to:
> > >
> > > Do you put Unstable into Test when it becomes stable
> >
> > Yes.
> >
> > > OR Do you pull Unstable from Test when it proves unstable.
> >
> > No.
> >
> > > The community prefers the latter, something I will probably never
> > > understand.
> >
> > I think the confusion regarding our approach has been caused by the
> > now defunct b6_0 branch.  I thought this was already covered in the
> > cvs-structure document?  Maybe it wasn't clear enough?  I'd like to
> > see unstable tagged at particular points in time when it is deemed
> > stable enough to receive wider testing.  *If* that wider testing
> > proves the instability of a particular feature, then of course,
> > corrective actions will need to be taken.  These may be simply
> > providing patches(as in this udev/hotplug issue), or backing out the
> > feature entirely, if luck has dictated that the only boxes that will
> > support the feature happen to be HEAD maintainers machines.
> > Cheers,
> >
> > Matt.
> I am glad we agree in theory, unfortunatly, your paragraph exemplifies
> the latter, IMO.

What would you rather us do then Larry?  Simply stop all development
like has been done in the past?  I'm confused.  We *need* constant
development in order to maintain inertia in the project and prevent the
kind of stagnation that has occurred in the past.  Now you're saying,
steadfastly, that this can't happen because we shouldn't be able to pull
things out of the testing branch if it is deemed insufficiently stable? 
How else are we to get the developments from HEAD available for a wider
range of testers, while still allowing HEAD to progress?

Thanks for any constructive comments,


More information about the lfs-dev mailing list