[opensuse-buildservice] Draft Concept Source Branching in the BS
Hi, we're currently thinking about how we improve the build service to allow more cooperation: People should be able to change projects that are not maintained by them and propose these changes to the maintainers of the project. Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts I am looking forward to reading your feedback, thanks, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 03 September 2007 10:24:40 wrote Klaas Freitag: ..
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
I am looking forward to reading your feedback,
[Details] "In case the user does not have write permission to the project, a branch of the base project is created by the API." I would just keep in mind, that a user might want still branch, even if he has write permissions. For example for pre-testing a change, which is maybe risky. [API Calls] It does look that you want alsa allow branching of a complete project. How would that work ? I suppose either 1) create new project and create source links for each package or 2) create a new mechanism which allows linking of projects. [API Calls] The "/source/home:<person>/_branchprojects" should maybe /source/home:<person>/_branchprojects/<project> because of handling multiple project branches. [Branch Notifier] Do you really want to create notifications when branching ? Isn't this something what should get defined later in a generic event notification proposal ? Shouldn't this be called "Merge request notifier" here ? Apart from my comments, I think your proposal describes the needed api tasks completely :) We may should also create some end-user workflows dealing with typical use cases to get also a picture what needs to done in the clients. Do you have any opinion how the actual merge should be done ? Will it happen in the backend like it happens already when you have source linked + patched packages ? bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 03 September 2007 10:51, Adrian Schröter wrote:
[Details] "In case the user does not have write permission to the project, a branch of the base project is created by the API."
I would just keep in mind, that a user might want still branch, even if he has write permissions.
That's correct.
[API Calls] It does look that you want alsa allow branching of a complete project. How would that work ? Yes, branching a project would be POST /source/<project>?cmd=branch
I suppose either 1) create new project and create source links for each package or 2) create a new mechanism which allows linking of projects. Not sure - needs more discussions ;-)
[API Calls]
The "/source/home:<person>/_branchprojects" should maybe
/source/home:<person>/_branchprojects/<project>
[Branch Notifier]
Do you really want to create notifications when branching ? Isn't this something what should get defined later in a generic event notification proposal ? Shouldn't this be called "Merge request notifier" here ? Probably it should be 'Merge Request'. And I think it needs to be saved somewhere because it holds the information that for a branch
Yes, thats what I meant. project was asked to merge.
Apart from my comments, I think your proposal describes the needed api tasks completely :) We may should also create some end-user workflows dealing with typical use cases to get also a picture what needs to done in the clients.
Yes, next task.
Do you have any opinion how the actual merge should be done ?
Puh - to be honest, I need some input here. From my feeling I doubt that it is possible to do that completely automagically. And I wonder if that is needed - I think that no maintainer will trust an automatic change of his package.
Will it happen in the backend like it happens already when you have source linked + patched packages ? I have to check that, any opinions on that?
Thanks, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Monday 03 September 2007 16:51:14 wrote Klaas Freitag:
On Monday 03 September 2007 10:51, Adrian Schröter wrote: ...
Do you have any opinion how the actual merge should be done ?
Puh - to be honest, I need some input here. From my feeling I doubt that it is possible to do that completely automagically. And I wonder if that is needed - I think that no maintainer will trust an automatic change of his package.
Will it happen in the backend like it happens already when you have source linked + patched packages ?
I have to check that, any opinions on that?
Well, an automatic/backend merge is possible if the patches do apply. But the nice thing is that you can see this before, because otherwise the source preparation during build will fail also. So we can either say 1) submit fixed source changes which do apply 2) request backend to do the merge. A problem appears when the original project/package owner wants to merge, but the source do not apply currently (for example, because the same person merged another change right before). In that case, the target project owner would need to fix the source before (what he may wants to do), but that means that he needs either to write it into requester project (bad idea, and he even has most likely no permission for it) or he needs to copy the project before. This is IMHO a serious possibility, if our tools make this easy. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello,
we're currently thinking about how we improve the build service to allow more cooperation: People should be able to change projects that are not maintained by them and propose these changes to the maintainers of the project.
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
I am looking forward to reading your feedback,
Rather than introducing a new system, why not unify the _link, _aggregate and your branch idea? Would be much nicer. a) Propagate links and aggregates back to the original project, so it is possible to see, where the own data is used (equals your list command). b) Allow better handling of patches: - Allow to edit the patched files and recreate a patch from it (instead of download and handmaking patches). c) Unify link and aggregate to minimize rebuilds but also to reduce equal packages (e.g. allow aggregate with rebuild for non-existing targets). d) Add your notification system in a slightly modified way. I did some branching the way, that I linked the project in my home, modified it and then told the original maintainer to incorporate the diffs. Worked fine for Factory ocaml related packages. Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hello,
we're currently thinking about how we improve the build service to allow more cooperation: People should be able to change projects that are not maintained by them and propose these changes to the maintainers of the project.
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
I am looking forward to reading your feedback,
Rather than introducing a new system, why not unify the _link, _aggregate and your branch idea? Would be much nicer.
a) Propagate links and aggregates back to the original project, so it is possible to see, where the own data is used (equals your list command). In my proposal there is no finer classification what "creating a branch
On Monday 03 September 2007 11:29, Dirk Stoecker wrote: project" means yet. That's simply because I am not sure yet, and I would not exclude linking or aggregating.
b) Allow better handling of patches: - Allow to edit the patched files and recreate a patch from it (instead of download and handmaking patches). That's a good idea.
d) Add your notification system in a slightly modified way. What modifications are you thinking of?
I did some branching the way, that I linked the project in my home, modified it and then told the original maintainer to incorporate the diffs. Worked fine for Factory ocaml related packages. Yes, but we like to have a more "organised" way :-)
Thanks for your feedback, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, 3 Sep 2007, Klaas Freitag wrote:
Rather than introducing a new system, why not unify the _link, _aggregate and your branch idea? Would be much nicer.
a) Propagate links and aggregates back to the original project, so it is possible to see, where the own data is used (equals your list command). In my proposal there is no finer classification what "creating a branch project" means yet. That's simply because I am not sure yet, and I would not exclude linking or aggregating.
Fine. I think there is lots of potential in link and aggregate, which is not used at all at the moment.
b) Allow better handling of patches: - Allow to edit the patched files and recreate a patch from it (instead of download and handmaking patches). That's a good idea.
When doing so, don't forget a conflict management in "<<<<" diff style.
d) Add your notification system in a slightly modified way. What modifications are you thinking of?
Make a prototype and I'll tell you :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
I just want to add to this thread that we should also think about how we adress projects or packages of other build service instances in future. This is important to get cross instance community work on the run and we should define this already in the branch and merge requests. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Sep 03, 2007 at 10:24:40AM +0200, Klaas Freitag wrote:
we're currently thinking about how we improve the build service to allow more cooperation: People should be able to change projects that are not maintained by them and propose these changes to the maintainers of the project.
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
- I don't think we need new API calls, branching is just creating a new project and copying a package into it. - It should be easily possible to branch into existing projects, especially the home project. Creating extra projects comes with a cost and is only needed for few projects. - Is <project> and <package> describing the branched package or the original package in the branch notifier? As branches are per project, should they live in /source/<project>/_branches? - Is there an order on the branch notifiers? How about a time stamp? - The "list all pending branches for a user" should be a search request instead of a special path. - We also need support for reviewers (aka package maintainers). i.e. state "reviewed". Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Mon, Sep 03, 2007 at 10:24:40AM +0200, Klaas Freitag wrote:
we're currently thinking about how we improve the build service to allow more cooperation: People should be able to change projects that are not maintained by them and propose these changes to the maintainers of the project.
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
- I don't think we need new API calls, branching is just creating a new project and copying a package into it. No, please have a new API call, because we can add other activities
- It should be easily possible to branch into existing projects, especially the home project. Creating extra projects comes with a cost and is only needed for few projects. For projects with write permissions it might be possible to branch into, but the usual usecase would be that you do not have permission. And I would not like to weaken the permission concept with exceptions
On Monday 03 September 2007 18:13, Michael Schroeder wrote: that should happen if a package is branched like writing to a statistics table etc, sending notifications etc. like "You can not write except branches".
- Is there an order on the branch notifiers? How about a time stamp? Yes, see creationDate attribute. I change it to creationTS
- The "list all pending branches for a user" should be a search request instead of a special path. Correct. So GET /search/branches/<username> and GET /search/branches/project should return a result. However I would also support the GET on the branch dirs.
- We also need support for reviewers (aka package maintainers). i.e. state "reviewed". Added. And changed the state changing requests a bit
Thanks, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 04 September 2007 10:21, Klaas Freitag wrote:
Yes, see creationDate attribute. I change it to creationTS
creationTS is pretty cryptic. What about "created"?
--
Cornelius Schumacher
On Monday 03 September 2007 10:24, Klaas Freitag wrote:
Please read a DRAFT concept for this what we call branching of sources under http://en.opensuse.org/Build_Service/Concepts
The general concept looks fine to me. As a side note: I would focus on the
merging aspect, not on the branching aspect. If merging is too hard,
branching doesn't make much sense.
Some comments about the API:
- Wouldn't it be more consistent to use the namespace notation for the
branches, so call a branch "home:<person>:branches:branchProjectName" instead
of "home:<person>/_branchprojects/branchProjectName"?
- How is the tracked from which project the branch originates?
- Why not call the branch notifier "merge request"? That sounds more like what
is meant to be to me. For the XML I would then use something like:
<branchrequest>
<branch project="home:myname/branches/coolproject">
<state>new</state>
</branchrequest>
- What is the meaning of the "name" and "desc" elements in the merge request?
- Maybe it would be better to store the merge requests in an own hierarchy
instead of the source tree, so use "GET/
PUT /branch/<project>/<package>/_branchrequest" instead
of "/source/_branches". The requests aren't really source data, so it would
be a bit confusing to have them in the source tree.
- For listing the branch requests of a user it would probably be better to use
a parameter instead of a pseudo path element, so something
like "GET /branch/?user=<username>" instead
of "GET /source/home:<person>/_branchprojects".
- As accepting a merge request has effects like merging in patches on the
merged project it could be better to use a POST request with a command
instead of the "PUT /source/_branchnotifiers/project". It's clearer, if the
PUT is only used for writing a resource without side effects.
--
Cornelius Schumacher
On Monday 03 September 2007 18:20, Cornelius Schumacher wrote: Hi,
The general concept looks fine to me. As a side note: I would focus on the merging aspect, not on the branching aspect. If merging is too hard, branching doesn't make much sense. True, however even if merging has to be done by hand, merge requests still are usefull - or did I get something wrong here?
- Wouldn't it be more consistent to use the namespace notation for the branches, so call a branch "home:<person>:branches:branchProjectName" instead of "home:<person>/_branchprojects/branchProjectName"? Hmm, no. Since branch projects are still real projects, I think they should use the normal directory notation.
- How is the tracked from which project the branch originates? For simplicity, from the project- and package name. However I realise that I have to remove the optional names from the branch API call ;-)
- Why not call the branch notifier "merge request"? That sounds more like what is meant to be to me. Yes, changed that.
- What is the meaning of the "name" and "desc" elements in the merge request? Name: "Make it all cool patch" Desc: "This patch adds the ability to fly to the project" I thought it might be usefull to find out what the patch is about also without reading the patch ;-) And basic rule: Everything needs a name.
- Maybe it would be better to store the merge requests in an own hierarchy instead of the source tree, so use "GET/ PUT /branch/<project>/<package>/_branchrequest" instead of "/source/_branches". The requests aren't really source data, so it would be a bit confusing to have them in the source tree. Correct, but I think we should have a toplevel dir /requests because there probably will be more like rename, drop, etc requests.
- For listing the branch requests of a user it would probably be better to use a parameter instead of a pseudo path element, so something like "GET /branch/?user=<username>" instead of "GET /source/home:<person>/_branchprojects". Yes, changed.
It's clearer, if the PUT is only used for writing a resource without side effects. Also accepted.
Thanks for the feedback, Klaas -- Klaas Freitag Architect OPS/IPD SUSE LINUX Products GmbH - Nuernberg --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Tuesday 04 September 2007 10:08, Klaas Freitag wrote:
On Monday 03 September 2007 18:20, Cornelius Schumacher wrote:
The general concept looks fine to me. As a side note: I would focus on the merging aspect, not on the branching aspect. If merging is too hard, branching doesn't make much sense.
True, however even if merging has to be done by hand, merge requests still are usefull - or did I get something wrong here?
Merge requests are certainly useful. I just wanted to say that the hard problem of branching is not creating the branch, but merging it back and we should put enough effort into the merging part to make this a good experience for the user.
- Wouldn't it be more consistent to use the namespace notation for the branches, so call a branch "home:<person>:branches:branchProjectName" instead of "home:<person>/_branchprojects/branchProjectName"?
Hmm, no. Since branch projects are still real projects, I think they should use the normal directory notation.
But normal projects don't use directory notation. They use the colon notation.
- Maybe it would be better to store the merge requests in an own hierarchy instead of the source tree, so use "GET/ PUT /branch/<project>/<package>/_branchrequest" instead of "/source/_branches". The requests aren't really source data, so it would be a bit confusing to have them in the source tree.
Correct, but I think we should have a toplevel dir /requests because there probably will be more like rename, drop, etc requests.
Sounds reasonable.
--
Cornelius Schumacher
participants (5)
-
Adrian Schröter -
Cornelius Schumacher -
Dirk Stoecker -
Klaas Freitag -
Michael Schroeder