[pacman-dev] My $0.02 on the Frugalware v.s. Arch bit...

newer
[pacman-dev] Long functions and...

Scott Horowitz

27 Dec 2006 27 Dec '06

6:42 p.m.

I hate to wade into this, but let me just say... there's no doubt in my mind that this will never be resolved while the (inflammatory) sentiment in the pacman-g2 README exists. For starters, the whole point being made about the API not being stable, which seems to be points 1 and 2 in the README, are plain silly. No project should take a project's cvs development code and expect the API to remain stable; Frugalware knew what it was getting into when it grabbed this code to put into their repositories. There's a reason that pacman3 hasn't been released yet on Archlinux, and that there haven't been Archlinux frontends developed. Pacman3 development shouldn't be hindered because someone decided to release the code into the wild, and it's clearly going under some large refactoring. As for point 3, Aaron's supposed disinterest in contributor's patches - I think it has been quite clear from the mailing list that this isn't the case. The real justification behind this sentiment, which was brought up in the original email and I agree needs improvement, is that there could use more openness (such as in response to a WONTFIX patch) between all the parties. Then there's the stuff about how development has fallen behind schedule (what project hasn't?) and Aaron asked Frugalware to fork things (I'm pretty sure this was more tongue-in-cheeck about how Frugalware is doing things than anything). These seem pretty petty to me. In my opinion, two things need to happen, one from each side. On the Archlinux side, I think Aaron should make a better attempt to be more transparent in his responses, which would hopefully encourage debate. On the Frugalware side, I think the whining about API stability needs to be dropped and, rather than take the "fork" talk as a challenge, they should be asking what needs to be done to make the two paths more compatible. Happy Holidays, Scott

Show replies by thread

Alex Smith

27 Dec 27 Dec

9:14 p.m.

Scott Horowitz wrote:

...

I hate to wade into this, but let me just say... there's no doubt in my mind that this will never be resolved while the (inflammatory) sentiment in the pacman-g2 README exists.

For starters, the whole point being made about the API not being stable, which seems to be points 1 and 2 in the README, are plain silly. No project should take a project's cvs development code and expect the API to remain stable; Frugalware knew what it was getting into when it grabbed this code to put into their repositories. There's a reason that pacman3 hasn't been released yet on Archlinux, and that there haven't been Archlinux frontends developed. Pacman3 development shouldn't be hindered because someone decided to release the code into the wild, and it's clearly going under some large refactoring.

Yes, I can agree with that.

...

As for point 3, Aaron's supposed disinterest in contributor's patches - I think it has been quite clear from the mailing list that this isn't the case. The real justification behind this sentiment, which was brought up in the original email and I agree needs improvement, is that there could use more openness (such as in response to a WONTFIX patch) between all the parties.

Then there's the stuff about how development has fallen behind schedule (what project hasn't?) and Aaron asked Frugalware to fork things (I'm pretty sure this was more tongue-in-cheeck about how Frugalware is doing things than anything). These seem pretty petty to me.

Very petty.

...

In my opinion, two things need to happen, one from each side. On the Archlinux side, I think Aaron should make a better attempt to be more transparent in his responses, which would hopefully encourage debate. On the Frugalware side, I think the whining about API stability needs to be dropped and, rather than take the "fork" talk as a challenge, they should be asking what needs to be done to make the two paths more compatible.

There shouldn't even be two paths in my opinion.

...

Happy Holidays, Scott

Thanks, Alex -- Alex Smith Frugalware Linux developer - http://www.frugalware.org

Christ Schlacta

1 Jan 1 Jan

12:46 a.m.

admittedly I don't know all the details behind the fork, however, from what I've read, it seems completely pointless. I think there needs to be some more cooperation all around. it would be best for everyone, especially the users. On 12/27/06, Alex Smith wrote:

...

Scott Horowitz wrote:

...
I hate to wade into this, but let me just say... there's no doubt in my mind that this will never be resolved while the (inflammatory) sentiment in the pacman-g2 README exists.

For starters, the whole point being made about the API not being stable, which seems to be points 1 and 2 in the README, are plain silly. No project should take a project's cvs development code and expect the API to remain stable; Frugalware knew what it was getting into when it grabbed this code to put into their repositories. There's a reason that pacman3 hasn't been released yet on Archlinux, and that there haven't been Archlinux frontends developed. Pacman3 development shouldn't be hindered because someone decided to release the code into the wild, and it's clearly going under some large refactoring.

Yes, I can agree with that.

...
As for point 3, Aaron's supposed disinterest in contributor's patches - I think it has been quite clear from the mailing list that this isn't the case. The real justification behind this sentiment, which was brought up in the original email and I agree needs improvement, is that there could use more openness (such as in response to a WONTFIX patch) between all the parties.

Then there's the stuff about how development has fallen behind schedule (what project hasn't?) and Aaron asked Frugalware to fork things (I'm pretty sure this was more tongue-in-cheeck about how Frugalware is doing things than anything). These seem pretty petty to me.

Very petty.

...
In my opinion, two things need to happen, one from each side. On the Archlinux side, I think Aaron should make a better attempt to be more transparent in his responses, which would hopefully encourage debate. On the Frugalware side, I think the whining about API stability needs to be dropped and, rather than take the "fork" talk as a challenge, they should be asking what needs to be done to make the two paths more compatible.

There shouldn't even be two paths in my opinion.

...
Happy Holidays, Scott

Thanks, Alex

-- Alex Smith Frugalware Linux developer - http://www.frugalware.org

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

VMiklos

11:45 a.m.

On Sun, Dec 31, 2006 at 04:46:20PM -0800, Christ Schlacta wrote:

...

admittedly I don't know all the details behind the fork, however, from what I've read, it seems completely pointless. I think there needs to be some more cooperation all around. it would be best for everyone, especially the users.

feel free to gime some to Aaron to get our patches applied. as we already stated in several mails, we've lost our motivation anyway, happy new year to all pacman{,-g2} hackers ;) udv / greetings, VMiklos -- Developer of Frugalware Linux, to make things frugal - http://frugalware.org

0 0

Roman Kyrylych

7:49 p.m.

2007/1/1, VMiklos :

...
feel free to gime some to Aaron to get our patches applied. as we already stated in several mails, we've lost our motivation

Ehm, correct me if I'm wrong, but AFAIK only one of your patch was not applied.

...
anyway, happy new year to all pacman{,-g2} hackers ;)

Happy new year for all! :) Let it be even more productive! -- Roman Kyrylych (Роман Кирилич)

0 0

Christ Schlacta

2 Jan 2 Jan
1:29 a.m.

now now, bickering won't help. so a patch wasn't applied. I can't speak to it either way, but I think that aaron should at least make a statement as to why, and if there wasn't a good reason for it's not being applied, either technical, or timewise, he should issue an apology, but since I'm not him, I don't know the reasons, and I can't say what he should do. Ultimately though, I think there needs to be a reunification of the packman development branches, pacman will fall prey to the same pitfalls as apt and rpm, and the same pitfalls as atom and rss as well. there should be no separation if it can be avoided, and as far as I can tell, it's up to aaron to make the first step and explain what he can. on an aside, I think the pacman development would be much smoother and more forward thinking if developers could get CVS access so that we don't have this same issue with a single maintainer holding all the strings in the future. Aaron, I hope you'll send a reply to this when you get back from whatever holiday you're celebrating. On 1/1/07, Roman Kyrylych wrote:

...
2007/1/1, VMiklos :

...
feel free to gime some to Aaron to get our patches applied. as we already stated in several mails, we've lost our motivation

Ehm, correct me if I'm wrong, but AFAIK only one of your patch was not applied.

...
anyway, happy new year to all pacman{,-g2} hackers ;)

Happy new year for all! :) Let it be even more productive!

-- Roman Kyrylych (Роман Кирилич) _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

0 0

James Rosten

4:16 a.m.

I do agree that there should be a reunification of development, because that would be for the better. On 1/1/07, Christ Schlacta wrote:

...
on an aside, I think the pacman development would be much smoother and more forward thinking if developers could get CVS access so that we don't have this same issue with a single maintainer holding all the strings in the future.

I think the one problem with that might be that, say you make a patch and apply it and commit it upstream, but while you were doing that someone else committed something that screws up your commit or you overwrite their commit. Of course, I don't use CVS very often and maybe it has some way around this, but if it doesn't that could lead to some problems.

0 0

Christ Schlacta

4:21 a.m.

well, cvs is pretty much like submitting patches, and if you try to commit and someone had modified the lines syou're trying to change, it prompts you to modify or discard the changes. it's a simple issue to resolve conflicts. biggest issue is when lead devs fail to commit or update often, and it results in massive changes every few days. On 1/1/07, James Rosten wrote:

...
I do agree that there should be a reunification of development, because that would be for the better.

On 1/1/07, Christ Schlacta wrote:

...
on an aside, I think the pacman development would be much smoother and more forward thinking if developers could get CVS access so that we don't have this same issue with a single maintainer holding all the strings in the future.

I think the one problem with that might be that, say you make a patch and apply it and commit it upstream, but while you were doing that someone else committed something that screws up your commit or you overwrite their commit. Of course, I don't use CVS very often and maybe it has some way around this, but if it doesn't that could lead to some problems.

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

0 0

James Rosten

4:29 a.m.

On Jan 1, 2007, at 11:21 PM, Christ Schlacta wrote:

...
well, cvs is pretty much like submitting patches, and if you try to commit and someone had modified the lines syou're trying to change, it prompts you to modify or discard the changes. it's a simple issue to resolve conflicts. biggest issue is when lead devs fail to commit or update often, and it results in massive changes every few days.

In that case, let us hope lead devs update and commit often. ~ Jamie / yankees26

0 0

Christ Schlacta

4:51 a.m.

indeed. lets hope for a development VS repo first. On 1/1/07, James Rosten wrote:

...
On Jan 1, 2007, at 11:21 PM, Christ Schlacta wrote:

...
well, cvs is pretty much like submitting patches, and if you try to commit and someone had modified the lines syou're trying to change, it prompts you to modify or discard the changes. it's a simple issue to resolve conflicts. biggest issue is when lead devs fail to commit or update often, and it results in massive changes every few days.

In that case, let us hope lead devs update and commit often.

~ Jamie / yankees26

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

0 0

Christ Schlacta

4:51 a.m.

erm, CVS. I hate this keyboard o,.,0 On 1/1/07, Christ Schlacta wrote:

...
indeed. lets hope for a development VS repo first.

On 1/1/07, James Rosten wrote:

...
On Jan 1, 2007, at 11:21 PM, Christ Schlacta wrote:

...
well, cvs is pretty much like submitting patches, and if you try to commit and someone had modified the lines syou're trying to change, it prompts you to modify or discard the changes. it's a simple issue to resolve conflicts. biggest issue is when lead devs fail to commit or update often, and it results in massive changes every few days.

In that case, let us hope lead devs update and commit often.

~ Jamie / yankees26

_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev

0 0

Jeff 'codemac' Mickey

7:26 a.m.

* On Monday, January 01 2007, James Rosten wrote:

...
I think the one problem with that might be that, say you make a patch and apply it and commit it upstream, but while you were doing that someone else committed something that screws up your commit or you overwrite their commit. Of course, I don't use CVS very often and maybe it has some way around this, but if it doesn't that could lead to some problems.

uhh.. this is called a "file conflict". Usually this will cause the second person's commit to fail, and leave them with the diff that broke the commit. The developer would then merge ( or edit and fix ) the two files, and recommit. It happens all the time, and this is literally the purpose of most revision control systems, handling multiple users editng the same file. // codemac -- .: [ + carpe diem totus tuus + ] :.

0 0

attachment

attachment.sig

6333
Age (days ago)

6339
Last active (days ago)

List overview
Download

11 comments

7 participants

Add to favorites Remove from favorites

tags

participants (7)

Alex Smith

Christ Schlacta

James Rosten

Jeff 'codemac' Mickey

Roman Kyrylych

Scott Horowitz

VMiklos