[ITP] monotone

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[ITP] monotone

Lapo Luchini
Well, here we are. I just gave a try at it, and it well seems that
monotone-0.25 likes our current boost package and does compile against it.

What's that?
> monotone is a free distributed version control system. it provides a
> simple, single-file transactional version store, with fully
> disconnected operation and an efficient peer-to-peer synchronization
> protocol. it understands history-sensitive merging, lightweight
> branches, integrated code review and 3rd party testing. it uses
> cryptographic version naming and client-side RSA certificates. it has
> good internationalization support, has no external dependencies, runs
> on linux, solaris, OSX, windows, and other unixes, and is licensed
> under the GNU GPL.
Files?
http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
http://www.lapo.it/cygwin/monotone-0.25-1-src.tar.bz2
http://www.lapo.it/cygwin/setup.hint

Checksums?
0657f3ef0778ca005ac73e8ab4639ec2bcc808ec
b27c1c503e5f70cfc1cc4a2663ed84a33385f954

setup.hint:

> # setup.hint for monotone
> sdesc: "free distributed version control system"
> ldesc: "monotone is a free distributed version control system. it
> provides a simple, single-file transactional version store, with fully
> disconnected operation and an efficient peer-to-peer synchronization
> protocol. it understands history-sensitive merging, lightweight
> branches, integrated code review and 3rd party testing. it uses
> cryptographic version naming and client-side RSA certificates. it has
> good internationalization support, has no external dependencies, runs
> on linux, solaris, OSX, windows, and other unixes, and is licensed
> under the GNU GPL."
> category: Devel
> requires: libiconv2 libintl3 zlib
> #maintainer: Lapo Luchini <[hidden email]>
PS: "make test" doesn't compile, it doesn't find
libboost_unit_test_framework-gcc-mt-s.a, but I tested that against my
local databases (created by mingw binary as found on the website,
version 0.23) and, after a "monotone db migrate" to upgrate 0.23 format
to 0.25 one) it worked perfectly.

    Lapo

Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Lapo Luchini
Lapo Luchini wrote:
> Files?
> http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
> http://www.lapo.it/cygwin/monotone-0.25-1-src.tar.bz2
> http://www.lapo.it/cygwin/setup.hint
>
> Checksums?
> 0657f3ef0778ca005ac73e8ab4639ec2bcc808ec
> b27c1c503e5f70cfc1cc4a2663ed84a33385f954
Almost forgot...

Linux distro references?
http://packages.debian.org/stable/devel/monotone
http://aur.archlinux.org/packages.php?do_Details=1&ID=1398&K=monotone
ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/monotone-0.23-1.fc5.src.rpm

    Lapo

Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Václav Haisman


Lapo Luchini wrote:

> Lapo Luchini wrote:
>
>> Files?
>> http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
>> http://www.lapo.it/cygwin/monotone-0.25-1-src.tar.bz2
>> http://www.lapo.it/cygwin/setup.hint
>>
>> Checksums?
>> 0657f3ef0778ca005ac73e8ab4639ec2bcc808ec
>> b27c1c503e5f70cfc1cc4a2663ed84a33385f954
>
> Almost forgot...
>
> Linux distro references?
> http://packages.debian.org/stable/devel/monotone
> http://aur.archlinux.org/packages.php?do_Details=1&ID=1398&K=monotone
> ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/monotone-0.23-1.fc5.src.rpm
>
>
>    Lapo
There is also FreeBSD package too. I support adding this package.

Vaclav Haisman

signature.asc (558 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Christopher Faylor-2
On Wed, Jan 04, 2006 at 08:26:47PM +0100, V??clav Haisman wrote:

>
>
>Lapo Luchini wrote:
>> Lapo Luchini wrote:
>>
>>> Files?
>>> http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
>>> http://www.lapo.it/cygwin/monotone-0.25-1-src.tar.bz2
>>> http://www.lapo.it/cygwin/setup.hint
>>>
>>> Checksums?
>>> 0657f3ef0778ca005ac73e8ab4639ec2bcc808ec
>>> b27c1c503e5f70cfc1cc4a2663ed84a33385f954
>>
>> Almost forgot...
>>
>> Linux distro references?
>> http://packages.debian.org/stable/devel/monotone
>> http://aur.archlinux.org/packages.php?do_Details=1&ID=1398&K=monotone
>> ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/monotone-0.23-1.fc5.src.rpm
>>
>There is also FreeBSD package too. I support adding this package.

There is no reason to vote on the package if there is already a
linux reference distribution.  FreeBSD is not relevant in this case.

Are there any volunteers who would be willing to modernize
http://cygwin.com/setup.html to make this policy clear?

cgf

Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Lapo Luchini
Christopher Faylor wrote:
> V??clav Haisman wrote:
>> There is also FreeBSD package too. I support adding this package.
>>    
I wonder who's crazy enough to mantain it. <giggle>
> There is no reason to vote on the package if there is already a
> linux reference distribution.  FreeBSD is not relevant in this case.
>  
What is missing, in this case, is a good old review of the packaging
itself, if my internal memory is not yet ready for the trash...
> Are there any volunteers who would be willing to modernize
> http://cygwin.com/setup.html to make this policy clear?
>  
I see the it isn't outdated, that part it's just missing. ;)
I'll try to write something tomorrow and post it on the list.

    Lapo

Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Christopher Faylor-2
On Thu, Jan 05, 2006 at 02:31:02AM +0100, Lapo Luchini wrote:

>Christopher Faylor wrote:
>> V??clav Haisman wrote:
>>> There is also FreeBSD package too. I support adding this package.
>>>    
>I wonder who's crazy enough to mantain it. <giggle>
>> There is no reason to vote on the package if there is already a
>> linux reference distribution.  FreeBSD is not relevant in this case.
>>  
>What is missing, in this case, is a good old review of the packaging
>itself, if my internal memory is not yet ready for the trash...

Right.  We still need a GTG.

>> Are there any volunteers who would be willing to modernize
>> http://cygwin.com/setup.html to make this policy clear?
>>  
>I see the it isn't outdated, that part it's just missing. ;)
>I'll try to write something tomorrow and post it on the list.

I suspect that there are parts of the page which could use some updating
which is why I couched the request more general terms but, yes, the
"new" rules should be spelled out there.

cgf

Reply | Threaded
Open this post in threaded view
|

"submission rules page" proposal [Was: monotone]

Lapo Luchini
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher Faylor wrote:
> I suspect that there are parts of the page which could use some updating
> which is why I couched the request more general terms but, yes, the
> "new" rules should be spelled out there.
I began with the last section, separating it in two (submitting new
packages vs updating existing packages) and including "submission rules".

I guess the other message (with the HTML in attach) didn't get thru, so
here it is: http://cyberx.lapo.it/~lapo/cygpackage.html

    Lapo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJDvPpKAAoJELBiMTth2oCD82UQALaVTZi9MYlZnjmV7wgnfGEM
+Ep2t334ZZAcmKxk5vDfO85Q8Pbvv6nzW5NoBxDwJePnM5WsFt4v1pu2PjAkG7wt
6cLdSYTcYCo8UcW1pBjjRYTVwa8iiAn/UVv8Ui85wNyTtWYh5cMCTfp7xotYEovA
wwMFzVhXE3Vju14ibId46cFr9fTPm6FAndHeF56wzPUbT+tvYDcm8deT9+GSWKFq
v9xnLsuXagaJx98WuR8rJO3LGamP+tV2a0k1IKR05qglbEsolkci668MxnUzz5pP
4aUEBZexusxnHDFgGGok4kL7D0cwbk1XIL+dE3urIDO8drlvrhLBm6Zlpzr3Xaq7
QbCUCRRBKfgqs2HOHCOEx+tkCzeKBx902fWeD0nqvaGGxv/lSvgasF7E2VA+iUYZ
KrfVZRw6l5wuaQ1gkoxckTyD9FdW47knVNjRvYRQ/GaJ02j+G/vTiy0JdMbcLoMl
wXo6GvveR2tGT2Q73X3s5hcxdtZJP/HQqJGLaLTOJIL7CqQcxffhFP+4c4Ui3XxF
EpXOxuvx1Y8XhD91GMBVId47w04F0JIjLKhvkggkAnRTNiXUAWBGmQSZQ9GojhGZ
FTk9PmtcwisvfYpBB3AqJ92UWgQyUngZQm19hVaoWU+tRBewEN6x1tmEyngv3+ZD
sMot/JuJ9PNm1MNyWuc7
=pbw0
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal [Was: monotone]

Eric Blake (cygwin)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Lapo Luchini on 1/5/2006 3:51 AM:
>
> I guess the other message (with the HTML in attach) didn't get thru, so
> here it is: http://cyberx.lapo.it/~lapo/cygpackage.html

Overall, it looks good; I appreciate you doing this.  My comments, on a
text-ized version:

> Submitting a new package
>
> So you've got a package you want to submit. Follow the following
> checklist before emailing [hidden email] and you'll
> almost certainly save time.
>
>    1. Propose on [hidden email] that you are interested
>       in becoming a package maintainer for package foo. Some
>       packages cannot be distributed via cygwin's setup due to
>       vendor licence limitations. Other packages may not be
>       appropriate for cygwin. This step will save time if, for
>       some reason, we cannot accept the package.

Mention that the email subject should include [ITP], to make it obvious
this is a request for a new package.

>
>       Submission rules:
>
>           * Include a complete setup.hint file as part of your
>             proposal. Include this file in the text of your
>             message so that it can be commented on. Do not submit
>             it as an attachment.
>
>           * If the new package is a well-known program already
>             included in a major Linux distribution (e.g. debian)
>             please include the URL of the package page.
>
>           * If the package is not included in any major Linux
>             distro it must receive three positive votes from

I thought this number was five votes.  bsflite was a recent example of
this, http://cygwin.com/ml/cygwin-apps/2005-12/msg00050.html

>             other package mantainers in order to be accepted.
>
>    2. Do you have the time to maintain the package? Packages
>       without active maintainers are pulled from the
>       distribution. Generally speaking the time commitment is
>       relatively low, simply subscribe to [hidden email]. We'd
>       prefer if you read the non-digest mode since prompt
>       response to packaging issues is a plus. When a bug in your
>       package is reported in the cygwin mailing list, address the
>       bug (if it's a cygwin-only bug) or pass back to the
>       vendor. When a solution exists, create an updated package
>       with the fix in it, and send a notification that you need
>       the package uploaded to cygwin-apps. Note that you are not
>       expected to be a helpdesk for the package - the users
>       should be pointed to the vendors lists if you've determined
>       that the bug is not a cygwin-related bug.
>
>    3. Look in the debian package list and identify the section
>       that your package is present in there - if it's available
>       via debian. If it's not, have a look and take a sensible
>       guess.
>
>    4. Create setup.hint file following the documentation on this
>       web page. Opinion on whether to mark your initial version
>       as a Test version is currently mixed. If you have doubts
>       about the stability of your initial offering you may decide
>       to mark it as Test. Then, once the package has no major bug
>       reports from users, a current package may be
>       introduced. Otherwise, it is perfectly acceptable to forgo
>       the Test designation in your first release.

You may want to move step 4 prior to step 1, since you mention submitting
the proposed setup.hint online.  Also, this would be a good place to
mention that writing
sdesc: "foo: program that does bar" is redundant for a package named foo,
and would look like "foo: foo: program that does bar" in setup.exe.

>
>    5. Place the package files in a web accessible http/ftp site
>       somewhere.

Mention that directory structure must exist.  For example, if I am
proposing foo and libfoo, my upload site should look like:
myserver.com/whatever/foo/foo-1-1.tar.bz2
myserver.com/whatever/foo/foo-1-1-src.tar.bz2
myserver.com/whatever/foo/setup.hint
myserver.com/whatever/foo/libfoo/libfoo-1-1.tar.bz2
myserver.com/whatever/foo/libfoo/setup.hint


>
>    6. Announce on [hidden email] that you have the
>       package ready for uploading. Provide the URLs to all
>       package files to your mail.
>
>    7. Each new package must in any case receive one GTG vote from
>       a package mantainer.

Explain that the GTG means that a maintainer has downloaded the package,
inspected the tarball contents, tested the applications, and rebuilt the
package from the source tarball without incident.  Also explain that by
becoming a package maintainer, you are allowed to provide the GTG reviews
for other package proposals.

>
>    8. Feel free to delete your temporary copy once the files have
>       been uploaded to sourceware.org.
>
>    9. Announce via [hidden email] that the new
>       package is available. Use a recent cygwin-announce message
>       from one of the core maintainers as a template for your
>       announcement.

Be sure the unsubscribe instructions are included at the end of the email,
since cygwin-announce does not add any.

>
>       Once sent, your message will be reviewed by one of the
>       cygwin-announce moderators and, once approved, will be
>       automatically forwarded to the cygwin mailing list with an
>       [ANNOUNCEMENT] prepended to the subject.
>
> Updating a package
>
> So you've got an updated package you want to submit. Follow the
> following checklist before emailing [hidden email] and
> you'll almost certainly save time.
>
>    1. Place the package files in a web accessible http/ftp site
>       somewhere.

Same layout rules as before - make your directory structure match what the
ultimate structure on the mirrors will be.

>
>    2. Announce on [hidden email] that you have the
>       package ready for uploading. Provide the URLs to all
>       package files to your mail. Just provide URLs for files
>       that have actually changed, i.e., it is not necessary to
>       provide a new link to a setup.hint file every time you
>       update your packages.

unless setup.hint actually changed.  Also, in the email, it is helpful if
you explicitly state which older versions to keep or delete from the mirrors.

>
>    3. Feel free to delete your temporary copy once the files have
>       been uploaded to sourceware.org.
>
>    4. Announce via [hidden email] that the new
>       package is available. Use a recent cygwin-announce message
>       from one of the core maintainers as a template for your
>       announcement.
>
>       Once sent, your message will be reviewed by one of the
>       cygwin-announce moderators and, once approved, will be
>       automatically forwarded to the cygwin mailing list with an
>       [ANNOUNCEMENT] prepended to the subject.
>
> NOTE: On any major version upgrade, you may want to mark the
> release as Test.

- --
Life is short - so eat dessert first!

Eric Blake             [hidden email]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDvSf284KuGfSFAYARAjWyAJ9Ni66GLIDIjGi4W2f0Seb4jNZw+wCgp3Ul
p/QSJVGpRuyRaZPVPutPgkk=
=UPQx
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal [Was: monotone]

Christopher Faylor-2
On Thu, Jan 05, 2006 at 07:06:48AM -0700, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Lapo Luchini on 1/5/2006 3:51 AM:
>>
>> I guess the other message (with the HTML in attach) didn't get thru, so
>> here it is: http://cyberx.lapo.it/~lapo/cygpackage.html
>
>Overall, it looks good; I appreciate you doing this.

Ditto!

I agree with all of Eric's points but I have a couple more to add.

(Thanks for text-izing this, Eric)

>>       Submission rules:
>>
>>           * Include a complete setup.hint file as part of your
>>             proposal. Include this file in the text of your
>>             message so that it can be commented on. Do not submit
>>             it as an attachment.
>>
>>           * If the new package is a well-known program already
>>             included in a major Linux distribution (e.g. debian)
>>             please include the URL of the package page.

Please mention Fedora and SuSE here, too.

>>           * If the package is not included in any major Linux
>>             distro it must receive three positive votes from
>
>I thought this number was five votes.  bsflite was a recent example of
>this, http://cygwin.com/ml/cygwin-apps/2005-12/msg00050.html

Yep.  We increased the votes when we allowed packages that were already
in other distributions to slide in.

>>    4. Create setup.hint file following the documentation on this
>>       web page. Opinion on whether to mark your initial version
>>       as a Test version is currently mixed. If you have doubts
>>       about the stability of your initial offering you may decide
>>       to mark it as Test. Then, once the package has no major bug
>>       reports from users, a current package may be
>>       introduced. Otherwise, it is perfectly acceptable to forgo
>>       the Test designation in your first release.
>
>You may want to move step 4 prior to step 1, since you mention submitting
>the proposed setup.hint online.  Also, this would be a good place to
>mention that writing
>sdesc: "foo: program that does bar" is redundant for a package named foo,
>and would look like "foo: foo: program that does bar" in setup.exe.

Yes!  Also, please reiterate that the "@ foo" notation should not be
used.

>>    5. Place the package files in a web accessible http/ftp site
>>       somewhere.
>
>Mention that directory structure must exist.  For example, if I am
>proposing foo and libfoo, my upload site should look like:
>myserver.com/whatever/foo/foo-1-1.tar.bz2
>myserver.com/whatever/foo/foo-1-1-src.tar.bz2
>myserver.com/whatever/foo/setup.hint
>myserver.com/whatever/foo/libfoo/libfoo-1-1.tar.bz2
>myserver.com/whatever/foo/libfoo/setup.hint

Again, big yes!  That makes life easier for package uploaders.

>>    6. Announce on [hidden email] that you have the
>>       package ready for uploading. Provide the URLs to all
>>       package files to your mail.
>>
>>    7. Each new package must in any case receive one GTG vote from
>>       a package mantainer.
>
>Explain that the GTG means that a maintainer has downloaded the package,
>inspected the tarball contents, tested the applications, and rebuilt the
>package from the source tarball without incident.  Also explain that by
>becoming a package maintainer, you are allowed to provide the GTG reviews
>for other package proposals.

Unless this was described earlier, you should explain what GTG (and ITP for
that matter) means.

>>    8. Feel free to delete your temporary copy once the files have
>>       been uploaded to sourceware.org.
>>
>>    9. Announce via [hidden email] that the new
>>       package is available. Use a recent cygwin-announce message
>>       from one of the core maintainers as a template for your
>>       announcement.
>
>Be sure the unsubscribe instructions are included at the end of the email,
>since cygwin-announce does not add any.

Maybe we should just include a template of a valid cygwin-announce email
on this web page.

>>    2. Announce on [hidden email] that you have the
>>       package ready for uploading. Provide the URLs to all
>>       package files to your mail. Just provide URLs for files
>>       that have actually changed, i.e., it is not necessary to
>>       provide a new link to a setup.hint file every time you
>>       update your packages.

Please mention that there is no reason to editorialize about the reason
for the upload.  We trust you as the package maintainer (unlike cygwin bug
reporters where we need at least 42 people to report a bug before we will
even consider it a bug).  All that we need in this email is the raw
details needed for uploading the packages to sourceware.org.  Again, maybe
a template email message would help.

>unless setup.hint actually changed.  Also, in the email, it is helpful if
>you explicitly state which older versions to keep or delete from the mirrors.

I've been meaning to mention this.  The disk space limitations on the new
sourceware are pretty much nonexistent now - at least for a year or so.
I don't think there's any harm in keeping old versions around now unless
people think this is a bad idea in general.

>>    3. Feel free to delete your temporary copy once the files have
>>       been uploaded to sourceware.org.

Please mention that someone with login privileges on sourceware.org will send
an "Uploaded" response eventually.

>>    4. Announce via [hidden email] that the new
>>       package is available. Use a recent cygwin-announce message
>>       from one of the core maintainers as a template for your
>>       announcement.
>>
>>       Once sent, your message will be reviewed by one of the
>>       cygwin-announce moderators and, once approved, will be
>>       automatically forwarded to the cygwin mailing list with an
>>       [ANNOUNCEMENT] prepended to the subject.

Please mention that the cygwin-announce message should not be sent until the
software has been uploaded but it should be sent as soon as possible after
the uploaded message has been sent to cygwin-apps.

Thanks again for doing this.

cgf

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal [Was: monotone]

Lapo Luchini
Christopher Faylor wrote:
> (Thanks for text-izing this, Eric)
> Unless this was described earlier, you should explain what GTG (and ITP for
> that matter) means.
>  
They were, actually, hyperlinks to the online OLOCA ;-)

About all the rest: I'll integrate the suggestions this evening.
> Thanks again for doing this.
>  
Gotta replenish the karma tank, once in a while 0:-)

    Lapo

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal [Was: monotone]

Eric Blake-2
In reply to this post by Lapo Luchini
>
> >>    2. Announce on [hidden email] that you have the
> >>       package ready for uploading. Provide the URLs to all
> >>       package files to your mail. Just provide URLs for files
> >>       that have actually changed, i.e., it is not necessary to
> >>       provide a new link to a setup.hint file every time you
> >>       update your packages.
>
> Please mention that there is no reason to editorialize about the reason
> for the upload.  We trust you as the package maintainer (unlike cygwin bug
> reporters where we need at least 42 people to report a bug before we will
> even consider it a bug).  All that we need in this email is the raw
> details needed for uploading the packages to sourceware.org.  Again, maybe
> a template email message would help.

Also, mention that once a package has been uploaded, all
future uploads need to bump the version number (if re-releasing
the same upstream version, this means bumping the cygwin
release number).  That way, even if a -1 was available on the
mirrors only for a short time, then got pulled for some reason
(such as the recent cmake issue), anyone who managed to
download the -1 will see the -2 update, rather than getting
warnings from setup.exe about the checksum changing in a
repeat upload of a changed -1.

--
Eric Blake

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal [Was: monotone]

Christopher Faylor-2
On Thu, Jan 05, 2006 at 04:08:59PM +0000, Eric Blake wrote:

>>
>> >>    2. Announce on [hidden email] that you have the
>> >>       package ready for uploading. Provide the URLs to all
>> >>       package files to your mail. Just provide URLs for files
>> >>       that have actually changed, i.e., it is not necessary to
>> >>       provide a new link to a setup.hint file every time you
>> >>       update your packages.
>>
>> Please mention that there is no reason to editorialize about the reason
>> for the upload.  We trust you as the package maintainer (unlike cygwin bug
>> reporters where we need at least 42 people to report a bug before we will
>> even consider it a bug).  All that we need in this email is the raw
>> details needed for uploading the packages to sourceware.org.  Again, maybe
>> a template email message would help.
>
>Also, mention that once a package has been uploaded, all
>future uploads need to bump the version number (if re-releasing
>the same upstream version, this means bumping the cygwin
>release number).  That way, even if a -1 was available on the
>mirrors only for a short time, then got pulled for some reason
>(such as the recent cmake issue), anyone who managed to
>download the -1 will see the -2 update, rather than getting
>warnings from setup.exe about the checksum changing in a
>repeat upload of a changed -1.

Yes, good point.

cgf

Reply | Threaded
Open this post in threaded view
|

"submission rules page" proposal number 2

Lapo Luchini
In reply to this post by Eric Blake (cygwin)
Eric Blake wrote:
> You may want to move step 4 prior to step 1, since you mention submitting
> the proposed setup.hint online.
Mhhh... that's a tough issue: for sure step 1 has a forward reference to
step 4 regarding setup.hint (which is bad), but step 1 contains the most
important info, and putting it at step 2 after a longish text about the
Test-ness of packages seems to remove step 1 quite a bit of authority.
Uhm. Any other comment or suggestion how to solve the issue?
> Also, in the email, it is helpful if
> you explicitly state which older versions to keep or delete from the
> mirrors.
Can "old" version be multiple or just a single one? (I'm assuming the
latter, in version 2 I'm preparing right now)


Christopher Faylor wrote:
> Yep.  We increased the votes when we allowed packages that were already
> in other distributions to slide in.
Whoops, didn't remember that.
> I've been meaning to mention this.  The disk space limitations on the new
> sourceware are pretty much nonexistent now - at least for a year or so.
> I don't think there's any harm in keeping old versions around now unless
> people think this is a bad idea in general.
Should I remove that part, then?
> should be sent as soon as possible after
> the uploaded message has been sent to cygwin-apps.
Does the old-times rule "give a few hours to allow the package spread to
the mirrors" hold no more, then?

Well, let's see how this version 2 fares:

http://cyberx.lapo.it/~lapo/cygpackage.html

    Lapo



Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Christopher Faylor-2
On Fri, Jan 06, 2006 at 02:26:29AM +0100, Lapo Luchini wrote:

>Eric Blake wrote:
>> You may want to move step 4 prior to step 1, since you mention submitting
>> the proposed setup.hint online.
>Mhhh... that's a tough issue: for sure step 1 has a forward reference to
>step 4 regarding setup.hint (which is bad), but step 1 contains the most
>important info, and putting it at step 2 after a longish text about the
>Test-ness of packages seems to remove step 1 quite a bit of authority.
>Uhm. Any other comment or suggestion how to solve the issue?
>> Also, in the email, it is helpful if
>> you explicitly state which older versions to keep or delete from the
>> mirrors.
>Can "old" version be multiple or just a single one? (I'm assuming the
>latter, in version 2 I'm preparing right now)
>
>
>Christopher Faylor wrote:
>> Yep.  We increased the votes when we allowed packages that were already
>> in other distributions to slide in.
>Whoops, didn't remember that.
>> I've been meaning to mention this.  The disk space limitations on the new
>> sourceware are pretty much nonexistent now - at least for a year or so.
>> I don't think there's any harm in keeping old versions around now unless
>> people think this is a bad idea in general.
>Should I remove that part, then?

I'd like to hear what other people (particularly Corinna) think before we
remove the section.

>> should be sent as soon as possible after
>> the uploaded message has been sent to cygwin-apps.
>Does the old-times rule "give a few hours to allow the package spread to
>the mirrors" hold no more, then?

I don't see any reason to wait.  The more you wait, the more you stand the
chance of forgetting.

cgf

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Corinna Vinschen-2
On Jan  5 20:52, Christopher Faylor wrote:
> On Fri, Jan 06, 2006 at 02:26:29AM +0100, Lapo Luchini wrote:
> >> I've been meaning to mention this.  The disk space limitations on the new
> >> sourceware are pretty much nonexistent now - at least for a year or so.
> >> I don't think there's any harm in keeping old versions around now unless
> >> people think this is a bad idea in general.
> >Should I remove that part, then?
>
> I'd like to hear what other people (particularly Corinna) think before we
> remove the section.

IMO we shouldn't keep old versions around for too long.  I'm not against
keeping one or two old versions which are not accessible via setup, but
more of that just makes live harder for the uploaders.  If a maintainer
wants to keep old versions, why not on his/her machine?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Reply | Threaded
Open this post in threaded view
|

Re: [ITP] monotone

Corinna Vinschen-2
In reply to this post by Lapo Luchini
On Jan  3 22:05, Lapo Luchini wrote:
> Lapo Luchini wrote:
> >Files?
> >http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
> >http://www.lapo.it/cygwin/monotone-0.25-1-src.tar.bz2
> >http://www.lapo.it/cygwin/setup.hint

$ wget http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
--12:30:52--  http://www.lapo.it/cygwin/monotone-0.25-1.tar.bz2
           => `monotone-0.25-1.tar.bz2'
Resolving www.lapo.it... 151.1.209.76
Connecting to www.lapo.it|151.1.209.76|:80... connected.
HTTP request sent, awaiting response... 404 Object Not Found
12:30:52 ERROR 404: Object Not Found.

Same for the -src file.  Only setup.hint is ok.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Lapo Luchini-2
In reply to this post by Corinna Vinschen-2
Corinna Vinschen wrote:

> On Jan  5 20:52, Christopher Faylor wrote:
>  
>> On Fri, Jan 06, 2006 at 02:26:29AM +0100, Lapo Luchini wrote:
>>    
>>>> I've been meaning to mention this.  The disk space limitations on the new
>>>> sourceware are pretty much nonexistent now - at least for a year or so.
>>>> I don't think there's any harm in keeping old versions around now unless
>>>> people think this is a bad idea in general.
>>>>        
>>> Should I remove that part, then?
>>>      
>> I'd like to hear what other people (particularly Corinna) think before we
>> remove the section.
>>    
> IMO we shouldn't keep old versions around for too long.  I'm not against
> keeping one or two old versions which are not accessible via setup, but
> more of that just makes live harder for the uploaders.  If a maintainer
> wants to keep old versions, why not on his/her machine?
>  
So there's some consensus on it?

What about the rest of the page?

When you're happy with it tell me: I will integrate it with the rest of
the HTML present in the page, in order to be uploadable in stead of the
"old" one.

    Lapo
Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Christopher Faylor-2
On Sat, Jan 21, 2006 at 10:33:23AM +0100, Lapo Luchini wrote:
>When you're happy with it tell me: I will integrate it with the rest of
>the HTML present in the page, in order to be uploadable in stead of the
>"old" one.

I think it is close but there are a couple of other random thing:

- The list of acceptable categories comes from the
http://cygwin.com/setup.html, not from Debian.  Adding a new package
requires discussion here first.

- Rather than saying "please avoid the package name", please make it an
imperative like "Do not use the package name".

- Should the "Do you have time to maintain the package?" question be the
very first question?

- I wonder if a summary detailing how a package gets accepted would be
useful just for reiteration:

  1) Build the package and make sure that you have time to maintain it.

  2) Send an ITP to the cygwin mailing list.  If the package is part
  of a distribution, include the URL which demonstrates this.  Include
  a setup.hint.

  3) If you have received the correct number of votes or if the package
  is part of a distribution, include URL(s) for the package binary and
  source so that someone can download them to check the package for any
  obvious problems.

  4) Once you get a GTG from a package maintainer, send a "Please upload"
  to the cygwin-apps mailing list.

  5) When you get the "uploaded" confirmation, send an immediate note to
  cygwin-announce.

Other than that this is nearly GTG, I think.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Jari Aalto-5
Christopher Faylor <[hidden email]> writes:

> On Sat, Jan 21, 2006 at 10:33:23AM +0100, Lapo Luchini wrote:
>   2) Send an ITP to the cygwin mailing list.  If the package is part
>   of a distribution, include the URL which demonstrates this.  Include
>   a setup.hint.

>   3) If you have received the correct number of votes or if the package
>   is part of a distribution, include URL(s) for the package binary and
>   source so that someone can download them to check the package for any
>   obvious problems.

[I'll reiterate from my previous post (ITP weblint)]

There has been objections to include Debian packages that are in
unstable. Let's think a while statements:

- It's included in Fedora
- It's included in Ubuntu
- It's included in Gentoo
- It's included in Debian

To my knowledge, Debian is the only one that includes (in my
terminology) so called "release categories", that is

  stable
  testing
  unstable
  experimental      

Ubuntu is based on Debian "unstable", where packages are frozen in 6
month intervals.

Fedora has release schedule similar to Ubuntu (NN months).

I don't know Gentoo, but I assume they only have one package category,
but that's not necessary the "stable" released Gentoo, but the latest
found there.

Debian "stable" is more like Redhat RHEL, which does not change often.
It would be impractical to say "only Debian stable" packages are
accepted without votes. If that were the rule, then we whould need to
similarly accept only RHEL packages from Redhat side.

So, what packages are exactly included in statement "If the package is part
of a distribution"

Jari



Reply | Threaded
Open this post in threaded view
|

Re: "submission rules page" proposal number 2

Christopher Faylor-2
In reply to this post by Christopher Faylor-2
On Sat, Jan 21, 2006 at 10:38:22PM -0500, Christopher Faylor wrote:
>On Sat, Jan 21, 2006 at 10:33:23AM +0100, Lapo Luchini wrote:
>>When you're happy with it tell me: I will integrate it with the rest of
>>the HTML present in the page, in order to be uploadable in stead of the
>>"old" one.
>
>I think it is close but there are a couple of other random thing:

And, to address Jari's point, I guess it can't be as simple as:

  # If the new package is a well-known program already included in a
  major Linux distribution (e.g.  Debian, Fedora, SuSE) please include
  the URL of the package page.

But has to say something about non-testing, non-development, non-unstable.

  # If the new package is a well-known program already included in a
  major Linux distribution (e.g.  Debian, Fedora, SuSE) please include
  the URL of the package page which shows the package.  Note that
  "development", "test", and "unstable" packages are not eligible for
  this rule.

(please massage the above as appropriate)

Lapo, if you make a combined page which addresses this and my previous
points I'll put it up ASAP.

cgf
12