Re: Confusing our users - who is supporting LTS?

2018-11-06 Thread Raphael Hertzog
On Sun, 28 Oct 2018, Wouter Verhelst wrote:
> On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > Debian can't afford to pay developers in general, and previous
> > proposals to pay specific developers were not well received.
> 
> That was over a decade ago. The circumstances at the time were also
> different.

That's true, but it's not clear that the result would be different.

And while I have certainly no objection in going down that route,
I also don't plan to actively push into this direction given that the
current situation seems to be working relatively well. I don't want to
break what's working given the time and energy I already invested in this
project.

I know that Luca is not 100% satisfied with the current situation but
while I acknowledge his message, I have not much to propose. Last time
I tried to bring LTS even closer to Debian (in terms of getting LTS
sponsors thanked on www.debian.org, etc.), the discussions quickly stalled.

If anybody wants to drive a change in the way the LTS funding works, I
will be happy to participate in the discussion/project but it needs to be
well prepared because handling so many sponsors with all the
invoicing/payments quirks is a non-trivial amount of work and moving
away from Freexian to a trusted organization is going to be supplementary
work. The scheme has been designed so that it can fund itself (the share
that Freexian is taking funds that part of administrative work) so it's
possible and it should sustainable in the long run once the initial cost
of moving has been paid.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/



Re: Confusing our users - who is supporting LTS?

2018-11-03 Thread Jonathan Dowland

On Fri, Nov 02, 2018 at 09:15:32AM -0300, Antonio Terceiro wrote:

It was said in this same thread that Freexian is already not the only
company paying people to do LTS work. See



Thanks, that's a good point because it brings up something that's
important to distinguish.

Freexian as a business seeks money from customers/investors specifically
to work on Debian LTS. The other LTS contributors that Ben mentioned may
not work for a company that specifically seeks funding for that purpose,
but who fund LTS work because it's considered valuable to their goals.

In the context of Wouter's objection, I think the former category of
company is what's important.




--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.



Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Adam Borowski
On Fri, Nov 02, 2018 at 12:45:17PM +0100, Andrej Shadura wrote:
> > I disagree, in both cases.
> >
> > Debian should not pay anything through an organization that has race, gender
> > and nationality discrimination as its core purpose.  Accepting code produced
> > this way is acceptable (as would be contributions from anyone), but
> > providing monetary support for such ideology is not something I can speak of
> > positively.
> 
> You can extend this logic and claim it’s fundamentally bad to help
> people in need, since that is discrimination on the fact of being in
> need.

...?  I don't see what not tolerating race discrimination has to do with
being against helping people.  Am I missing something?

Both helping people in need, and not promoting any race/etc over another are
pretty basic rules.  Both are important requirements for the society.  The
latter is not included (yet?) in any document of Debian proper (other for
depriving someone of the right to run a piece of software), but at least
DebConf's code of conduct says it clearly:

The following is a list of examples of behavior that is deemed highly
inappropriate and will not be tolerated at DebConf:
[...]
* unwarranted exclusion from conference or related events based on age,
  gender, sexual orientation, disability, physical appearance, body size,
  race, religion;

So I don't understand why you disagree so strongly with my want to have
similar rule for Debian proper.

> In other words, helping someone who’s in a worst position
> because of been previously and currently being discriminated against,
> while being sort of discriminative (e.g. helping that person and not
> someone who’s not been discriminated against), it fundamentally a good
> thing, as it helps people and brings things into balance.

This paragraph, can't parse.

> Your logic is flawed, just accept it already.

Can't argue with such a statement...


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on
⢿⡄⠘⠷⠚⠋⠀ the maternity ward.
⠈⠳⣄



Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Antonio Terceiro
On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote:
> On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> > > I meant that we would say that stable is supported by the security team.
> > > And instead of saying that Jessie was supported by the LTS team, we
> > > would say supported by Freexian.
> > 
> > I would object to that, on the grounds that even though Freexian is
> > currently the only company paying people to do LTS support, we should
> > not encourage the idea that they have a monopoly on doing that.
> 
> In my view, that is a situation we could address at the time that we had
> more than one company doing LTS work. Until that time, I don't think
> it's a problem. It's consistent with our listing of consultants, and
> addresses the problems of the official-ness-or-not of LTS that are why
> this thread started.
> 
> > If some other company decides that they are not happy with Freexian,
> > then they are currently able to just start their own competing project
> > and do things differently. This is a good thing.
> 
> They would still be able to do so even if we were listing Freexian as
> being the only entity supporting LTS (which is a statement of current
> fact after all): I don't think the hypothetical competing company would
> be too bashful to ask us to update the website. And we could pre-empt
> the situation by making a clear statement as to the project's position
> on listing Freexian (essentially codifying what I'm writing here,
> somewhere)

It was said in this same thread that Freexian is already not the only
company paying people to do LTS work. See



signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Andrej Shadura
On Fri, 2 Nov 2018 at 10:15, Adam Borowski  wrote:
>
> On Fri, Nov 02, 2018 at 11:36:11AM +0800, Paul Wise wrote:
> > On Thu, Nov 1, 2018 at 2:18 AM Holger Levsen wrote:
> >
> > > ... and that's what I meant when I said not much has changed: what was
> > > bad about about the idea of Debian paying people I still think is bad
> > > today. And I don't think I'm alone here.
> >
> > I also agree with Debian not paying members for their contributions.
> >
> > > Money is a cause of friction (at best) and as such I firmly believe it's
> > > better we keep money/paying contributors out of Debian *itself*.
> >
> > I note that we are paying Outreachy interns using Debian funds. I
> > personally do not have a problem with this as long as it remains a
> > mechanism for growing the community rather than paying insiders.
>
> I disagree, in both cases.
>
> Debian should not pay anything through an organization that has race, gender
> and nationality discrimination as its core purpose.  Accepting code produced
> this way is acceptable (as would be contributions from anyone), but
> providing monetary support for such ideology is not something I can speak of
> positively.
>
> On the other hand, using some funds for an activity vital for a good part of
> the users which doesn't find enough volunteers, while controversial, is not
> fundamentally bad.

You can extend this logic and claim it’s fundamentally bad to help
people in need, since that is discrimination on the fact of being in
need. In other words, helping someone who’s in a worst position
because of been previously and currently being discriminated against,
while being sort of discriminative (e.g. helping that person and not
someone who’s not been discriminated against), it fundamentally a good
thing, as it helps people and brings things into balance.

Your logic is flawed, just accept it already.

-- 
Cheers,
  Andrej



Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Wouter Verhelst
On Fri, Nov 02, 2018 at 08:58:47AM +, Jonathan Dowland wrote:
> On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> > > I meant that we would say that stable is supported by the security team.
> > > And instead of saying that Jessie was supported by the LTS team, we
> > > would say supported by Freexian.
> > 
> > I would object to that, on the grounds that even though Freexian is
> > currently the only company paying people to do LTS support, we should
> > not encourage the idea that they have a monopoly on doing that.
> 
> In my view, that is a situation we could address at the time that we had
> more than one company doing LTS work.

Yes, but then there's the important matter of wording.

A hyptothetical "Extended Debian support by Freexian" is a product of
Freexian that just happens to use Debian infrastructure.

In contrast, a just as hypothetical "Extended Debian support by the ED
team (financially supported by Freexian)" is a product of Debian that
just happens to be supported by Freexian.

I would be fine with something along the lines of the latter, but not
the former.

(the exact wording that we end up deciding on may be different, but you
get the point).

> Until that time, I don't think it's a problem.

I think that if we end up writing something which "assigns" LTS to
Freexian, then the possibility that some other company doing LTS work
diminishes. That is not something I want to see happening.

[...]
> > If some other company decides that they are not happy with Freexian,
> > then they are currently able to just start their own competing project
> > and do things differently. This is a good thing.
> 
> They would still be able to do so even if we were listing Freexian as
> being the only entity supporting LTS (which is a statement of current
> fact after all): I don't think the hypothetical competing company would
> be too bashful to ask us to update the website. And we could pre-empt
> the situation by making a clear statement as to the project's position
> on listing Freexian (essentially codifying what I'm writing here,
> somewhere)

Yes, that'd definitely be necessary.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Adam Borowski
On Fri, Nov 02, 2018 at 11:36:11AM +0800, Paul Wise wrote:
> On Thu, Nov 1, 2018 at 2:18 AM Holger Levsen wrote:
> 
> > ... and that's what I meant when I said not much has changed: what was
> > bad about about the idea of Debian paying people I still think is bad
> > today. And I don't think I'm alone here.
> 
> I also agree with Debian not paying members for their contributions.
> 
> > Money is a cause of friction (at best) and as such I firmly believe it's
> > better we keep money/paying contributors out of Debian *itself*.
> 
> I note that we are paying Outreachy interns using Debian funds. I
> personally do not have a problem with this as long as it remains a
> mechanism for growing the community rather than paying insiders.

I disagree, in both cases.

Debian should not pay anything through an organization that has race, gender
and nationality discrimination as its core purpose.  Accepting code produced
this way is acceptable (as would be contributions from anyone), but
providing monetary support for such ideology is not something I can speak of
positively.

On the other hand, using some funds for an activity vital for a good part of
the users which doesn't find enough volunteers, while controversial, is not
fundamentally bad.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).



Re: Confusing our users - who is supporting LTS?

2018-11-02 Thread Jonathan Dowland

On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:

On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote:

I meant that we would say that stable is supported by the security team.
And instead of saying that Jessie was supported by the LTS team, we
would say supported by Freexian.


I would object to that, on the grounds that even though Freexian is
currently the only company paying people to do LTS support, we should
not encourage the idea that they have a monopoly on doing that.


In my view, that is a situation we could address at the time that we had
more than one company doing LTS work. Until that time, I don't think
it's a problem. It's consistent with our listing of consultants, and
addresses the problems of the official-ness-or-not of LTS that are why
this thread started.


If some other company decides that they are not happy with Freexian,
then they are currently able to just start their own competing project
and do things differently. This is a good thing.


They would still be able to do so even if we were listing Freexian as
being the only entity supporting LTS (which is a statement of current
fact after all): I don't think the hypothetical competing company would
be too bashful to ask us to update the website. And we could pre-empt
the situation by making a clear statement as to the project's position
on listing Freexian (essentially codifying what I'm writing here,
somewhere)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.



Re: Confusing our users - who is supporting LTS?

2018-11-01 Thread Paul Wise
On Thu, Nov 1, 2018 at 2:18 AM Holger Levsen wrote:

> ... and that's what I meant when I said not much has changed: what was
> bad about about the idea of Debian paying people I still think is bad
> today. And I don't think I'm alone here.

I also agree with Debian not paying members for their contributions.

> Money is a cause of friction (at best) and as such I firmly believe it's
> better we keep money/paying contributors out of Debian *itself*.

I note that we are paying Outreachy interns using Debian funds. I
personally do not have a problem with this as long as it remains a
mechanism for growing the community rather than paying insiders.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Confusing our users - who is supporting LTS?

2018-10-31 Thread Holger Levsen
On Wed, Oct 31, 2018 at 12:04:47PM +0100, Wouter Verhelst wrote:
> When I say "the circumstances were different", I mean that at the time,
> it was about paying people to do release management of testing, and that
> it was originally suggested by the DPL. In this case, it is about
> paying people to work on the exact opposite of the release train,

right.

> and it
> has no DPL involvement.

(Chris is involved in LTS, but I get what you meant.)

> I think it would be fine if Debian were to, occasionally, sponsor people
> to work on LTS, provided that it does not become a "LTS is only paid for
> by Debian" situation. Say, we could do a matching drive or something
> along those lines (as in, "Debian will match any sponsorship up to
> XYZ").

I don't think that would be fine...

> Of course you might reasonably disagree with that opinion, but "the
> circumstances are different" is a simple statement of fact ;-)

... and that's what I meant when I said not much has changed: what was
bad about about the idea of Debian paying people I still think is bad
today. And I don't think I'm alone here.

Money is a cause of friction (at best) and as such I firmly believe it's
better we keep money/paying contributors out of Debian *itself*.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-31 Thread Wouter Verhelst
On Mon, Oct 29, 2018 at 12:56:26PM +, Holger Levsen wrote:
> On Sun, Oct 28, 2018 at 04:31:38PM +0100, Wouter Verhelst wrote:
> > On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > > Debian can't afford to pay developers in general, and previous
> > > proposals to pay specific developers were not well received.
> > That was over a decade ago. The circumstances at the time were also
> > different.
> 
> I'm not sure that so much has changed. I really like that LTS is managed
> outside Debian, precisely because money is involved.

When I say "the circumstances were different", I mean that at the time,
it was about paying people to do release management of testing, and that
it was originally suggested by the DPL. In this case, it is about
paying people to work on the exact opposite of the release train, and it
has no DPL involvement.

I think it would be fine if Debian were to, occasionally, sponsor people
to work on LTS, provided that it does not become a "LTS is only paid for
by Debian" situation. Say, we could do a matching drive or something
along those lines (as in, "Debian will match any sponsorship up to
XYZ").

Of course you might reasonably disagree with that opinion, but "the
circumstances are different" is a simple statement of fact ;-)

> So I'm very happy that Raphael is 'the benevolent dictator of LTS' *and*
> that LTS is designed not to rely on Freexian.

Yes, the latter is very important, I agree -- that's why I was opposed
to mentioning Freexian as "doing LTS" on the website; even if that ends
up being the truth in practice, I think we should absolutely not
perpetuate the idea that that is the *only* possibility.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Confusing our users - who is supporting LTS?

2018-10-29 Thread Holger Levsen
On Sun, Oct 28, 2018 at 04:31:38PM +0100, Wouter Verhelst wrote:
> On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> > Debian can't afford to pay developers in general, and previous
> > proposals to pay specific developers were not well received.
> That was over a decade ago. The circumstances at the time were also
> different.

I'm not sure that so much has changed. I really like that LTS is managed
outside Debian, precisely because money is involved.

So I'm very happy that Raphael is 'the benevolent dictator of LTS' *and*
that LTS is designed not to rely on Freexian.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-28 Thread Wouter Verhelst
On Sun, Oct 28, 2018 at 01:14:13AM +, Ben Hutchings wrote:
> Debian can't afford to pay developers in general, and previous
> proposals to pay specific developers were not well received.

That was over a decade ago. The circumstances at the time were also
different.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Confusing our users - who is supporting LTS?

2018-10-27 Thread Ben Hutchings
On Sat, 2018-10-27 at 20:51 +, Luca Filipozzi wrote:
> On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> > On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo 
> > wrote:
> > > I meant that we would say that stable is supported by the security
> > > team.  And instead of saying that Jessie was supported by the LTS
> > > team, we would say supported by Freexian.
> > 
> > I would object to that, on the grounds that even though Freexian is
> > currently the only company paying people to do LTS support, we should
> > not encourage the idea that they have a monopoly on doing that.
> 
> I agree that more than one consultancy should/could provide resources
> for LTS.
> 
> I find it inappropriate that that we (Debian) publicize solicitation of
> donations to Freexian on debian.org websites [1] and, further, that we
> the advertise their 'Extended LTS' commercial offering [2].
> 
> [1]: https://wiki.debian.org/LTS/Funding
> [2]: https://wiki.debian.org/LTS/Extended

Debian has long maintained references to consultants (like the paid LTS
work) and commercial derivatives (like the ELTS) and I don't think
that's inherently problematic.

But the wording here could certainly be improved to make it clearer
that Debian has no special relationship with Freexian.

> > For the avoidance of doubt, I am not saying that Freexian is doing a
> > bad job, or that they should be replaced, or anything of the sorts.
> 
> Nor am I, but I do not find the lack of distinction between Debian and
> Freexian to be appropriate.
> 
> One way is for the funding for Debian LTS to flow through Debian's
> Trusted Organizations, complete with the restrictions that might come
> with that.

Debian can't afford to pay developers in general, and previous
proposals to pay specific developers were not well received.  So, I
don't this happening.

Ben.

> Another way is for Debian websites to not solicit for donations or to
> advertise for their commercial offering (my preference).

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.




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


Re: Confusing our users - who is supporting LTS?

2018-10-27 Thread Luca Filipozzi
On Sat, Oct 27, 2018 at 09:41:43AM +0200, Wouter Verhelst wrote:
> On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote:
> > I meant that we would say that stable is supported by the security
> > team.  And instead of saying that Jessie was supported by the LTS
> > team, we would say supported by Freexian.
> 
> I would object to that, on the grounds that even though Freexian is
> currently the only company paying people to do LTS support, we should
> not encourage the idea that they have a monopoly on doing that.

I agree that more than one consultancy should/could provide resources
for LTS.

I find it inappropriate that that we (Debian) publicize solicitation of
donations to Freexian on debian.org websites [1] and, further, that we
the advertise their 'Extended LTS' commercial offering [2].

[1]: https://wiki.debian.org/LTS/Funding
[2]: https://wiki.debian.org/LTS/Extended

> For the avoidance of doubt, I am not saying that Freexian is doing a
> bad job, or that they should be replaced, or anything of the sorts.

Nor am I, but I do not find the lack of distinction between Debian and
Freexian to be appropriate.

One way is for the funding for Debian LTS to flow through Debian's
Trusted Organizations, complete with the restrictions that might come
with that.

Another way is for Debian websites to not solicit for donations or to
advertise for their commercial offering (my preference).

Luca

-- 
Luca Filipozzi



Re: Confusing our users - who is supporting LTS?

2018-10-27 Thread Wouter Verhelst
On Fri, Oct 26, 2018 at 01:02:57PM -0300, Thadeu Lima de Souza Cascardo wrote:
> I meant that we would say that stable is supported by the security team.
> And instead of saying that Jessie was supported by the LTS team, we
> would say supported by Freexian.

I would object to that, on the grounds that even though Freexian is
currently the only company paying people to do LTS support, we should
not encourage the idea that they have a monopoly on doing that.

If some other company decides that they are not happy with Freexian,
then they are currently able to just start their own competing project
and do things differently. This is a good thing.

For the avoidance of doubt, I am not saying that Freexian is doing a bad
job, or that they should be replaced, or anything of the sorts.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard



Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Jonathan Dowland

My brief 2p - I hope we can improve the interaction and experience of
LTS for the whole project: although I don't use (yet) or contribute
(yet) to the LTS effort, I think it's a *great* idea and a real benefit
to Debian in the world. I'm glad some friends are able to support
themselves by working on Debian.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.



Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Ben Hutchings
On Fri, 2018-10-26 at 13:02 -0300, Thadeu Lima de Souza Cascardo wrote:
> On Fri, Oct 26, 2018 at 11:05:18AM -0400, Antoine Beaupré wrote:
> > On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote:
[...]
> > > 2) Say "supported by Security team" versus "supported by Freexian",
> > > instead of just saying "supported by LTS"?
> > 
> > Hm... I'm not sure what that refers to or what you're proposing, but LTS
> > releases are *not* supported by the security team, but by the LTS team.
> > 
> 
> I meant that we would say that stable is supported by the security team.
> And instead of saying that Jessie was supported by the LTS team, we
> would say supported by Freexian. The table at
> https://wiki.debian.org/LTS doesn't even say "supported by LTS team",
> but "supported by LTS", which might be confusing to these users. So,
> maybe just fix this nitpick?
[...]

Although Freexian organises funding for LTS work, there are other LTS
contributors paid directly by other organisations or working on their
own time.  So the best name we have for those contributors now is "LTS
team", but that could change if we change to a different term for the
associated support status.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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


Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Ben Hutchings
On Fri, 2018-10-26 at 11:05 -0400, Antoine Beaupré wrote:
> On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote:
[...]
> > 3) Stop using LTS as a "label" for oldstable releases?
> 
> I am not sure how that would help anything. :) I do like, however, the
> idea brought by Jeremy Stanley in a reply to your email of using the
> "Extended Maintenance" label instead of "Long Term Support" because the
> latter is usually attached to a *current* release, while the former is
> seen as an *extension*.

+1 to this.  Our current use of "LTS" is unusual.

> But renaming the project seems like a huge undertaking and I'm not sure
> it would really resolve this conendrum.
[...]

I don't think we would need to rename everything, at least not at once.
The critical thing to change is that we should change the way we refer
to jessie's status (and future releases when regular security support
for them ends).

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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


Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Antoine Beaupré
On 2018-10-26 13:02:57, Thadeu Lima de Souza Cascardo wrote:
>> > 5) Is that not true anymore with Extended LTS and CIP?
>> 
>> Sorry, what is not true? #4? If so, I think people should *still*
>> install the latest supported Debian release (stable or stretch right
>> now) and not LTS or ELTS, when deploying new systems.
>
> Yeah, not true that Stretch would have a latest term support compared to
> any earlier release. So, if one needs something that lasts 12 years,
> should one be picking up Stretch, Jessie or Wheezy?

"12 years" ... it depends when you start counting. Do you count from the
release date of the software? Or "now"? Because if you want 12 years
support, jessie, even less so wheezy is not going to help you.

>From that perspective, you might stand a better chance of installing
*unstable* or *buster* right now if you want the longer support schedule
from *right now* because then you'll get the buster release cycle (three
years, starting from late 2019 if not 2020), then LTS (two years) and
maybe even an extra ELTS (a year or more) slapped on top, which will
bring you somewhere somewhere close to 2027. That's 9 years from now, a
far cry from your 12 years objective, but it's pretty much the best shot
we have.

12-year support cycle is the crazy stuff they do at Solaris, or at least
did. Since Oracle bought it, they bumped that up to *twenty* years:

https://en.wikipedia.org/wiki/Solaris_(operating_system)#Version_history

We're still far away from that goal. And keep in mind the Solaris that
is supported there is a very limited operating system when compared with
the scope of packages supported in Debian...

A.

-- 
La seule excuse de Dieu, c'est qu'il n'existe pas.
- Stendhal



Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Thadeu Lima de Souza Cascardo
On Fri, Oct 26, 2018 at 11:05:18AM -0400, Antoine Beaupré wrote:
> On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote:
> > I am guessing one of the other (incorrect) assumption users might make
> > is that the "LTS version" is preferred over other versions. That's how
> > LTS works for Linux and Ubuntu, for example. So, a user would rather
> > install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10,
> > that is supported for 9 months. The same happens with Linux 4.14 versus
> > Linux 4.18.
> 
> I agree that is a concern...
> 
> > I am not sure it's clear to users that all Debian stable versions would
> > have Long Term Support, because the releases are not *labeled* as LTS. I
> > know the wiki says:
> >
> > "Debian Long Term Support (LTS) is a project to extend the lifetime of
> > *all* Debian stable releases to (at least) 5 years." (emphasis mine)
> >
> > But I believe the table right below that would still confuse some users
> > that would understand that Jessie is supported by LTS, while Stretch is
> > not, even though there is a schedule column there.
> 
> ... but, well, that is pretty clear isn't it? "All" releases are
> supported, and "stretch" is explicitely mentioned in the table. I think
> we've done our part.
> 

I agree here, my suggestions below were just asking how could we make
things better or even more clear to the uneducated user, who comes from
these other projects, which have a different release/maintenance
process. I would refute some of the suggestions myself, but thought
about suggesting anyway because I didn't want to assume how other people
would feel about them.

> > Using the LTS term in a slightly different way than the "industry
> > standard" now means we need to spend a little more effort on users
> > education.
> 
> I'm not sure we're using it that differently. But it's true normal
> stable releases don't immediately get marked as LTS. There are good
> reasons for that, and those would be very hard to work around. To get
> more explicit, we can answer your questions one by one:
> 
> > Should we:
> >
> > 1) Start calling the stable releases as LTS releases?
> 
> No. That would be very confusing, as the stable releases are (to
> simplify greatly) under the responsability of the security team (ST) and
> the stable release managers (SRM), not the LTS team.
> 
> > 2) Say "supported by Security team" versus "supported by Freexian",
> > instead of just saying "supported by LTS"?
> 
> Hm... I'm not sure what that refers to or what you're proposing, but LTS
> releases are *not* supported by the security team, but by the LTS team.
> 

I meant that we would say that stable is supported by the security team.
And instead of saying that Jessie was supported by the LTS team, we
would say supported by Freexian. The table at
https://wiki.debian.org/LTS doesn't even say "supported by LTS team",
but "supported by LTS", which might be confusing to these users. So,
maybe just fix this nitpick?

> > 3) Stop using LTS as a "label" for oldstable releases?
> 
> I am not sure how that would help anything. :) I do like, however, the
> idea brought by Jeremy Stanley in a reply to your email of using the
> "Extended Maintenance" label instead of "Long Term Support" because the
> latter is usually attached to a *current* release, while the former is
> seen as an *extension*.
> 
> But renaming the project seems like a huge undertaking and I'm not sure
> it would really resolve this conendrum.

Ubuntu started supporting an EOL release with "Extended Security
Maintenance". So, maybe start using something like those two projects
have been doing?

> > 4) Just advise users all the time that they should prefer the latest
> > stable release, as that is going to have the "latest term support"?
> 
> Right. So maybe that's a piece that's been missing in our
> communications, and that could be the reason why people still think they
> should install jessie cloud images. ;)
> 
> So maybe we could make some proeminent statement on the LTS and
> LTS/Using pages in the wiki?
> 

Agreed. Advising new users that they should be using the latest stable
release if they have no explicit need to use any older ones.

> > 5) Is that not true anymore with Extended LTS and CIP?
> 
> Sorry, what is not true? #4? If so, I think people should *still*
> install the latest supported Debian release (stable or stretch right
> now) and not LTS or ELTS, when deploying new systems.

Yeah, not true that Stretch would have a latest term support compared to
any earlier release. So, if one needs something that lasts 12 years,
should one be picking up Stretch, Jessie or Wheezy?

> 
> I think the idea here is that we think Debian rocks. It's solid, stable,
> and we love it. But we want to support it for even longer than what our
> volunteer team can deal with right now, so we're hiring a bunch of
> dedicated fanatics who can figure out how to fit a square peg in a round
> hole for you.
> 
> But please don't make us any more 

Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Antoine Beaupré
On 2018-10-26 10:26:09, Thadeu Lima de Souza Cascardo wrote:
> On Wed, Oct 24, 2018 at 09:30:46AM +0800, Paul Wise wrote:
>> On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote:
>> >
>> > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:
>> > >
>> > > In short: Make it very clear if you want to provide long-term support
>> > > for your project. Talk to the LTS team in case you need help. Nobody is
>> > > forced to do anything.
>> >
>> > This is a good idea, but ISTM the assumption should be that the
>> > subproject does not participate unless it explicitly says that it does.
>> 
>> This thread started because users have the opposite assumption. So I
>> think it would be better to be explicit about support teams and
>> timelines.
>> 
>> -- 
>> bye,
>> pabs
>> 
>> https://wiki.debian.org/PaulWise
>> 
>
> I am guessing one of the other (incorrect) assumption users might make
> is that the "LTS version" is preferred over other versions. That's how
> LTS works for Linux and Ubuntu, for example. So, a user would rather
> install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10,
> that is supported for 9 months. The same happens with Linux 4.14 versus
> Linux 4.18.

I agree that is a concern...

> I am not sure it's clear to users that all Debian stable versions would
> have Long Term Support, because the releases are not *labeled* as LTS. I
> know the wiki says:
>
> "Debian Long Term Support (LTS) is a project to extend the lifetime of
> *all* Debian stable releases to (at least) 5 years." (emphasis mine)
>
> But I believe the table right below that would still confuse some users
> that would understand that Jessie is supported by LTS, while Stretch is
> not, even though there is a schedule column there.

... but, well, that is pretty clear isn't it? "All" releases are
supported, and "stretch" is explicitely mentioned in the table. I think
we've done our part.

> Using the LTS term in a slightly different way than the "industry
> standard" now means we need to spend a little more effort on users
> education.

I'm not sure we're using it that differently. But it's true normal
stable releases don't immediately get marked as LTS. There are good
reasons for that, and those would be very hard to work around. To get
more explicit, we can answer your questions one by one:

> Should we:
>
> 1) Start calling the stable releases as LTS releases?

No. That would be very confusing, as the stable releases are (to
simplify greatly) under the responsability of the security team (ST) and
the stable release managers (SRM), not the LTS team.

> 2) Say "supported by Security team" versus "supported by Freexian",
> instead of just saying "supported by LTS"?

Hm... I'm not sure what that refers to or what you're proposing, but LTS
releases are *not* supported by the security team, but by the LTS team.

> 3) Stop using LTS as a "label" for oldstable releases?

I am not sure how that would help anything. :) I do like, however, the
idea brought by Jeremy Stanley in a reply to your email of using the
"Extended Maintenance" label instead of "Long Term Support" because the
latter is usually attached to a *current* release, while the former is
seen as an *extension*.

But renaming the project seems like a huge undertaking and I'm not sure
it would really resolve this conendrum.

> 4) Just advise users all the time that they should prefer the latest
> stable release, as that is going to have the "latest term support"?

Right. So maybe that's a piece that's been missing in our
communications, and that could be the reason why people still think they
should install jessie cloud images. ;)

So maybe we could make some proeminent statement on the LTS and
LTS/Using pages in the wiki?

> 5) Is that not true anymore with Extended LTS and CIP?

Sorry, what is not true? #4? If so, I think people should *still*
install the latest supported Debian release (stable or stretch right
now) and not LTS or ELTS, when deploying new systems.

I think the idea here is that we think Debian rocks. It's solid, stable,
and we love it. But we want to support it for even longer than what our
volunteer team can deal with right now, so we're hiring a bunch of
dedicated fanatics who can figure out how to fit a square peg in a round
hole for you.

But please don't make us any more square pegs and install Debian
normally. Don't break Debian! :)

https://wiki.debian.org/DontBreakDebian

Thanks!

A.

-- 
Work expands so as to fill the time available for its completion.
- Parkinson's law



Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Jeremy Stanley
On 2018-10-26 10:26:09 -0300 (-0300), Thadeu Lima de Souza Cascardo wrote:
[...]
> Using the LTS term in a slightly different way than the "industry
> standard" now means we need to spend a little more effort on users
> education.
[...]

Just a data point: under pressure from downstream consumers the
OpenStack project implemented longer-but-reduced support for each of
its major coordinated releases. In an effort to avoid the confusion
seen here over "LTS" they opted to refer to it as "Extended
Maintenance" instead. Like Debian's LTS, the idea is that all major
releases switch to EM once they reach what would originally have
been their EOL date, and EM is continued on them for as long as the
downstream stakeholders interested in those releases are willing to
put in the effort to review critical fixes and keep those particular
branches tested (which in many cases may also mean investing in and
getting involved with assisting the OpenStack community's equivalent
of the DSA to keep the necessary test infrastructure to support
those older releases maintained and viable).
-- 
Jeremy Stanley


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-26 Thread Thadeu Lima de Souza Cascardo
On Wed, Oct 24, 2018 at 09:30:46AM +0800, Paul Wise wrote:
> On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote:
> >
> > On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:
> > >
> > > In short: Make it very clear if you want to provide long-term support
> > > for your project. Talk to the LTS team in case you need help. Nobody is
> > > forced to do anything.
> >
> > This is a good idea, but ISTM the assumption should be that the
> > subproject does not participate unless it explicitly says that it does.
> 
> This thread started because users have the opposite assumption. So I
> think it would be better to be explicit about support teams and
> timelines.
> 
> -- 
> bye,
> pabs
> 
> https://wiki.debian.org/PaulWise
> 

I am guessing one of the other (incorrect) assumption users might make
is that the "LTS version" is preferred over other versions. That's how
LTS works for Linux and Ubuntu, for example. So, a user would rather
install Ubuntu 18.04 that is supported for 5 years than Ubuntu 18.10,
that is supported for 9 months. The same happens with Linux 4.14 versus
Linux 4.18.

I am not sure it's clear to users that all Debian stable versions would
have Long Term Support, because the releases are not *labeled* as LTS. I
know the wiki says:

"Debian Long Term Support (LTS) is a project to extend the lifetime of
*all* Debian stable releases to (at least) 5 years." (emphasis mine)

But I believe the table right below that would still confuse some users
that would understand that Jessie is supported by LTS, while Stretch is
not, even though there is a schedule column there.

Using the LTS term in a slightly different way than the "industry
standard" now means we need to spend a little more effort on users
education.

Should we:

1) Start calling the stable releases as LTS releases?
2) Say "supported by Security team" versus "supported by Freexian",
instead of just saying "supported by LTS"?
3) Stop using LTS as a "label" for oldstable releases?
4) Just advise users all the time that they should prefer the latest
stable release, as that is going to have the "latest term support"?
5) Is that not true anymore with Extended LTS and CIP?

Cascardo.



Re: Confusing our users - who is supporting LTS?

2018-10-25 Thread Michael Stone

On Thu, Oct 25, 2018 at 09:15:31PM +0200, Tollef Fog Heen wrote:

Noah writes that the latest image is 8.7.  The latest jessie version is
8.11 according to https://wiki.debian.org/DebianJessie.


Ok, then obviously nobody cares. :) Either way, the important thing is 
that security updates are enabled; the latest release needs updates more 
often than not.


Mike Stone



Re: Confusing our users - who is supporting LTS?

2018-10-25 Thread Tollef Fog Heen
]] Michael Stone 

> On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote:
> >We should not be in the business of distributing known-vulnerable
> >software.  There are practical considerations around point releases and
> >such which makes this not-really-true for a period of time after there's
> >a security update out, but this gets converged at each point release. If
> >you look cdimage.d.o, we are only distributing the latest point release.
> >I think the same standard should apply to cloud images.
> 
> It does; they are distributing the latest (lastest) point release.

Noah writes that the latest image is 8.7.  The latest jessie version is
8.11 according to https://wiki.debian.org/DebianJessie.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



Re: Confusing our users - who is supporting LTS?

2018-10-24 Thread Michael Stone

On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote:

We should not be in the business of distributing known-vulnerable
software.  There are practical considerations around point releases and
such which makes this not-really-true for a period of time after there's
a security update out, but this gets converged at each point release. If
you look cdimage.d.o, we are only distributing the latest point release.
I think the same standard should apply to cloud images.


It does; they are distributing the latest (lastest) point release. As 
you already stipulated, this is no different than the normal state of 
stable, which is only secure if you update & upgrade with security 
sources.list entry.


IMO, the main benefits of point releases are that 1) they reduce the 
amount you need to download if you are installing from an iso and 2) 
they are an opportunity to introduce *non* security updates into stable. 
I'm not sure that either of these are relevent in the context of this 
thread.


Mike Stone



Re: Confusing our users - who is supporting LTS?

2018-10-24 Thread Raphael Hertzog
Hi,

On Tue, 23 Oct 2018, Noah Meyerhans wrote:
> The question
> here was simply about discoverability. If you're a Debian user just
> beginning exploration of public cloud alternatives, should we make it
> easy for you to launch LTS instead of stable?

I don't see any reason to make it hard, but it should definitely be shown
less prominently than the current stable release. And the difference in
the status must be clearly communicated.

> The perception, afaict, is that LTS only exists because people are paid
> to work on it. There has not traditionally been sufficient interest
> within Debian to sustain support of a release for 5 years, so some
> companies have provided financial incentives. That's fine, but potential
> somewhat fragile. If that funding goes away, does LTS go away?

LTS has been running for 4.5 years and rely on many sponsors so that nothing
stops when one sponsor goes away. It's not that fragile currently.

> Is LTS work, for pay, going to drain resources from volunteer work?

My experience has rather been the opposite. Most paid LTS contributors do
between 10 and 30 hours per month for LTS and in multiple cases it
allows them to spend many more hours of volunteer work in the project.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Noah Meyerhans
On Tue, Oct 23, 2018 at 10:05:35PM +0200, Tollef Fog Heen wrote:
> > To be clear, the ongoing cost to the cloud team of dealing with jessie
> > on AWS (where this issue originally came up) has been exactly zero,
> > afaict. That is, we haven't actually updated anything in >18 months.
> > Users who launch a jessie image there get 8.7, with 106 pending updates.
> > As long as LTS exists and users are happy with it, there's nothing
> > strictly wrong with this situation. They should update their instances
> > and reboot, but from there, they are free to continue using them in
> > relative safety.
> 
> I disagree with the statement that there's nothing wrong with this.

Sorry; to be more precise, I meant that there's nothing wrong that can't
be remedied using entirely standard and well-established workflows, e.g.
dist-upgrade. There's no need to add custom apt sources, apt keys, or
anything like that. dist-upgrade is something I'd expect most users to
do pretty early in the lifetime of a cloud instance (and possibly
regularly after that, depending on how long it's expected to remain
active).

noah



signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Paul Wise
On Wed, Oct 24, 2018 at 4:15 AM Sean Whitton wrote:
>
> On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:
> >
> > In short: Make it very clear if you want to provide long-term support
> > for your project. Talk to the LTS team in case you need help. Nobody is
> > forced to do anything.
>
> This is a good idea, but ISTM the assumption should be that the
> subproject does not participate unless it explicitly says that it does.

This thread started because users have the opposite assumption. So I
think it would be better to be explicit about support teams and
timelines.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Sean Whitton
Hello Markus,

On Tue 23 Oct 2018 at 05:06PM +0200, Markus Koschany wrote:

> I believe LTS is not a black and white issue as it is depicted in this
> thread so far.

Yes, that is fair enough.

> This is the first time that someone expresses concern how LTS affects
> other subprojects but I don't think it is correct to assume that it is a
> general issue which can only be solved by making LTS less integrated
> into Debian. I feel the best way to deal with such situations is to
> communicate very clearly that "subproject X" does not support LTS
> releases and recommends to make an upgrade instead. If subproject X is
> general in favor of LTS support but lacks time and energy to make it
> happen, we should determine whether it is possible and desired that the
> LTS team steps in and lends a helping hand.
>
> In short: Make it very clear if you want to provide long-term support
> for your project. Talk to the LTS team in case you need help. Nobody is
> forced to do anything.

This is a good idea, but ISTM the assumption should be that the
subproject does not participate unless it explicitly says that it does.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Tollef Fog Heen
]] Noah Meyerhans 

> To be clear, the ongoing cost to the cloud team of dealing with jessie
> on AWS (where this issue originally came up) has been exactly zero,
> afaict. That is, we haven't actually updated anything in >18 months.
> Users who launch a jessie image there get 8.7, with 106 pending updates.
> As long as LTS exists and users are happy with it, there's nothing
> strictly wrong with this situation. They should update their instances
> and reboot, but from there, they are free to continue using them in
> relative safety.

I disagree with the statement that there's nothing wrong with this.

We should not be in the business of distributing known-vulnerable
software.  There are practical considerations around point releases and
such which makes this not-really-true for a period of time after there's
a security update out, but this gets converged at each point release. If
you look cdimage.d.o, we are only distributing the latest point release.
I think the same standard should apply to cloud images.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are



Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Noah Meyerhans
On Tue, Oct 23, 2018 at 11:03:39AM -0400, Antoine Beaupré wrote:
> TL;DR: Why not just delegate image management to the LTS team once
> oldstable because LTS just like we do with security? Zobel also provided
> a good template for the images life cycle which could clarify this on
> debian-cloud@, which I fully support.

We could certainly delegate. The goal for the future, though, is to have
enough automation in place that continuing to support an old release is
simply a matter of not turning off its image generation. For technical
reasons, jessie is a bit different, but future releases should be
simpler. But the question really isn't "how do we keep publishing and
supporting jessie?", it's "should we keep publishing and supporting
jessie?"

To be clear, the ongoing cost to the cloud team of dealing with jessie
on AWS (where this issue originally came up) has been exactly zero,
afaict. That is, we haven't actually updated anything in >18 months.
Users who launch a jessie image there get 8.7, with 106 pending updates.
As long as LTS exists and users are happy with it, there's nothing
strictly wrong with this situation. They should update their instances
and reboot, but from there, they are free to continue using them in
relative safety.

> But in the cloud infrastructure, things are slightly different. The base
> image isn't as important as the application and/or data that runs on
> top. In the cloud, we install new "machines" all the time, sometimes as
> part of CI/CD processes and those machines are not "pets", they are
> "cattle" and recycled constantly.

That's a very common use case, for sure, but not the only one we want to
support. We definitely do have people who launch an instance and then
keep it around for a long time, interacting with and configuring it by
hand, just as they would with any physical server. (In fact, I recently
noticed a bunch of what appeared to be jessie EC2 instances owned by our
QA team; when I asked about them, I learned that they'd all been
upgraded in place to stretch.)

> In that sense, switching the base OS is, paradoxically, a big deal so
> it actually makes sense to install an older release for newer
> machines. This is why Travis CI still supports Ubuntu LTS Precise
> (12.04) and Trusty (14.04), the former which isn't supported by
> Canonical, and it's missing *two* more recent LTS releases, Xenial
> (16.04) and Bionic (18.04).

Yes, this is correct; it's also something we can continue to support,
even without active engagement from the LTS team. As long as the LTS
team doesn't do anything that breaks updates on the old images, we're
never going to tell people that they can't launch them. The question
here was simply about discoverability. If you're a Debian user just
beginning exploration of public cloud alternatives, should we make it
easy for you to launch LTS instead of stable?

> It seems like a nice, symmetrical approach to solve the problem: just
> punt this over to the LTS team. We have some capacity and knowledge. I
> know I would be happy to work on those images.

I'm not even sure that's necessary. I, as a member of the cloud team and
maintainer of the stretch AWS images, have already expressed willingness
to update the jessie images, if it's something we as a project agree is
appropriate.  Coming to some clearer agreement about that, especially in
light of a decision to the contrary that we made within the cloud team
recently, is the sticky point.

The perception, afaict, is that LTS only exists because people are paid
to work on it. There has not traditionally been sufficient interest
within Debian to sustain support of a release for 5 years, so some
companies have provided financial incentives. That's fine, but potential
somewhat fragile. If that funding goes away, does LTS go away? Is LTS
work, for pay, going to drain resources from volunteer work? These
questions exist outside the context of the current cloud team issue. The
cloud team just happens to be the one to have tripped over them in this
instance.

noah



signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Antoine Beaupré
Hi Steve!

On 2018-10-23 04:26:18, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

TL;DR: Why not just delegate image management to the LTS team once
oldstable because LTS just like we do with security? Zobel also provided
a good template for the images life cycle which could clarify this on
debian-cloud@, which I fully support.

I acknowledge this is, indeed, a problem Debian volunteers have
sometimes mentioned. It's a broader issue than just the cloud team of
course, but if I may, I would like to try and fix that specific issue in
itself. I know there's the larger debate of separation of duty and
infrastructure, paid-vs-unpaid work and other questions, but I do not
think it's productive to fix that particular issue by addressing the
larger ones up front, as they seem intractable unless we address
specific cases.

In this case, it seems to me we have a flawed assumption in the way we
handle Debian LTS: we assume people will not actually install it and
instead just upgrade machines installed when LTS was "stable". It's a
fair assumption in the case of workstations and long-lived, "pet"
servers. I know I wouldn't install a new bare-metal server with an
unsupported release: I would install stretch, if not buster, not jessie.

But in the cloud infrastructure, things are slightly different. The base
image isn't as important as the application and/or data that runs on
top. In the cloud, we install new "machines" all the time, sometimes as
part of CI/CD processes and those machines are not "pets", they are
"cattle" and recycled constantly. In that sense, switching the base OS
is, paradoxically, a big deal so it actually makes sense to install an
older release for newer machines. This is why Travis CI still supports
Ubuntu LTS Precise (12.04) and Trusty (14.04), the former which isn't
supported by Canonical, and it's missing *two* more recent LTS releases,
Xenial (16.04) and Bionic (18.04).

So while we haven't taken up the work of managing the debian-installer
parts of Debian LTS (because there was no need or demand for it), it
seems to me like a fair request that the Debian LTS team should manage
the Debian Cloud images once the official support window closes. Just
like the security team delegates oldstable to LTS, the cloud team could
hand off unsupported images to the LTS team. In a way, just like APT and
the normal archive, "cloud images" are just another way to "upgrade" an
existing Debian install.

It seems like a nice, symmetrical approach to solve the problem: just
punt this over to the LTS team. We have some capacity and knowledge. I
know I would be happy to work on those images.

That's for the expectations part of the question. As for how to clarify
this to our users, Martin Zobel-Helas made a good proposal for a
workflow of how and when the team updates the images and when they
become unsupported. The /etc/motd in the images could mention this, for
example and the last build could add a warning pointing to it. If we
agree to delegate to the LTS team, the document should also mention that
transition.

Sorry for the long email, I hope it's useful!

a.

-- 
We have to talk about liberating minds as well as liberating society.
- Angela Davis



Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Markus Koschany
[I am trimming the CC list a little. Steve is subscribed to debian-lts.
Our leader is subscribed to debian-lts and debian-devel and drowns in
emails anyway. I hope you agree.]

Am 23.10.18 um 15:47 schrieb Sean Whitton:
[...]
> The more LTS is integrated with the regular project, the more that teams
> will feel they have to spend time on LTS matters.  Even if paid LTS team
> members are the ones writing the patches to do the actual integration,
> the relevant Debian team will still have to review those patches, engage
> in design discussion and keep LTS needs in mind while doing their other
> work.  Indeed, that's what you're asking for in the paragraphs of your
> e-mail I've quoted.  Reducing integration avoids this problem.

I believe LTS is not a black and white issue as it is depicted in this
thread so far. We neither solve such a problem by hiding LTS nor by
reducing the integration within the Debian project. The goals of the LTS
project have been clearly communicated from the beginning and nobody was
ever forced to work on them. [1] Our main goal is to extend the lifetime
of stable releases by providing security support and bug fixes for all
packages except those which are marked as unsupported in our
debian-security-support package. That has never implied that we support
every official or non-official subproject that bases its work on the
availability of LTS.

This is the first time that someone expresses concern how LTS affects
other subprojects but I don't think it is correct to assume that it is a
general issue which can only be solved by making LTS less integrated
into Debian. I feel the best way to deal with such situations is to
communicate very clearly that "subproject X" does not support LTS
releases and recommends to make an upgrade instead. If subproject X is
general in favor of LTS support but lacks time and energy to make it
happen, we should determine whether it is possible and desired that the
LTS team steps in and lends a helping hand.

In short: Make it very clear if you want to provide long-term support
for your project. Talk to the LTS team in case you need help. Nobody is
forced to do anything.

Regards,

Markus

P.S.:

As a first step I'm going to create a LTS/Jessie subpage on our wiki
that will outline what we currently (don't) support in Jessie.

[1] https://wiki.debian.org/LTS/



signature.asc
Description: OpenPGP digital signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Sean Whitton
Hello Raphael,

On Tue 23 Oct 2018 at 09:52AM +0200, Raphael Hertzog wrote:

> Instead we are rather aiming to integrate LTS more and more everywhere.
> However, when LTS is becoming a burden on other teams, we should
> definitely look how the LTS team can help to alleviate that burden.
> Because as you know the LTS team has paid contributors to do that kind
> of work.
>
> I invite you to start a conversation between debian-lts and debian-cloud
> to discuss how the LTS team can help you with the workload that you would
> rather get rid of. Maybe we need to allocate some time each month to
> update LTS images, maybe you need our help to improve your tooling to better
> support LTS and that would be enough, etc. I don't know. Let's discuss.

Unfortunately, I don't think this suggestion could help with the issues
raised by Steve.

The more LTS is integrated with the regular project, the more that teams
will feel they have to spend time on LTS matters.  Even if paid LTS team
members are the ones writing the patches to do the actual integration,
the relevant Debian team will still have to review those patches, engage
in design discussion and keep LTS needs in mind while doing their other
work.  Indeed, that's what you're asking for in the paragraphs of your
e-mail I've quoted.  Reducing integration avoids this problem.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-23 Thread Raphael Hertzog
Hi Steve,

On Tue, 23 Oct 2018, Steve McIntyre wrote:
> So I'm worried that those of us who have *not* volunteered to support
> LTS are being pressured into spending our time on it anyway. What can
> we do to fix that? How/where do we clarify for our users (and
> developers!) what LTS means, and what expectations are fair?

FWIW, I don't think that the right answer is to make LTS even more clearly
separate. We want to be able to say that Debian is supported for 5 years
and we don't want to have to put an asterisk pointing to a long list of
exceptions.

Instead we are rather aiming to integrate LTS more and more everywhere.
However, when LTS is becoming a burden on other teams, we should
definitely look how the LTS team can help to alleviate that burden.
Because as you know the LTS team has paid contributors to do that kind
of work.

I invite you to start a conversation between debian-lts and debian-cloud
to discuss how the LTS team can help you with the workload that you would
rather get rid of. Maybe we need to allocate some time each month to
update LTS images, maybe you need our help to improve your tooling to better
support LTS and that would be enough, etc. I don't know. Let's discuss.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature


Re: Confusing our users - who is supporting LTS?

2018-10-22 Thread Craig Small
I've seen this sort of thing done elsewhere and the way they did it was to
put a large amount of separation between the two.

So the main site only mentioned the old releases in a historical context
and pointed to a separate website which did the LTS. Any page for the older
versions had a prominent common banner stating this.

The Debian website doesn't really show this.

Forget being a developer for a moment and look at
https://www.debian.org/releases/jessie/ for example, it's not terribly
clear.

Or https://packages.debian.org/jessie/procps is this still maintained?

Eg "After /date/ Debian version X is no longer supported by the Debian
project, see ancientdebian.org". Every page every time. I'm not saying as
annoying as those cookie notices, but something close.

It has to be clear there is this cutoff. The fact that some developers work
on it is fine, but stating that anywhere muddies the waters.

Not an ideal situation and you'll still cop some emails but it might help.

 - Craig


> --
Craig Small https://dropbear.xyz/ csmall at : dropbear.xyz
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5