On Sunday, 20 April 2014, Paul Allen <pal...@perforce.com> wrote: > Hi Guys, > > Sorry I han't been checking email over the Easter break. > > I like Kohsuke Kawaguchi's idea of running the two together, it will allow > user to try out the now plugin and provide feedback. I'm not sure how easy > it would be to provide a migration path for each Build Job's configuration, > but this would simplify adoption. > > ... Just seen Jesse's post; perhaps I don't appreciate the differences. > Allowing the two code bases to co-exist (effectively two plugins in one). > The UI can than just show Perforce-1 / Perforce-2; as we progress this > could change to Perforce-Deprecated / Perforce, then finally just Perforce. > > > [Steve RE: Credentials] > The new plugin extends Jenkins Credentials into two new types. Perforce > Password credential and Perforce Ticket credential; these both support SSL > and P4TRUST finger prints. I did look at the password and SSL credentials, > but Perforce has some specifics P4TICKETS etc..
Sounds like you've implemented one too many. You should not be implementing a user+pass credential type at all. The ticket credential type is fair enough... In principle (I have not looked at your code mind) > > I had tried to make the SCM polling more efficient and letting Perforce > manage it's own workspaces, after all this is what Perforce was designed to > do. I was not aware of the 'SCM-API', is there any docs/guide like: > > https://wiki.jenkins-ci.org/display/JENKINS/SCM+plugin+architecture No docs yet. It's needed to allow multi-branch support ala literate project type (though no limited to literate) Subversion, git and hg all have implementations of the SCM-api. It impacts polling as you want to expand the scope of what you find info about, so eg * subversion maintains a map of latest revisions of various paths... This map will in future be used to reduce the amount of polling that jobs need... At present only literate takes advantage of the map (waiting until I feel the credentials support has bedded down) * git and hg maintain a local checkout which (git) can be used / (hg) is used to speed up checkout on slaves and reduce the amount of querying Once SCM-api us fully integrated these plugins will have effectively much more performant polling whereby eg push notifications get merged into local stores so that 99% of polling operations are served from a local cache (fed by both other jobs off same repo and push notifications) > As Oleg mentioned there are features that I haven't had time to port; > these shouldn't take long but I would like to involve the community and > especially the authors. > > I'm back in on Tuesday; will try and keep an eye on the posts... > > Thank you all for your involvement, I'm pleased there is so much interest > and help. > > Kind regards, > Paul > > > On 18 Apr 2014, at 18:46, Rob Petti <rob.pe...@gmail.com> wrote: > > > I didn't realize that you could release two versions of a plugin at the > same time to two different update centers. I think your proposal is > probably the best option here. > > > > > > On Fri, Apr 18, 2014 at 11:31 AM, Kohsuke Kawaguchi < > kkawagu...@cloudbees.com> wrote: > > > > I'm waiting for Rob and Paul to agree on the approach forward. I think > we'd be happy to honor that, since you guys are the ones that are doing the > actual work. > > > > > > Where Jesse and I are coming from is to try to understand the message to > the existing users, because Perforce plugin is widely used. > > > > > > If you expect both current and new plugins to co-exist going forward, > that's the least preferable outcome from users' PoV. > > > > The next better one is that you expect the current plugin to become > dormant and all the efforts to go to the new plugin. It's still disruptive > for users, but at least there's a clarity in the direction. > > > > The next better one is that you two agree that the current plugin will > become dormant and the new one will take over, then we work out the data > migration compatibility between the current and new plugin, without > preserving code compatibility. This is pretty good for users, as they don't > have to go through disruptive changes. > > > > Then the final one is to try to maintain some/all of the code > compatibility. If there are plugin out there that depends on the perforce > plugin, this will make their users happy. > > > > > > Without much experience of Perforce, what I'd like to encourage you to > consider is the third option, and here is one way of doing it. > > > > We could put both current and the new in the same repo, and call the new > one "perforce plugin 2.0." They need not share the code at all. 2.0 would > work toward feature parity with 1.0. Existing Jenkins devs can help create > migration shim in the 2.0 branch. > > > > We can have alpha/beta releases of 2.0 in parallel to updates to 1.x > releases. People on the beta update center will get this 2.0 beta versions. > When 2.0 is in feature parity, we can have the official 2.0 release. > > > > Or if we discover that feature parity is unattainable, we can rename the > new version to another name and release it as a separate plugin. > > > > > > > > > > On 04/18/2014 02:33 AM, Paul Allen wrote: > > Hi Rob, > > > > The refactoring effort would be so wide spread there would be very > little, if anything, left. > > > > By removing the underlying p4 command wrapper (Tek42) and replacing it > with the p4-java api would require a re-write of all the functions. In > addition the behavioural changes to the use of Perforce workspaces and > authentication would change most of the user interface. > > > > I suggest that we either create a new plugin 'p4' or fork/rename the > existing plugin. A new plugin would be less disruptive to the existing > user base and give the opportunity for a clean start. > > > > Paul > > > > On 17 Apr 2014, at 19:23, Rob Petti <rob.pe...@gmail.com> wrote: > > > > I thought it was decided that refactoring the old plugin was the better > way to go? It's less of an impact on users, and preserves all of the > required functionality. > > > > If not, then just make a new repo, I guess... > > > > On Thursday, 17 April 2014 10:52:20 UTC-6, pallen wrote: > > I have been discussing the plugin for sometime over email. > > > > I'll CC Rob and the others... > > > > Paul > > > > On 17 Apr 2014, at 16:59, Jesse Glick <jgl...@cloudbees.com> wrote: > > > > > On Thu, Apr 17, 2014 at 11:51 AM, Paul Allen <pal...@perforce.com> > wrote: > > >> Whilst the new plugin provides all the basic SCM functions, it is not > yet as feature rich. We plan to add features [...] > > >> > > >> [...] perhaps there is a way to branch (fork) the old codebase into a > legacy area? > > > > > > > > A bit more work, but arguably better for users, would be to include > > > the new refactored implementation inside the existing plugin (in trunk > > > versions). For a time, users of the plugin would see two SCM > > > options--Perforce (v1) and Perforce (v2)--with somewhat different > > > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
