Re: [Tails-dev] Basing Tails on quarterly snapshots of Debi…

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Basing Tails on quarterly snapshots of Debian Testing: status update… and next steps?
hi,

sajolida:
> Speaking as an accountant: I'm worried about taking important money
> decisions before the end of the fundraising campaign and our budget
> planning which will happen in February.
> Because I wouldn't like to commit to paying work on "rolling Tails"
> (what's the name of your project by the way?) to then realize two
> months later that we will be very short on other core budget lines.
> This applies to technical writing as well: I'd rather have more
> money for core technical writing in 2018 than money for technical
> writing on "rolling Tails" now.


Absolutely. We've already discussed this elsewhere and I think
I already made it clear from the beginning that I agree with all this.

When I wrote "I can look into the money aspect more closely" I didn't
mean to put this back on the table. Instead, I meant looking into
re-purposing money that's *already* budgeted elsewhere for purposes
I find questionable at the moment. I'd rather not elaborate on
a public mailing list though.

Regarding the project name: currently the best we have is "Basing
Tails on quarterly snapshots of Debian Testing", sorry.
Improvements are welcome. "rolling" means something different, let's
not use it.

> Speaking as a friend: Which options are more work and more stress for
> the people involved across the next 12 months?


Across the next 12 months: with all the evaluation and bootstrapping
work that's needed, it's quite clear to me that both B and C entail
more work than A on the short term; but it'll be a more interesting
and meaningful kind of work than workaround'ing Stretch bugs and
backporting stuff. B is probably a bit less stressful than C, thanks
to the more relaxed timeline, but it implies more work for me, and
it's much less fun than having team-mates.

Across the next 18 months: then A gets much worse because we'll be
back to porting all our stuff in the last N months before the Debian
release, while with B or C it would be done already. Been there, done
that (too many times), which is one of the main reasons why this
project was born.

All in all I'm more concerned about the "is it fun?" and "does it make
sense to me?" aspects (that are strongly correlated to stress levels)
than about my workload: I can very well handle some more work if it
makes sense to me (in terms of long-term strategy) and is
technically challenging.

Cheers,
--
intrigeri