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

Re: Serializing transitions



Raphael Hertzog <hertzog@debian.org> writes:
> To resolve the problems I suggest to serialize transitions in sid.

This was already discussed a few times.

> First the archive should block package uploads to sid that would be
> starting a new transition (defining this in more details is left for
> later).

No, this can't be defined later. It's a central part. Would any new
binary lead to a dedicated overlay? How do you determine when this is
needed and when not?

> Instead transitions should be managed in dedicated repositories
> that are overlays over sid. We would have tools (command-line, web
> interface, etc.) to manage the transition in that repository.

What would these tools do? Why don't they exist currently?

> We could tell which packages need to be rebuilt (bin-NMU, sourceful upload)
> and the system would automatically rebuild the package (and it
> would also be automatically rebuilt every time that the package is updated
> in sid).

How do you determine the set of packages that need to be transitioned?
Are these provided by the uploader? Can they be computed?

> Some web interface would display the status of the transition,
> displaying which package/arch have been built or not, and which one failed
> to build from source.

You mean like the existing pages on buildd.debian.org? You just need to
feed them the list of affected packages to get that.

> Multiple transitions will still end up mixed in sid if you push them
> before packages have migrated to testing but they are all already
> completed and you only have to deal with RC bugs and delays to ensure
> package can migrate to testing.

"Only" deal with RC bugs? This touches an interesting point you didn't
cover at all: How are bugs reported? How can these bugs be tracked if
the same source version is fine in sid, but breaks in an overlay - or,
worse, breaks in one overlay, but not in another?

> Dealing with transitions that way make it clear that the maintainer has to
> take the responsibility to prepare/complete the transition if he wants to
> see his package in sid and in the next release.

I assumed that this was already the case. I also don't see how enforcing
such a technical system would solve this problem?

> Preparing the transition in experimental is not always done and takes
> much more energy than such a system would take.

Why, actually?

> How does that sound to you?

Trying to improve the handling of transitions is a good thing. I don't
consider your mail to be a proposal, as it doesn't cover any of the
actual technical problems. 

Another interesting question: Do you plan to implement this? Do you
expect someone else to do it? Why weren't the "tools" you hinted at
never implemented for transition handling in sid?

And, seeing the not ending discussions about your handling of the new
dpkg source formats: Do you think that such a change could be
implemented without pissing off so many people?

Marc

Attachment: pgpvQuO5S2PPy.pgp
Description: PGP signature


Reply to: