Re: virtualbox, backports, and fasttrack

[Pirate Praveen]

On 2019, ഡിസംബർ 2 6:08:13 AM IST, Jonathan Nieder  wrote:
>Hi,
>
>Pirate Praveen wrote:
>> On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz  wrote:
>>> Hi Lucaus,
>
 I hope that  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.

Re: virtualbox, backports, and fasttrack

[Jonathan Nieder]

Hi,

Pirate Praveen wrote:
> On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz  wrote:
>> Hi Lucaus,

>>> I hope that  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.)

> 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?

What are the criteria for being able to upload?  Is there a keyring
for developers who can upload to fasttrack?

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".)

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?  Can packages in fasttrack depend on
other packages in fasttrack, or only on packages in stable +
stable-backports?

Is there a mailing list for day-to-day discussion?

> Secutity issues are fixed by uploading new upstream releases.

What architectures are supported?  Are there autobuilders available?
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?  Is there an announcement list for uploads addressing
security issues?

Thanks,
Jonathan

Re: virtualbox, backports, and fasttrack

[Pirate Praveen]

On Wed, Oct 2, 2019 at 23:23, Bernd Zeimetz  wrote:

Hi Lucaus,


 Given that backports are a no-go, I hope that
  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.



- 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.


buster-backports suite:

We also allow dependencies of packages in fasttrack to be updated from 
experimental during special cases like freeze, transitions or for new 
security update (backport-new can take some time). In the normal 
course, they should be uploaded to official backports since they 
qualify for backports.


You can see the original proposal that explains things in detail.

https://lists.debian.org/debian-devel/2018/12/msg00297.html

- how do you want to avoid that this service becomes a mess? who 
removes

packages when, who makes sure maintainers actually take care of what
they upload? how are bugs being reported? What about security issues?



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).


Secutity issues are fixed by uploading new upstream releases.


Thanks,

Bernd


--
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.de 
http://www.debian.org 

 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: virtualbox, backports, and fasttrack

[Lucas Nussbaum]

Hi,

On 02/10/19 at 23:23 +0200, Bernd Zeimetz wrote:
> > Given that backports are a no-go, I hope that
> > http://fasttrack.debian.net/ will make quick progress and turn into an
> > official service soon.
> 
> basically a good idea, but
> - what are your requirements for packages that are being uploaded there?
> - how do you want to avoid that this service becomes a mess? who removes
> packages when, who makes sure maintainers actually take care of what
> they upload? how are bugs being reported? What about security issues?

To clarify: I'm not involved in fasttrack myself.

Lucas

Re: virtualbox, backports, and fasttrack

[Dmitry Smirnov]

Just few answers derived from common sense:

On Thursday, 3 October 2019 7:23:41 AM AEST Bernd Zeimetz wrote:
> - how do you want to avoid that this service becomes a mess?

We don't have a perfect solution for this problem in the official backports 
either. Sometimes there is just enough time, or other circumstances.
This is not a problem with large enough pool of active maintainers.


> who removes
> packages when, who makes sure maintainers actually take care of what
> they upload?

I would assume that DDs are qualified enough to be trusted what they upload?


> how are bugs being reported?

IMHO all bugs should be reported to our bug tracking system.


> What about security issues?

Does not matter. Sometimes lack of security support is precisely the reason 
why you want a package in fasttrack/backports.
For example, it is not uncommon for a package without meaningful security 
support upstream (e.g. Oracle) to be marked as "unfit for release" (by a bug 
with severity "serious"). Such packages will not migrate to "testing" and 
therefore can not be introduced to backports.
Maintaining such packages only in "unstable" makes little sense if there is 
no channel to provide them to users of current release.

I have misfortune of maintaining one such package: "mysql-workbench" and 
because I don't run Sid on my desktop I have to maintain unofficial backport 
anyway, just to be able to run the package. Hardly anyone can use a package 
that exist only in "unstable" so no wonder that users asked me to backport 
MySQL Workbench many times but I can not do that under current policy.

Another case could be almost the opposite -- when there is a security support 
but only for a short time when release cycle is rapid. GitLab is one such 
example, arguably not suitable for "stable" but necessary in fasttrack/
backports in order to be usable.

-- 
Cheers,
 Dmitry Smirnov

---

Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill


signature.asc
Description: This is a digitally signed message part.

Re: virtualbox, backports, and fasttrack

[Bernd Zeimetz]

Hi Lucaus,

> Given that backports are a no-go, I hope that
> http://fasttrack.debian.net/ will make quick progress and turn into an
> official service soon.

basically a good idea, but
- what are your requirements for packages that are being uploaded there?
- how do you want to avoid that this service becomes a mess? who removes
packages when, who makes sure maintainers actually take care of what
they upload? how are bugs being reported? What about security issues?

Thanks,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F