[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Re: Debian as living system

> > - We must improve and doesn't trash tests made in unstable:
> Why do we need to do that? A package which is clearly  improved or outdated
> does not need any testing.

Because, for example if i release three revision of a package in a month and i upload in unstable,
it is in a good status with no rc bugs, still must waiting two days for entering in testing, but i override
it uploading the new upstream version package then i must restart to testing the new upstream version in unstable without
having the old version entering in testing and probably maintaing an old one in testing untill the new upstream packaged
version is in a good shape and is old enought for land in testing.

> > - We must to use this same policy adding the normal unstable to testing
> > policy from testing to stable using a "stable waiting time" that could
> > be fixed to 30/60/90 days according to the priority (and eventually
> > section) of the packages.
> We dont change stable, this does not work you can only test the system as a
> whole.

Actually we doesn't change stable, but with the new infrastructure we can start.
I think that a system could be tested with a group of packages an its dependencies.
Big infrastructural changes (as a new install system) could be done of the stable system and land in stable when done.
Stable, testing and unstable could has different infrastructures and cd snapshot so that infrastructural changes land 
one by one in stable only when ready.

> > So we cannot have entering two different packages in stable less than 30
> > days
> sure we can.
This was an assumption of not to have too many frequent software changes in stable.
Probably if i have Inkscape installed and i'm running stable also if upstream release a new version every week
in the optimistic use cases i cannot must to use a new version of it less then 30/60/90 days following the testing to 
stable policy.

> > So we will have a very slowly stable release moving without the needs of
> > formal freeze and releases: a "living" system.
> Kind of cancer?
Not only to do thinks slowly with little changes without having a total different os and applications after one/two 
or three year of upstreams work impact to the distro users.
> > Official cd are daily (or weekly) rebuilded snapshots of the stable
> > distro or net installable cd images.
> And you cant do QA nur security update, create additional mirror load on
> stable and kill cd distributors.
Security updates are done through security/updates if u done daily cd rebuild u have the last security updates 
on the cd every day if u want to do a new install. After installing a day X snapshot you can follow
day x+n security updates through security.debian.org.
> I think you can do that for non-core packages like bsd packages, but the
> base system must be released as a whole.
For base system we could create something like a group or branching levels using some dependencies info 
so it can land to stable only as a whole. 


Reply to: