Re: virtualbox, backports, and fasttrack
On 2019, ഡിസംബർ 2 6:08:13 AM IST, Jonathan Nieder <jrnieder@gmail.com> wrote:
>Hi,
>
>Pirate Praveen wrote:
>> On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz <bernd@bzed.de> wrote:
>>> Hi Lucaus,
>
>>>> I hope that <http://fasttrack.debian.net/> will make quick
>>>> progress and turn into an official service soon.
>>>
>>> basically a good idea, but
>>
>> I'm part of the Fast Track team and I'll try to answer your
>questions.
>
>Thanks much for this. I'm excited to see the idea moving forward.
>
>>> - what are your requirements for packages that are being uploaded
>there?
>>
>> buster-fasttrack suite:
>>
>> If a package cannot be part of a stable release because we cannot
>provide
>> security updates for the entire stable lifecylce then that package
>cannot be
>> in testing or backports. Those packages get security updates along
>with new
>> upstream versions and such software can be in FastTrack.
>
>Does the package need to be in unstable or experimental to be in
>fasttrack? Or can I upload a package to fasttrack without being in
>Debian at all?
>
>(Asking in order to better understand how this works. My first guess
>would have been "has to be in unstable or experimental". Looking at
>the mailing list post you linked to, it's "has to be in unstable",
>which seems reasonable enough, I suppose.)
In general, the package has to be in unstable, we allow packages from experimental as exceptions, when a new version cannot be in unstable because it is blocked by transitions or freeze. We also allow packages in fast track temporarily when packages need to clear backports-new (usually when a package in fast track has a security release and we want to push it to users as soon as possible).
>
>> We have not really thought about removals yet (probably we have not
>reached
>> that stage yet as we only have one package there ie, gitlab and it is
>> maintained well.). But we could follow the same rules as testing and
>> backports (except for the meta rc bug that is present only to prevent
>> testing migration).
>
>Who should I contact if I need to remove a package? E.g. is there a
>request tracker queue or debbugs virtual package for this?
We use salsa issues as mentioned in the website.
https://salsa.debian.org/fasttrack-team/support/issues We have not been monitoring it closely, but we should start monitoring it closely now as I can see a new issue for virtual box there.
>What are the criteria for being able to upload? Is there a keyring
>for developers who can upload to fasttrack?
For now, its fast track team members who can upload. We can give other DDs upload access on request. Use the issue tracker.
>Where should users report bugs? (My preference would be "all packages
>in fasttrack are uploaded by members of the packaging team for the
>corresponding package in unstable, and bug reports are accepted in the
>ordinary bug tracking system".)
I prefer that too. It is up to each maintainer how they want it.
>What user-facing recommendations are provided? If a user wants to
>stop using fasttrack, can they upgrade to unstable and remove
>fasttrack from sources.list?
It is untested, again up to each maintainer. For gitlab, I have to use experimental as many dependency updates are blocked by pending transitions.
> Can packages in fasttrack depend on
>other packages in fasttrack, or only on packages in stable +
>stable-backports?
It can depend on other packages in fast track.
>Is there a mailing list for day-to-day discussion?
We use irc/matrix group for this, but if a mailing list is preferred, we could probably create one.
#debian-fasttrack on oftc is used. It is bridged to Matrix group #debian-fasttrack:poddery.com
>> Secutity issues are fixed by uploading new upstream releases.
>
>What architectures are supported? Are there autobuilders available?
It is on our to do list. Currently amd64 and binary uploads only. More could be added if there is interest.
>Is there a way to build releases with an embargoed security fix in
>secret? (It's fine if the answer is "no".) Is there a way to upload
>binary packages to avoid waiting for autobuilders to act on a security
>release?
For now its binary included upload only.
> Is there an announcement list for uploads addressing
>security issues?
Not yet. We could start one. For now gitlab new releases are announced via wiki.debian.org/gitlab
>Thanks,
>Jonathan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Reply to: