On Oct 7, 2009, at 3:02 PM, Peter Meier wrote: > >>> What about all the forks? Many people provide their modules as a git >>> repository and people fork them and start hacking their own changes. >>> With the linear model of version numbers we don't have any >>> possibility >>> to differentiate between a module foo that have been forked from 2.0 >>> and >>> evolved to 2.1 and the original module that might have been improved >>> to >>> version 2.1 . If you look at the current reality there are plenty of >>> such modules. >>> >>> For sure the main goal to fix that is the common modules project, >>> however if we introduce a formal description which modules work >>> together >>> or require another in a certain version we should be able to >>> distinguish >>> forks as well. Otherwise we might end up with a lot of people who >>> take >>> module foo from x in version 1, which requires module bar in version >>> 2.1 >>> but instead to take the actual version from x they take the fork >>> from y. >>> So somehow we need to be able to the actual version. >> >> Any suggestions for this? > > Not really. We would need something like a unique identifier to > which we > could refer. On the other side it might be sufficient to mention the > refered module with source in the README and if people mix that up...
True; and a basic 'forked-from' attribute wouldn't be bad, I guess. > >> I haven't been worrying too much about parallel versions in forks >> because 1) I'm assuming that people will only ever have a single >> version installed at a time and 2) Puppet can only deal with a single >> module with a given name, so there isn't much opportunity for >> conflict. > > more or less yeah, but for example if I look to all the apache modules > out there for example I think that quite everyone is completely > different. I think that's mostly a namespace collision problem - multiple people making competing modules. That will sort itself out over time as we have central repositories people can refer to. > >> In the end, we can only usefully talk about dependencies within a >> subset of modules that exist, and my assumption is that we'll >> generally have two subsets we operate on: The modules installed, and >> the modules available in whatever repositories we're looking at. It >> should be straightforward to manage forks (or not support them) >> within >> that subset. > > that should be fine. > >> That being said, I'm happy to find a solution here, but I'm not sure >> it fits under the "simplest solution that provides a benefit", which >> is what I was shooting for initially. > > I don't think it have to be in the very first version and I think we > should start without this issue. But I think some time we should try > to > find a good solution for it. I agree. I think a lot of it will get sorted out as people start to use this minimal behaviour. -- Always behave like a duck - keep calm and unruffled on the surface but paddle like the devil underneath. -- Jacob Braude --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
