Tails

#1 Updated by sajolida 2015-04-08 22:07:29

• blocked by Feature #9217: Investigate integration of bootstrap with ikiwiki added

#2 Updated by sajolida 2015-05-19 19:22:57

• Affected tool set to Installation Assistant

#4 Updated by tchou 2015-05-28 10:45:53

• Assignee changed from tchou to sajolida
• QA Check set to Ready for QA

#5 Updated by intrigeri 2015-05-28 11:59:57

• Assignee changed from sajolida to tchou
• QA Check changed from Ready for QA to Dev Needed

I’m nearly 100% convinced :)

My main remaining concern is about upgrades and maintenance, that should IMO be addressed in this argument. Below, I’m assuming that we’ll copy a snapshot of the bootstrap’s CSS (possibly minified) into our own Git repo.

• Is it easy to track important bugfixes upstream publishes? (e.g. I suspect that browser upgrades could break stuff sometimes, and then the CSS needs to be updated to cope with it)
• Who will track such bugfixes, validate the new version, and propose merging it into our own Git tree?
• Is there anything like a LTS branch upstream, that’s sanely maintained, and that we can blindly trust and regularly upgrade to e.g. as part of our release process?
  • If yes, for how long is the current LTS branch supported?
• Did anyone of us ever have to upgrade a website from a major bootstrap version to another one? (e.g. we might want to use newly introduced features at some point)
  • If yes: how painful/easy was it?
  • If no: what do other people feel about how painful/easy it is?

Thanks in advance!

#7 Updated by tchou 2015-06-10 11:14:09

• Assignee changed from tchou to intrigeri

#8 Updated by intrigeri 2015-06-10 15:31:40

• Assignee changed from intrigeri to tchou

Thanks for all these answers — this helps me understand what’s going on in that web/CSS world that I don’t know :)

>> * Is it easy to track important bugfixes upstream publishes? (e.g. I suspect that browser upgrades could break stuff sometimes, and then the CSS needs to be updated to cope with it)

> There is some Browser Bugs reported : https://github.com/twbs/bootstrap/issues?q=label%3A%22browser+bug%22+is%3Aclosed

Sounds like a painful way to track important bugfixes. Thankfully,

• http://blog.getbootstrap.com/ has release announces; but they’re way too vague for our needs;
• release tags have a detailed changelog, e.g. https://github.com/twbs/bootstrap/releases/tag/v3.3.4

=> so we should be good, as long as “someone” tracks this.

>> * Who will track such bugfixes, validate the new version, and propose merging it into our own Git tree?

> I guess that the UX or Web team should do this.

That’s pretty vague, but I trust that a more convincing answer will be found before this is rolled out live. Perhaps this task can be combined with maintaining our ikiwiki templates forks, by the way :)

> I don’t think there is a “LTS” version. It jumps from a version to an other one (But of course the releases on the same version “3.x.x” should just fix bugs).

OK, thanks. They say they use semantic versioning, which helps. On https://github.com/twbs/bootstrap/tags I notice that once new major releases are out, old branches see no maintenance release anymore, so basically one has to upgrade if they want bugfixes.

>> * Did anyone of us ever have to upgrade a website from a major bootstrap version to another one? (e.g. we might want to use newly introduced features at some point)
>> If yes: how painful/easy was it?

> It’s painfull. Bootstrap 3 was not backwards compatible with v2.x

That’s bad news, especially combined with the fact that maintenance of previous versions apparently stops immediately when a new major one is out.

> But it’s ok to stick on an old version, and if there is to many things broken, there is alway a big community.

OK… do you have first hand experience with asking for help, within that community, about bugs with newer browsers in a version of bootstrap that’s deprecated since 6 months? a year? more? (rationale: in some communities, this simply doesn’t work, and the answer is pretty much always “please upgrade”)

Another problem with this approach is that we have no very good means to detect “if there is to many things broken”, in particular for browsers we don’t have easy access to. So if we don’t upgrade bootstrap, then we’ll have to rely on bug reports from users, and then try to find help about an obsolete version. Fingers crossed.

But oh well, it’s “only” CSS, so take all that I wrote with a grain of salt :)

That’s all I had in mind. IMO you should integrate the outcome of our discussion into the argument you’ll present to the project, so that other people who may be worried by the same aspects as I am know what’s the deal upfront.

#12 Updated by tchou 2015-11-04 14:52:03

• Assignee changed from tchou to sajolida
• QA Check changed from Dev Needed to Info Needed

I feel that the presentation has been done is this ticket and that the decision as been taken more or less. no ?

Maybe next step is to know how to handle this on the long run ? (the “Who will track such bugfixes, validate the new version, and propose merging it into our own Git tree?” point) ?

#13 Updated by sajolida 2015-11-07 07:49:31

• Status changed from Confirmed to Resolved
• Assignee deleted (sajolida)
• QA Check deleted (Info Needed)

I think we have a misunderstanding on what “presenting to the project” means here. I’m pretty sure I made it clear to you that Redmine was not the right place to “present things to the project” as very few people (actually only intrigeri) is following Redmine closely enough to even know that this discussion is happening.

My idea was to have this discussion on tails-dev. Thankfully (or maybe this played against my plan in this case) intrigeri jumped into the discussion in Redmine and both of you had elaborated a bit more the idea. But for example, I would have like at least emmapeel and u to be part of this discussion and I’m not sure they were even aware it was happening. That was for me the meaning of the word “everybody” in the description of this ticket.

Also note that intrigeri’s last comment in Feature #9216#note-12 was a question made 2 months ago and left unanswered…

All-in-all, I’m not that happy with how it went. But now we’re too close to the deadline to question this any further, so of course we’ll use bootstrap. I guess that using it in the Installation Assistant without touching the rest of the website can be a good initial test.

Anyway, I’m marking this as “resolved” despite the doubts I’m raising here…

#15 Updated by intrigeri 2018-09-05 07:04:57

• related to Bug #15749: Use Bootstrap everywhere on the website added