Re: Frozen distribution?

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:

    Anthony> --nFreZHaLTZJo0R7j Content-Type: text/plain;
    Anthony> charset=us-ascii Content-Disposition: inline
    Anthony> Content-Transfer-Encoding: quoted-printable


    Anthony> This is somewhat confused.

    Anthony> "testing" is maintained by a script, it is not uploaded
    Anthony> to directly. What you describe would be mostly sensibly
    Anthony> named:

    Anthony> 	stable testing frozen unstable

    Anthony> where stable is updated as it is now, testing is updated
    Anthony> from frozen instead of unstable by scripts, and both
    Anthony> frozen and unstable can be uploaded to directly. At
    Anthony> release, frozen is removed entirely, testing becomes the
    Anthony> new stable, and is also forked into a new testing which
    Anthony> is once again updated from unstable.

    Anthony> The problem with doing something like this is what I
    Anthony> described before: bugfix uploads need to go to both
    Anthony> frozen & unstable, which causes problems for the
    Anthony> autobuilders.

So, I really like this approach but understand that we probably cannot easily fix the autobuilders in time for woody.  I think it is a the best long-term strategy.

I am concerned about the proposal you sent out to
debian-devel-announce because I suspect that there will be more
packages changing once frozen than you really want to handle manually.
While I was not a developer during the potato freeze I di follow it as
a user and follow how often packages that were ideally frozen were
changing.

That seems like enough work that you want to have an automated way to
request a new package be pulled up into  the release.

If as I believe is the case, dealing with frozen unstable uploads and
autobuilders is not a reasonable option, I think your proposal sounds
reasonable.  However, I would ask you to establish a package in the
BTS for requests to move from unstable into testing after the package
was frozen.  If you don't need to use it much, that would be great.
However, I would rather have a tool that package maintainers can use
to check the status of their requests and to make sure that things are
being handled.  I don't thing that simply sending mail to someone has
adequate tracking/auditing characteristics and I think the BTS could
provide a good way of handling this.




    Anthony> And in truth, it doesn't seem much of a win over just
    Anthony> using

    Anthony> 	stable testing unstable experimental

    Anthony> in those roles. The only benefit it gets is that the few
    Anthony> people who fork their packages during the freeze don't
    Anthony> have to file a bug report to get their package moved into
    Anthony> unstable from experimental 

It also makes it significantly harder for people to follow your forked
package.  I'm not willing to put experimental into apt sources and
dist-upgrade to it, but I will run unstable.  I may be underestimating
the value of being able to get people to test your forked code  soon.
I don't know how  it tends to be useful in Debian, but in other
software packages  having a mainline branch that is always  a
reasonable place to commit working, but possibly unstable code  is useful.