Am 16.06.2015 um 23:33 schrieb Emmanuel Bourg: > Le 16/06/2015 20:37, Markus Koschany a écrit : > >> Thanks for the upload. However I feel that this is another "double work" >> situation again. (you probably remember the javahelper case). In my >> opinion we should have continued to work on bnd1. I am always open for >> improvement suggestions and of course I would have fixed all remaining >> issues myself. Thanks btw for fixing jsch-agent-proxy so quickly. > > Well, I was concerned about the missing history, but as you said it > wasn't absolutely necessary. I didn't want to bother you with this > aspect and made the changes myself. I used your package as a guide > though, so that wasn't really a double work. Ok, I'm glad that you don't perceive it as double work and I have always appreciate it that members of this team fix minor issues themselves. > I have put some thought in bnd1, for example my package >> was co-installable whereas bnd-1.50 breaks/replaces bnd <= 2 now. I >> don't expect any fatal problems with this decision but this was also >> true for bnd1. > > I don't mind changing this once the package is in unstable. Note that > bnd1 wasn't co-installable either, the Maven artifacts in > /usr/share/maven-repo and the versioned jars in /usr/share/java were > conflicting. piuparts would have bitten us quickly with a RC bug against > both packages. I should have been more precise. My intention was that bnd1 and the current bnd package in experimental were co-installable. That's why I changed the symlinks in /usr/share/java. The plan was to move all packages, which would be broken by an upload of bnd 2.1.0 to unstable, to the new transitional package bnd1. After that we could upload bnd 2.1.0 from experimental and all remaining r-deps to unstable. I never envisioned that it should be possible to install bnd with version 1.50 and bnd1 with version 1.50. > I also think that we don't really need the packaging >> history because it is clear to everyone that the bnd repository contains >> all historical information. I would treat bnd1/bnd1.50 simply as a new >> package with a clean Git history whose sole goal is to simplify the >> transition to bnd2 and then we should get rid of it as soon as possible. >> There is no need for fancy Git magic. > > I'm just prudent, sometimes temporary things last much longer than > expected. If the 1.50 package was to remain in Stretch I'd feel better > if it had a full and self contained history. I understand where this assessment comes from. However I believe the current bnd repository provides all necessary information. I'm just pragmatical. I'm not very much interested in bnd but I want the transition to be a success because it affects so many different packages. My personal goal is to remove the transitional package bnd1.50 before the next freeze. In general I believe we should be more aggressive with transitions. Especially packages with low popcon values, "one-time-fire-and-forget uploads", everything that is not very important and fails to build with recent versions should be removed from Debian. We should be more stringent in those cases and avoid supporting multiple versions of the same package. >> The issue with bnd's upstream branch was that someone forgot to push the >> old 1.50 upstream sources when bnd 1.50 was released. Miguel was the >> first one who created an initial upstream branch for bnd and pushed the >> 2.1.0 sources. I don't perceive the current situation as an issue >> because Git master reflects the current state of affairs in unstable and >> you still can work with bnd 2.1.0 on the experimental branch. So I am >> confident everything will be resolved when we eventually upload 2.1.0-2 >> to unstable and re-import everything with gbp import-dsc on Git master. > > The messy history on the master branch is bothering though :/ I'm not > blaming anyone, I understand well it was the result of a benign gbp > misuse. Git makes this easily fixable and I'm willing to do the work > necessary to restore a chronological history. But before proceeding I'd > like to ensure Miguel and you do not have pending changes, since the > rebasing would prevent you from pushing them. Ok, this is something that doesn't bother me very much because I think it will be fixed with the upload of bnd 2.1.0 to unstable. I don't have anything else to commit, from my side, please go ahead. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature