Togan Muftuoglu - 20:26 2.12.13 wrote:
"Michal" == Michal Hrusecky <mhrusecky@suse.cz> writes:
Michal> Hi, Michal> we are having a nice torrent of ideas in this mailing list since coolo Michal> presented this proposal last Thursday: Michal> https://progress.opensuse.org/workflow/factory-proposal.html
Michal> Some of them are related to staging projects, so I will try to Michal> expand further one of the options regarding what could be Michal> happening inside that dashed box in the diagram.
Thanks for the explanation, as the boxes in the proposal was not easy to follow with my eyes ;)
Michal> 2.2) The submitter coordinates with people who maintain packages Michal> that got broken. That means several people working on several Michal> packages (very often from different devel projects) all together Michal> to fix the new staging project. The fixes can be done in the devel Michal> projects or directly in the staging project.
I am not sure I understand how this one work. For example in one of the gcc staging phase, there was a list of broken packages sent to factory list. I am thinking we want to automate this, rather than sending a list of packages that is manually compiled and send to factory.
In case of gcc new staging project will get created and we will wait a reaaaaallly long time as everything depends on it :-D Than we will have staging project where there are quite some packages failing. We can list only failing packages, but we can simply point people to the web monitor of this staging project.
So in this new approach how is it planned to coordinate effort to fix the failing packages ?
It is just an idea, one of many possibilities. In gcc case, we should probably call for project wide help, but gcc maintainer will probably know the most frequent cases and probably could do some mass submission to fix them.
Michal> This is just a proposal on how staging projects could work. The Michal> main goal of this proposal is to partially move the responsibility Michal> of the integration process into the community of packagers so: - Michal> Staging project maintainer has to cooperate with package Michal> maintainer to get his SR in. - Package maintainers have motivation Michal> to fix their stuff, otherwise new versions don't get included.
What is the delegation of work if the package maintainer is not responding in a timely manner ?
Well, we should probably detect and handle inactive maintainers in general, but that would be out of scope of staging projects. We should somehow handle packages that nobody fixes, packages with security bugs nobody cares about and similar. Currently there is a group called confusingly 'factory-maintainers' that acts as backup for maintainers, but in general, I would leave this open and we can address inactive contributors later in discussion more generally ;-)
Michal> The main advantages if this approach are: Michal> - Everything has to go through package maintainer to make sure Michal> changes don't get lost, package maintainers knows about the problems Michal> and agrees with the solution Michal> - We move from one good state to another, accepting only changes Michal> together with fixes.
Michal> What do you think? What do you like/dislike? Opinions?
Overall sounds fine to me.
Glad you like it :-) -- Michal HRUSECKY SUSE LINUX, s.r.o. openSUSE Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org