Re: Regarding the recent update on the xfce packages
On Tue, Mar 17, 2015 at 4:29 AM, Dark Serph wrote: > Please, think fondly in updating the xfce packages on JESSIE, before > launching it! Your suggestion would probably have best been sent to the maintainers of the Xfce packages in Debian rather than debian-project. Unfortunately since we are in the pre-release freeze, updating Xfce in jessie to a new upstream version isn't going to happen. Once the jessie release is out and the Xfce team have uploaded a new version of Xfce to stretch, it could be added to the list of jessie backports if the team have the time to do that. You might want to join the team to help them out with that. https://pkg-xfce.alioth.debian.org/ http://backports.debian.org/Contribute/ -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6EYQew5pdB+bSguPi5ae=f3uxbuv34b0wkdunfg6rr...@mail.gmail.com
Regarding the recent update on the xfce packages
Please, think fondly in updating the xfce packages on JESSIE, before launching it! Many thanks for the attention!
Re: non-financial donations (was: call for help: partners program)
also sprach Paul Wise [2015-03-16 12:52 +0100]: > Re financial donations, I'd personally like to see more focus on > something like having 20k or more individuals donating $10 a year > and most of them listed on contributors.d.o, as opposed to turning > Debian into more of an advertising organisation, which seems to be > the end of the spectrum we are headed towards. I don't think Debian should become an advertising organisation. We have identified some ways in which we could use money that IMHO requires a cash flow. So I am merely advocating finding ways of generating that cash flow based on our product and brand, without losing the soul. The problem with 20k × $10 / year is collection. We can let Paypal do this, but I am sure we would find people strongly opposed to Paypal here. But we'd need to use such a provider, working globally, but then you are looking at losing 5–10% of those funds to them. Anyway, the two are not at all in disagreement. Someone giving $10 to Debian every year should be treated with the same diligence as someone giving 20k, especially since the $10 are likely to be a larger cut of their budget than 20k for BigCorp. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "if you stew apples like cranberries, they taste more like prunes than rhubarb does." -- groucho marx digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: call for help: partners program
also sprach Lucas Nussbaum [2015-03-16 10:39 +0100]:
> I think that it is the role of the DPL to break ties in that context,
> under "Make any decision for whom noone else has responsibility.".
> Of course, that should be done after hearing opinions, including from
> teams such as the press team and the www team that are likely to be
> affected by many of the perks.
You say the DPL would break ties "of course […] after hearing
opinions". How is that different from a delegate making decisions
after hearing opinions?
Obviously, perks affect other teams and designing them would require
being in touch with those teams. The goal should not only be to sell
perks that don't "sell out our soul", but also perks that we can
actually fulfill, and unless the fundraising team wants to also
become the fulfillment team, we'll need to have all the other teams
on board, identifying with our product(s) and having felt part of
the process so that they are motivated later on to fulfill the
promises we made.
But this design process will need active driving and decision-making
all along, and while we have all the time in the world to discuss
technical decisions until we get stuck and have to call the CTTE,
fundraising won't work this way, and I wouldn't feel particularly
motivated to engage, to be honest.
It really all boils down to one question, IMHO:
Assuming there's a team with good knowledge of Debian (the
"product", as well as the project's values) —
Are we as a project ready to delegate design, implementation and
further management to said group in full trust that they will
- always stay faithful to the project,
- engage with the stakeholders involved (e.g. press team, web
team, the community) for feedback,
- act without an agenda though still enabled and willing to drive
the process and make decisions,
- get up after making mistakes and learn from them?
To me, the role of the DPL in this should not be to be the tip of
the scales at the end of the design process, when dozens of strongly
held opinions have been formed and you can basically only choose
whom to go against and lose. To me, the leader should make such
decisions before the process, be ready to defend these decisions and
back the efforts with support by the project — this is all assuming
that while mistakes will happen, none are breaches of trust or harm
the project.
But Lucas, I am not trying to put you on the spot here, nor any of
the candidates. The issue at hand is about money, and we all know
that as soon as money gets involved, we all recall history and go
into hyper-defensive mode over our and the project's ideals, which
is GOOD; asking the DPL to simply step beyond this would be unfair,
and unrealistic as well.
Yet, if we wanted to create a cash flow with the goal to be able to
hand out budgets to teams such as DSA, sprints, DebConfs, outreach
programmes and what not ("make better use of our money"), then
I *think* the only way to do so is to approach it with
entrepreneurial freedom.
--
.''`. martin f. krafft @martinkrafft
: :' : proud Debian developer
`. `'` http://people.debian.org/~madduck
`- Debian - when you have better things to do than fixing systems
"der glaube an den kausalnexus ist der aberglaube"
-- wittgenstein
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: non-financial donations (was: call for help: partners program)
On Mon, Mar 16, 2015 at 6:33 PM, martin f krafft wrote: > If Debian had a wishlist, we could let partners join by donating > hardware on this list — until the need is higher and we cannot wait > and have to buy the hardware ourselves, so this would need to be > actively managed. We have a hardware wishlist but there is nothing on it yet and no-one replied to my calls for adding things to it (on IRC, d-d-a). https://wiki.debian.org/Hardware/Wanted https://lists.debian.org/debian-devel-announce/2015/03/msg4.html The previous hardware wishlist became obsolete because it was writeable only by the web team. There is also the DSA wishlist but half of it is obsolete since zack created sources.d.n. https://dsa.debian.org/hardware-wishlist/ Looking at my hardware-donations@d.o archive, we've been offered mostly hardware that we can't use for one reason or another; out of warranty, too slow/ancient, donor didn't follow-up with suggestion to contact porters or we had no use for them. So far only one of eight has been accepted and that was from the manufacturer and was very new hardware. IIRC, the partners program was meant for continuous support every year like supplying machines as-needed for port X rather than one-off donations. Re financial donations, I'd personally like to see more focus on something like having 20k or more individuals donating $10 a year and most of them listed on contributors.d.o, as opposed to turning Debian into more of an advertising organisation, which seems to be the end of the spectrum we are headed towards. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Hoa2QBavjbZcRURfca=+wk-7e0ageeitjlhesj6l-...@mail.gmail.com
non-financial donations (was: call for help: partners program)
also sprach Lucas Nussbaum [2015-03-16 09:45 +0100]: > Also note that one of the tricky parts of the partners role is the > ability to consider non-financial contributions (e.g. hardware, > hosting, sprint hosting, etc.). This is largely orthogonal, but > must not be forgotten. The pending partners inquiries are all of > that nature. Well, this is indeed a very hard subject, and also includes hardware donations. There's the easy case, which is when Debian needs something and then there's demand and presumably a market price (hardware donations and hosting). If Debian had a wishlist, we could let partners join by donating hardware on this list — until the need is higher and we cannot wait and have to buy the hardware ourselves, so this would need to be actively managed. Wrt sprint hosting, I'd refrain from asking the potential hoster for a price to use their offices before accepting them for free, so here I'd rather use some sort of formula that takes into account geographic location (travel costs), amenities provided, food, etc. to determine the actual worth of the hosting to us. I'd reject sponsors who want to give us products instead of cash when there's no concrete need. The biggest challenge IMHO here is though not the valuation of a single donation and slotting it in with our offerings. Instead, I think the biggest challenge are the different "lifetimes", e.g. gold partnership lasts one year and let's just say we would award it in return for a specific SAN by SANManufacturer Ltd. with a 5 year SLA. What then? Does the partner get degraded the next year? All in all, I think the way to solve this is by fixing the rules in the brochure and not to make exceptions, i.e. to become a dependable and predictable peer to our sponsors. And to get there, we probably need to engage with them and shape the product, which will be a longer process. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "i love deadlines. i like the whooshing sound they make as they fly by." -- douglas adams digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: call for help: partners program
On 16/03/15 at 10:13 +0100, martin f krafft wrote: > also sprach Lucas Nussbaum [2015-03-16 09:45 +0100]: > > Obviously I'm not in a position to make long term commitments as > > the DPL. I'd welcome "crazy ideas" in that area, at least in > > a brainstorming phase. Maybe you could start by working on a list > > of possible benefits, and then discuss with the DPL and the > > project which ones we are willing to give to sponsors? > > Okay, so then let's assume we identify perk Foo; now there are three > possible scenarios: > > a) "you know best, do as you see fit" — okay, forget that… ;) > b) "nice perk, but I think this should not be Silver but Gold and > up" > c) "no way we will offer this" from n people, "good idea" from > m people > > I can only dream of (a), and (b) would be really useful feedback. > But what do we do in the case of (c)? Scratch it for lack of > consensus? Push it anyway? What if it's hugely successful with our > sponsors and doesn't change the project really, once people have > come to accept it? What if it's a big failure and we won't do it > again? > > I am asking all these questions now because such sponsorship > brochure is a lot of work. I don't think any small team among us > will be able to just get it right, and being able to obtain feedback > from the community will be extremely useful. > > At the same time, however, I'd hate to create all this work (which > does involve speaking with sponsors at some point), only to find > that the efforts will get stalled because the Debian community can't > agree to place this in the hands of a few and ride along. > > The DebConf15 brochure had some perks at some time that caused > vicious debates, and while we removed the contentious ones, I think > that the only reason we managed to actually get this brochure out > was due to time pressure and just pushing things, which may have > alienated some people. > > In the context of Debian partners, we do not have this time pressure > and we don't have the ability to drive this to completion, unless > delegated. Obviously, nobody would be interested to go against the > majority, but knowing that there won't be consensus on everything, > one still needs to be able to make a move with the support of the > project. I think that it is the role of the DPL to break ties in that context, under "Make any decision for whom noone else has responsibility.". Of course, that should be done after hearing opinions, including from teams such as the press team and the www team that are likely to be affected by many of the perks. I don't think that it makes sense to delegate that authority to the partners team. Its role should be to: - *propose* a list of Perks - rank them in levels (Silver, Gold, ...) - decide on values for their levels - translate non-financial contributions to a common scale I agree that some perks might be contentious. But there are also a lot of "easy" ones. Maybe start by building a list, and we'll see where this goes? - Lucas signature.asc Description: Digital signature
Re: call for help: partners program
also sprach Lucas Nussbaum [2015-03-16 09:45 +0100]: > Obviously I'm not in a position to make long term commitments as > the DPL. I'd welcome "crazy ideas" in that area, at least in > a brainstorming phase. Maybe you could start by working on a list > of possible benefits, and then discuss with the DPL and the > project which ones we are willing to give to sponsors? Okay, so then let's assume we identify perk Foo; now there are three possible scenarios: a) "you know best, do as you see fit" — okay, forget that… ;) b) "nice perk, but I think this should not be Silver but Gold and up" c) "no way we will offer this" from n people, "good idea" from m people I can only dream of (a), and (b) would be really useful feedback. But what do we do in the case of (c)? Scratch it for lack of consensus? Push it anyway? What if it's hugely successful with our sponsors and doesn't change the project really, once people have come to accept it? What if it's a big failure and we won't do it again? I am asking all these questions now because such sponsorship brochure is a lot of work. I don't think any small team among us will be able to just get it right, and being able to obtain feedback from the community will be extremely useful. At the same time, however, I'd hate to create all this work (which does involve speaking with sponsors at some point), only to find that the efforts will get stalled because the Debian community can't agree to place this in the hands of a few and ride along. The DebConf15 brochure had some perks at some time that caused vicious debates, and while we removed the contentious ones, I think that the only reason we managed to actually get this brochure out was due to time pressure and just pushing things, which may have alienated some people. In the context of Debian partners, we do not have this time pressure and we don't have the ability to drive this to completion, unless delegated. Obviously, nobody would be interested to go against the majority, but knowing that there won't be consensus on everything, one still needs to be able to make a move with the support of the project. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems only by counting could humans demonstrate their independence of computers. -- douglas adams, "the hitchhiker's guide to the galaxy" digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: call for help: partners program
On 16/03/15 at 09:32 +0100, martin f krafft wrote: > also sprach Lucas Nussbaum [2015-03-16 07:55 +0100]: > > Please let me know if you need something from me. > > I would like to know how the procedure will be between now and then. > > Let's make it easy and say up-front that we will not allow a sponsor > to gain influence over project decisions, no matter how much money > they give us.¹ > > So we get to work and design the "products" to sell with our > sponsorship brochure, i.e. bundling perks (benefits) for different > levels. For instance, we might want to name sprints after our > Silver+ sponsors, mention all Gold and Platinum sponsors in our > press releases forthwith, and offer 50% discounts on the DebConf > sponsorship packages of equal or lesser levels to all our sponsors. > > Obviously, none of this will be developed behind closed doors > (though probably also not on a mailing list like this) and it'll be > really useful to reach out to the community for feedback, scrutiny > and ideas, but what I wouldn't want to do is "develop" this brochure > in a mailing list discussion with dozens of people. > > I'd only be motivated to work on this if I was allowed to try > things (within limits of course, and also respecting guidelines put > forth in a delegation), make mistakes and recover from them. Can you > imagine that we can pull this off? > > ¹) I think we could open ourselves to ideas about this later on, > but that would certainly require a working programme and > a lengthy discussion about values. So let's not even go there > now. Obviously I'm not in a position to make long term commitments as the DPL. I'd welcome "crazy ideas" in that area, at least in a brainstorming phase. Maybe you could start by working on a list of possible benefits, and then discuss with the DPL and the project which ones we are willing to give to sponsors? Also note that one of the tricky parts of the partners role is the ability to consider non-financial contributions (e.g. hardware, hosting, sprint hosting, etc.). This is largely orthogonal, but must not be forgotten. The pending partners inquiries are all of that nature. Lucas signature.asc Description: Digital signature
Re: call for help: partners program
also sprach Lucas Nussbaum [2015-03-16 07:55 +0100]: > Please let me know if you need something from me. I would like to know how the procedure will be between now and then. Let's make it easy and say up-front that we will not allow a sponsor to gain influence over project decisions, no matter how much money they give us.¹ So we get to work and design the "products" to sell with our sponsorship brochure, i.e. bundling perks (benefits) for different levels. For instance, we might want to name sprints after our Silver+ sponsors, mention all Gold and Platinum sponsors in our press releases forthwith, and offer 50% discounts on the DebConf sponsorship packages of equal or lesser levels to all our sponsors. Obviously, none of this will be developed behind closed doors (though probably also not on a mailing list like this) and it'll be really useful to reach out to the community for feedback, scrutiny and ideas, but what I wouldn't want to do is "develop" this brochure in a mailing list discussion with dozens of people. I'd only be motivated to work on this if I was allowed to try things (within limits of course, and also respecting guidelines put forth in a delegation), make mistakes and recover from them. Can you imagine that we can pull this off? ¹) I think we could open ourselves to ideas about this later on, but that would certainly require a working programme and a lengthy discussion about values. So let's not even go there now. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "no, 'eureka' is greek for 'this bath is too hot.'" -- dr. who digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
