Re: Chosing release goals for slink
James Troup <james@nocrew.org> writes:
> > * Developer controlled automatic archive maintenance (eg removal of
> > packages automatically after GPG signed email with list of
> > packages to delete)
>
> I think this idea, as presented here, is very bad. Even with sanity
> checks and more thought, I'm not impressed by the idea and don't think
> it would be worth the effort to implement. We now have people helping
> Guy, and the ftp site should be much less of a problem than it has
> been recently.
I think your paranoia is unjustified, James. I should elaborate to say
my suggestion would only apply to packages maintained by the person
sending and signing the email. If I can upload packages to Debian as a
maintainer, shouldn't I be able to remove them, by a similar process?
You say we now have people helping Guy, who are they? Yourself? I hope
you can get net access soon to keep helping him, but in the past you have
been reluctant to do anything to the archive for fear of hosing it.
> > * Autocompilation support
>
> Eh? That sounds suspiciously like meaningless buzz-word talk. What's
> ``autocompilation support'' please?
It means even more automation than your debbuild script.. such as a
server automatically getting packages from a quinn diff check, compiling
them, and sending the results, if bad, straight to the maintainer, ccing
to an arch specific person.
> > That's all that comes to mind right now, any other suggestions?
>
> That we release slink before 2038 or so? These goals (the desirable
> ones, that is) aren't viable if we want slink to not be the disaster
> hamm is.
Actually I agree these shouldn't be slink release goals, but rather
issues we should focus on when hamm is released. And I don't think hamm
is a disaster, in terms of quality.
Martin.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: