This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pending packages status

On Fri, 7 Mar 2003, Charles Wilson wrote:

> Yep, IIRC it *was* Pavel's personal preference.  It cetainly isn't mine. 
>   I agree with Max: packages should be uniquely identified, to avoid 
> confusion *during the prerelease phase*.  Imagine:
> "Bob, there's a proplem with your foo-1.3.2-1 package"
> "That's fixed in the third release of foo-1.3.2-1"
> "Wait, Bob, I thought I was using the third release.  Are you sure?"
> "Nope, you're right -- it's the *fourth* release that fixes the problem. 
>   Here's the package md5sum..."
> "Um, bob, I just downloaded foo-1.3.2-1 and it has md5sum xxxx.  Is that 
> newer, or older than the mythical fourth release?"
> "Yeah, sorry about that.  I gave you the md5sum of the fourth 
> pre-release.  I expected that you would simply compare it to the md5sum 
> of the package you've been complaining about (#3 ?).  However, you can't 
> download the #3 nor #4 prereleases anymore. We're up to the sixth 
> pre-release, and THAT is what you just downloaded..."

You're assuming that the guy has enough web space to hold all 
intermidiate releases. I've never seen this here. New packages are 
uploaded and the old ones removed.

> This is especially true in my case, since for autotool releases I tend 
> to put them up on my website in setup-compatible form prior even to 
> "test:" releases on the cygwin mirrors.  I *need* to keep pre-release 
> and pre-test versions unique if there have been any changes in them. Or 
> I'll hork off my testers...
> As far as chris's comments go, he is right that we haven't yet had too 
> many problems -- because most pre-release packages have not been 
> "setup-installable". Thus, no problems (except for communication issues, 
> as described above).

Ok I agree with this point. I've being doing this myself each time a new 
nfs-server package was released:

1) Download the package
2) Bump its version
3) Generate setup.ini
4) Upload to my site

>From these steps the most painful (error prone maybe is better) for me was 
the generation the setup.ini since I do this manually - yes I know there 
are other ways. Of course this is just me.

My point back then, when I replied to Daniel, was that I'm not doing this 
because "I like it this way". If you think about it, there is no gain for 
me to prefer one way over the other. This was my understanding of how the 
release process should work and it was based on the documentation on how to
make packages.

I'm not some freak who cant accept other peoples opinions. I'm open and
since I see that my way is unacceptable for many of the people here, I
agree that if a maintainer wants to bump the number then it is up to him
not me.

My work here is simple - keep a list of packages so people won't forget
about them. Now I see that I've overestimated my responsibilities 
for which I apologise. The important thing is to keep the packages coming.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]