[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] [Brainstorming] Why (not) a "Final Daze" in SimRel?

Hi all,

You probably all noticed the "Final Daze" email recently. That has brought some questions and concerns for some newcomers. I'll go into details in a few lines, but first, I'd like to ask these generic questions: What is the value of the Final Daze? What's its cost?

For the cost it's obvious:
* releng effort for any participating projects (setting up p2.mirrorsUrl for instance)
* delaying of the release of the individual project although it's ready and approved
* Deadlines don't scale: what happens if a project owner cannot move the bits on the right time to the right place?
* delaying announcement -although a particularity of some project makes it better to announce release immediately...

For the risk: tweaking p2 metadata to set up p2.mirrorsUrl in the last week before release is definitely something most of us would prefer to avoid, especially in the context of a "Daze".

For the value, it's more discussable:
* end-users only care about SimRel repo, EPP packages and installer. Those are the only artifacts they face. They're actually not much dealing with individual p2 repos, so all optimization regarding p2.mirrorsURL at that point of time most likely have a very low impact on users and bandwidth in general.
* Doesn't the Foundation plan to enable a transparent mirroring system very soon that would make all this p2.mirrorsUrl useless?
* Making deliverables invisible: same as the topic about p2.mirrorsUrl. Do actual end-user hit the project repository directly? And if they do in advance while the release is ready, why not letting them do so? Blocking release availability isn't really making projects feel more agile thanks to SimRel...


Overall, I have the impression that this Final Daze of SimRel adds some complexity, constraints and stress there for some cost of project, and no added-value to typical end-users.
It would most likely be better to get rid of some of those timing constraints, let project release as usual they want/can conforming to the usual processes -even if it's earlier-, and focus on the actual entry point of Simultaneous Release which is the SimRel repo without putting additional pressure on projects.
So just abandoning the Final Daze TODO-list would be a good simplification.

What do you think?
--
Mickael Istria
Eclipse IDE developer, at Red Hat Developers community