Hi,
I'd have thought that Factory submissions are going through OBS and through the respective development project set for the package? Once again that wasn't the case for two packages mozilla-nspr and mozilla-nss where new packages were already waiting in the mozilla:Factory project for inclusion in Factory.
Sorry, that happens far too often for me and I certainly won't always merge back the stuff to the package in the development project.
Can someone official please enlighten me if it's ok to destroy other's work by bypassing the normal procedures?
Yes, I'm really annoyed by that happening all the time.
Wolfgang
h_root schrieb:
Hello community,
here is the log from the commit of package mozilla-nspr for openSUSE:Factory checked in at Fri Jan 9 01:35:21 CET 2009.
--- GNOME/mozilla-nspr/mozilla-nspr.changes 2008-06-18 02:46:16.000000000 +0200 +++ /mounts/work_src_done/STABLE/mozilla-nspr/mozilla-nspr.changes 2009-01-07 11:06:51.000000000 +0100 @@ -1,0 +2,5 @@ +Wed Jan 7 12:34:56 CET 2009 - XXX@suse.de
+- obsolete old -XXbit packages (bnc#437293)
+-------------------------------------------------------------------
On Freitag 09 Januar 2009 08:46:31 Wolfgang Rosenauer wrote:
Hi,
I'd have thought that Factory submissions are going through OBS and through the respective development project set for the package?
We (or better the osc tool) do route changes by default to the development project yes.
But we do not forbid submissions bypassing this. This is not the recommended way, but may be necessary in some cases (see below).
However, in the end you should get these changes automatically when you use source links. Yes, concflicts can appear and need get merged manually like with cvs, svn and friends as well.
Once again that wasn't the case for two packages mozilla-nspr and mozilla-nss where new packages were already waiting in the mozilla:Factory project for inclusion in Factory.
Sorry, that happens far too often for me and I certainly won't always merge back the stuff to the package in the development project.
Can someone official please enlighten me if it's ok to destroy other's work by bypassing the normal procedures?
Yes, I'm really annoyed by that happening all the time.
I have not checked what kind of submissions these are in your case.
I heard that Rudi needed to fix several hundred packages (all with the same fix) to get Factory building again after an incompatible change in a base package. This is a situation where we do not want to ask and wait for feedback from each maintainer, because we need Factory working ASAP.
If there are other contributions, which could have submitted to your project, please ask the people direct to do this in future.
Yes, we have the general policy that people should use the development project. But in the end it is just a recommendation, because the way how people develop their packages differs a lot (this is partly caused also by the upstream project).
So, please try to find a solution with the people. CC me if you want feedback (or give feedback to OBS) during this.
thanks a lot for your work adrian
and happy new year :)
Wolfgang
h_root schrieb:
Hello community,
here is the log from the commit of package mozilla-nspr for openSUSE:Factory checked in at Fri Jan 9 01:35:21 CET 2009.
--- GNOME/mozilla-nspr/mozilla-nspr.changes 2008-06-18 02:46:16.000000000 +0200 +++ /mounts/work_src_done/STABLE/mozilla-nspr/mozilla-nspr.changes 2009-01-07 11:06:51.000000000 +0100 @@ -1,0 +2,5 @@ +Wed Jan 7 12:34:56 CET 2009 - XXX@suse.de
+- obsolete old -XXbit packages (bnc#437293)
+-------------------------------------------------------------------
Hi,
Adrian Schröter schrieb:
On Freitag 09 Januar 2009 08:46:31 Wolfgang Rosenauer wrote: But we do not forbid submissions bypassing this. This is not the recommended way, but may be necessary in some cases (see below).
I can't really say if it was necessary because the mentioned bug is as always a closed one as in most of these cases but I seriously doubt it given the nature of the changes.
However, in the end you should get these changes automatically when you use source links. Yes, concflicts can appear and need get merged manually like with cvs, svn and friends as well.
Turn it into "conflicts will appear" in any case usually if only just because of the *.changes change and I'm tired having to fix stuff other people broke. And to give some feedback to OBS: Resolving conflicts in source linked packages is a real PITA.
If there are other contributions, which could have submitted to your project, please ask the people direct to do this in future.
I did that for the several last occassions but I'm also tired of that since usually random people within Novell are doing submissions through autobuild and I don't want to have to notify each of them. As long as using OBS and osc is just a weak "recommendation" inside of Novell I'll stop contributing directly to a *:Factory/Factory-development project. Interested maintainers can still get my stuff from my own projects if they like since they have to touch and review the stuff anyway and if not I should just stop to care.
Yes, we have the general policy that people should use the development project. But in the end it is just a recommendation, because the way how people develop their packages differs a lot (this is partly caused also by the upstream project).
No, the issue here is that Novell internal people drive by changing stuff in foreign packages and don't know anything about the "non-written" rules (while the official maintainer does in most cases) of the respective package. Usually there is no problem with the dedicated maintainers.
Wolfgang
On Freitag 09 Januar 2009 12:19:37 Wolfgang Rosenauer wrote:
Adrian Schröter schrieb:
On Freitag 09 Januar 2009 08:46:31 Wolfgang Rosenauer wrote: But we do not forbid submissions bypassing this. This is not the recommended way, but may be necessary in some cases (see below).
I can't really say if it was necessary because the mentioned bug is as always a closed one as in most of these cases but I seriously doubt it given the nature of the changes.
However, in the end you should get these changes automatically when you use source links. Yes, concflicts can appear and need get merged manually like with cvs, svn and friends as well.
Turn it into "conflicts will appear" in any case usually if only just because of the *.changes change and I'm tired having to fix stuff other people broke. And to give some feedback to OBS: Resolving conflicts in source linked packages is a real PITA.
Yes, I agree that the missing merge handling is badly missing for too long time.
If there are other contributions, which could have submitted to your project, please ask the people direct to do this in future.
I did that for the several last occassions but I'm also tired of that since usually random people within Novell are doing submissions through autobuild and I don't want to have to notify each of them. As long as using OBS and osc is just a weak "recommendation" inside of Novell I'll stop contributing directly to a *:Factory/Factory-development project. Interested maintainers can still get my stuff from my own projects if they like since they have to touch and review the stuff anyway and if not I should just stop to care.
Yes, we have the general policy that people should use the development project. But in the end it is just a recommendation, because the way how people develop their packages differs a lot (this is partly caused also by the upstream project).
No, the issue here is that Novell internal people drive by changing stuff in foreign packages and don't know anything about the "non-written" rules (while the official maintainer does in most cases) of the respective package. Usually there is no problem with the dedicated maintainers.
Hm, I do not think that this has something to do with the two worlds of inside and outside of Novell.
We have basically an open system, so that in general everyone with write access can write everywhere. This works also quite well in projects like KDE, where only social rules prohibit people to submit not well enough tested stuff into base libs.
Our main goal for this year is to improve the source handling (and stuff like content from internal frameworks like our package database). So I hope you like to hear that there will be some progress in this direction this year. However, we are still in the planing phase.
I see it this way. We have already a system which helps you more than other systems when underling changes happens with the source links.
The current disadvantage is that conflicting changes are badly handled atm. Yes, we need to improve this as soon as possible.
bye adrian
Le vendredi 09 janvier 2009, à 12:36 +0100, Adrian Schröter a écrit :
The current disadvantage is that conflicting changes are badly handled atm. Yes, we need to improve this as soon as possible.
Is there a bug or a fate entry open about this?
Quite often, the two main issues with merging, afaik, are changes .changes and automatic updates to the release tag. At least for .changes, it sounds possible to handle the file in a different way than a diff.
Thanks,
Vincent
On Fri, 2009-01-09 at 12:36 +0100, Adrian Schröter wrote:
The current disadvantage is that conflicting changes are badly handled atm. Yes, we need to improve this as soon as possible.
I can't help but get the feeling that a lot of work could've been avoided if we just backed the OBS with an existing, well-maintained DVCS like git or bzr. Is it impossible to do at this stage?
-
Adrian Schröter -
Hans Petter Jansson -
Vincent Untz -
Wolfgang Rosenauer