RPM4.6 vs RPM5 Take 2

[gettinther]

Guys,

I've reviewed the information available around in terms of technical merit and wrote up a doc about it.  Can you guys please review the document and make final comments here?  I hope to have the vote started and completed this week.

Cheers

[CPunltd]

Understandably, the faster one to be developed is not the choice of "commercial" distros nor a current standard... but efficiency has never played a true role in corporate scenarios and is always frowned upon.  I say stay ahead of the times.  It's nice that 4.6 will eventually have this feature and that, but the question is, why wait?  All in all, I can't see any real advantage to taking the slower path.  We can always take the faster path and slow down as we need to.... it's easier on gas mileage to slow down than it is to speed up.

[gettinther]

I think using rpm5 would "make us different" from the Mandriva parent and lend us more credibility but this is more a "marketing" point.

[Zoltan]

I think we as a community we could lend a hand to test out RPM5, and make it better. If help them, we help on ourself. If our base will use RPM5, maybe we'll become an maintainer group, and an stable background dev base, what Red Hat surely will observe. Python and the other capabilities from RPM 5, could mean better and faster package handling, and who knows - an possible new de facto standard - fully or partially - later, if we make with care. I think we could build something new with packagekit (servicepacks, metapack system, aso.), and not be judged by public as an "another fork again". This maybe means that we step away from mandriva packs, and problems - but better and easier to learn something new, and start with clean 'new page'.

[Sal]

I think using rpm5 would "make us different" from the Mandriva parent and lend us more credibility but this is more a "marketing" point.

That "marketing" point is a two edged sword, there are many that would then perceive us as being just a "fringe distro", not having it's roots in the mainstream and as such hurt our credibility. cAos & ArkLinux (not Archlinux), who are they, even you felt the need to explain it to us.  

Understandably, the faster one to be developed is not the choice of "commercial" distros nor a current standard... but efficiency has never played a true role in corporate scenarios and is always frowned upon.  I say stay ahead of the times.  It's nice that 4.6 will eventually have this feature and that, but the question is, why wait?  All in all, I can't see any real advantage to taking the slower path.  We can always take the faster path and slow down as we need to.... it's easier on gas mileage to slow down than it is to speed up.

Yes, "commercial" decisions also take into account other aspects besides the developers point of view and excitement over the latest new toy. Marketing folks also lend a moderating influence due to their concern for the product being a success. They take into account and place things like stability, brand recognition, and a the smooth continuity of development over all else.

Just my 2 cents and some food for thought.
Cheers,
Sal

[gettinther]

True there a risk associated with rpm5 as well as potential benefits.  There's no clear winner in this, hence the vote.  It will end up being a detail that will make people choose one way or the other.  Both have merits and flaws.

But it needs to be a group decision so that it is respected by everyone once agreed upon.

[spiralofhope]

There is a perspective where the choice would be based on whether we wanted/needed to keep Unity Linux development directly paying attention to RPM development or not.

With RPM 4.6, we can get away with ignoring all active development.  We only "deal" with RPM when updates break our habits.

With RPM 5, it sounds like we would be tempted to pay more attention to active development.  It also sounds like we'd be learning more.  Maybe we'd  be forced to learn more, or maybe we'd just be tempted to learn more.  I don't know if that's true.  Do our more technical people agree with this idea of temptation to learn more?

--+

I'm leaning towards RPM5 for political/marketing reasons.  Yes, it's shiny and new to me, but I think that if we have RPM 4.6 then distros/devs will question if they want to branch with us or just rebase from Mandriva directly.  It may sound like one small stupid point, but it would happen.

I also worry about the previous conversations about the two RPM teams and leadership.

- It sounds like we couldn't/wouldn't influence 4.6 development, but we would be pretty happy not participating.

- It also sounds like we would want to influence 5.0 development, but that also that their team or leadership may not always be compatible with us.  I'm also not so worried about RPM5 dissolving due to management issues, since they seem to have a medium-sized team.

--+

I lean towards RPM5 because of marketing value, hacking temptation and "shiny features NOW".  However, I would immediately bow to any technical or collaboration-related concerns.  Having said that, I think voting should be given double or triple weight for the core devs who directly work with RPM5 setup/support and preparing core packages.  I say this because this is too much of a "bicycle shed" issue.

[Sal]

Having said that, I think voting should be given double or triple weight for the core devs who directly work with RPM5 setup/support and preparing core packages.  I say this because this is too much of a "bicycle shed" issue.

LOL, I'm of the direct opposite opinion, the core devs vote should only count a 1/2 or 1/3 of a vote. They're always gonna want to run with the newest technical challenge, there's a reason why developers aren't allowed to make marketing decisions.   
Sal

[CPunltd]

is this nothing more than a marketing decision?  I would think other factors are at play as well.  Including, but not limited to, future development (of the core and branches), feature compatibility, bug fixing and upstream development.  We have some seriously talented people on our team, and I can foresee a lot of contributions going upstream with rpm5 which is not so obvious with rpm4.6.

[Sal]

is this nothing more than a marketing decision?  I would think other factors are at play as well.  Including, but not limited to, future development (of the core and branches), feature compatibility, bug fixing and upstream development.  We have some seriously talented people on our team, and I can foresee a lot of contributions going upstream with rpm5 which is not so obvious with rpm4.6.

Yes, everything you mentioned are all marketing decisions since they will contribute to the future success of Unity. Thing is IMHO that with the possible exception of getting a quicker responce from upstream input to RPM5, everything you mentioned is on the plus side for RPM4.6.

I'm not sure why Gettinther has even brought this issue up again, AFAIK since Vaughan's departure I'm the only one here still speaking out against the RPM5 path. But then this team is mainly composed of developers and I'm still Sal "the voice of sanity and reason".     As long as the issue is still being discussed I have to continue to oppose the path of RPM5.
Cheers,
Sal

[gettinther]

I brought it back on because we need to decide now of a path.  Waiting is not an option anymore for several reason but primarily the fact the i586 mandriva rpms are now incompatible with our version of rpm, even fedora SRPMS are not compatible which means the mandriva ones will soon follow.

I did not want to make a decision by myself because I value everyone's advice.  If you read my document attached to the first post, you will see that both teams are actively checking each other and actually looking for compatibility.  This is an important decision but it's not one that will affect the packagers badly.  rpm5 does introduce changes faster which will make packager's life easier but rpm4.6 will follow suit at some stage so the point is moot.

The important point here is to weigh the benefits vs risks associated with using rpm4.6 or rpm5.  As I said it will be up to each of us to decide what way to go.  Would using rpm5 be a marketing strongpoint or a weakness.  Does using rpm5 present us as an "rogue group" using "non standard" packaging system doomed to a short life span?  Does using rpm4.6 present us as "just another mdv remaster" with no future? I'm being the devil's advocate here but those are the kind of questions we should ask ourselves. 

[gri6507]

Based on my admittedly limited understanding of the technical differences and based on large part on the very nice summary document provided in this thread, I would like us to continue with the 4.x branch. Primarily this is to simplify our own life with Mandriva compatibility. I don't know if there are any other advantages of one vs the other from my point of view.

Just my 2 cents.

[CPunltd]

well, in the end, I have noted where I stand.  I believe I am done with this topic officially.

[gettinther]

I'll open the poll in 24 hr except if we get into further information warranting an delay for review.

[Jmiahman]

rpm5, the help it will offer with packaging python alone is worth it, rpm4.6 doesn't offer nor seems to have plans to offer such a technology. It's not a shiny new toy thing it's what does the Job the best. If we can work less repackaging python depends in the future with one verses the other then, then go with the one that's easier. This also brings to light the path rpm5 is going. One of it's goals seems to be to make it easier easier for the packager. It's much less a marketing decision then a decision for survival. The less work in packaging the less chance of burn out. RedHat and the commercial distributions have less to worry about when it comes to ease of use of packaging or volunteer burnout, for the most part people are getting paid to package. Whatever makes it easier for our volunteers gets my vote and reading the differences myself and the changelogs of both projects that's rpm5. Derrive your own conclusion but we need something to market first before we even start getting into marketing discussions about something the end user rarely thinks about or sees as long as it works.