commit new port - transcode
I submitted a new port recently and was hoping someone could commit it for me. Here's the ticket information: http://trac.macports.org/projects/macports/ticket/11933 Thank you. cr
On May 16, 2007, at 7:54 AM, cremes.devlist@mac.com wrote:
I submitted a new port recently and was hoping someone could commit it for me. Here's the ticket information:
We generally like to avoid cvs checkouts if possible (and when they're necessary, it's generally preferred to use a tag or date instead of HEAD). Is there a compelling reason to use cvs HEAD for this port? -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 16, 2007, at 8:59 AM, Daniel J. Luke wrote:
On May 16, 2007, at 7:54 AM, cremes.devlist@mac.com wrote:
I submitted a new port recently and was hoping someone could commit it for me. Here's the ticket information:
We generally like to avoid cvs checkouts if possible (and when they're necessary, it's generally preferred to use a tag or date instead of HEAD).
Is there a compelling reason to use cvs HEAD for this port?
Yes. The upcoming 1.1.0 release can only be accessed from HEAD. Plus, this is the best way to make sure that, as the code reaches release status, it doesn't break under OSX. The other maintainer and I are keeping a close eye on things to make sure OSX remains a solidly supported target platform. As soon as 1.1.0 is officially released, we will update the Portfile to grab a tarball. There is an older release (1.0.3) which could potentially be used, but it's a dead-end for support and functionality. All new development is focused on the 1.1.x releases. In the interim, HEAD is safe. The project developers have a policy of not breaking the build so we are (somewhat) assured the port will function properly for folks. Again, this is temporary. Is this sufficient? cr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFGSxHNtEOEsNMQp04RAtTTAJ0aMN4m/25Al7syziT2CsmvdI+sAACdE0Hw x2BWuZGlYN4PBmGRE2YBqHc= =+Veg -----END PGP SIGNATURE-----
Hi Chuck and David, On 17/05/2007, at 00:14, Chuck Remes wrote:
On May 16, 2007, at 8:59 AM, Daniel J. Luke wrote:
Is there a compelling reason to use cvs HEAD for this port?
Yes. The upcoming 1.1.0 release can only be accessed from HEAD. Plus, this is the best way to make sure that, as the code reaches release status, it doesn't break under OSX. The other maintainer and I are keeping a close eye on things to make sure OSX remains a solidly supported target platform. As soon as 1.1.0 is officially released, we will update the Portfile to grab a tarball.
There is an older release (1.0.3) which could potentially be used, but it's a dead-end for support and functionality. All new development is focused on the 1.1.x releases.
In the interim, HEAD is safe. The project developers have a policy of not breaking the build so we are (somewhat) assured the port will function properly for folks. Again, this is temporary.
Is this sufficient?
My concern with tracking HEAD in a public portfile (which is, I believe, the primary stated reason for discouraging it) is to do with non-reproducibility of builds. I imagine that it would be much easier to diagnose a problem if we know exactly what was in the source files via a tag, rather than having to try to find out when exactly they installed the port (particularly if it's a bug that is important but whose cause gets obfuscated by later changes, though I don't know how likely that is). Having said that, I don't see a problem with you maintaining a HEAD- tracking port locally and a publicly available tag-tracking port whose tag is frequently updated; if people are concerned with overly frequent updates, we can label the latter as transcode-devel to warn off people who are looking for more stable codebases. Of course, this course would be too much work without commit rights, but you're welcome to apply for that [1] (note that I have nothing to do with determining who gets those rights; I only got mine a few weeks ago). May I finally say thank you for your work on developing a port for transcode; speaking for myself, I've seen your posts to the lists and am impressed by the amount of work you have both been putting into this. I'd hate you to think that your work was not being appreciated. (I'm not casting aspersions about Daniel, either, who I'm sure appreciates your efforts too; I've just learned that you have to be really careful about writing emails, as it is far too easy to give the wrong impression. Apologies if you think I'm over- compensating, but I think it's worth it.) Kind regards, Maun Suang [1] "Requesting Commit Rights" at http://trac.macports.org/projects/ macports/wiki/NewCommittersGuide -- Boey Maun Suang (Boey is my surname) Email: boeyms at macports dot org
On May 17, 2007, at 1:14 AM, Boey Maun Suang wrote:
Hi Chuck and David,
On 17/05/2007, at 00:14, Chuck Remes wrote:
On May 16, 2007, at 8:59 AM, Daniel J. Luke wrote:
Is there a compelling reason to use cvs HEAD for this port?
Yes. The upcoming 1.1.0 release can only be accessed from HEAD. Plus, this is the best way to make sure that, as the code reaches release status, it doesn't break under OSX. The other maintainer and I are keeping a close eye on things to make sure OSX remains a solidly supported target platform. As soon as 1.1.0 is officially released, we will update the Portfile to grab a tarball.
There is an older release (1.0.3) which could potentially be used, but it's a dead-end for support and functionality. All new development is focused on the 1.1.x releases.
In the interim, HEAD is safe. The project developers have a policy of not breaking the build so we are (somewhat) assured the port will function properly for folks. Again, this is temporary.
Is this sufficient?
My concern with tracking HEAD in a public portfile (which is, I believe, the primary stated reason for discouraging it) is to do with non-reproducibility of builds. I imagine that it would be much easier to diagnose a problem if we know exactly what was in the source files via a tag, rather than having to try to find out when exactly they installed the port (particularly if it's a bug that is important but whose cause gets obfuscated by later changes, though I don't know how likely that is). [snip]
Thanks for all the feedback. I'll take a look at introducing a date tag so we can get reproducible builds. Once I get that working, we'll just update the Portfile twice a month until the transcode developers put out the final release. I'll privately track their daily submissions to make sure they don't break OSX builds too badly. :-) cr
On May 17, 2007, at 6:37 AM, Chuck Remes wrote:
On May 17, 2007, at 1:14 AM, Boey Maun Suang wrote:
Hi Chuck and David,
On 17/05/2007, at 00:14, Chuck Remes wrote:
On May 16, 2007, at 8:59 AM, Daniel J. Luke wrote:
Is there a compelling reason to use cvs HEAD for this port?
Yes. The upcoming 1.1.0 release can only be accessed from HEAD. Plus, this is the best way to make sure that, as the code reaches release status, it doesn't break under OSX. The other maintainer and I are keeping a close eye on things to make sure OSX remains a solidly supported target platform. As soon as 1.1.0 is officially released, we will update the Portfile to grab a tarball.
There is an older release (1.0.3) which could potentially be used, but it's a dead-end for support and functionality. All new development is focused on the 1.1.x releases.
In the interim, HEAD is safe. The project developers have a policy of not breaking the build so we are (somewhat) assured the port will function properly for folks. Again, this is temporary.
Is this sufficient?
My concern with tracking HEAD in a public portfile (which is, I believe, the primary stated reason for discouraging it) is to do with non-reproducibility of builds. I imagine that it would be much easier to diagnose a problem if we know exactly what was in the source files via a tag, rather than having to try to find out when exactly they installed the port (particularly if it's a bug that is important but whose cause gets obfuscated by later changes, though I don't know how likely that is). [snip]
Thanks for all the feedback. I'll take a look at introducing a date tag so we can get reproducible builds. Once I get that working, we'll just update the Portfile twice a month until the transcode developers put out the final release. I'll privately track their daily submissions to make sure they don't break OSX builds too badly. :-)
I have submitted a modified Portfile using a date tag for checkout. It compiles cleanly on both PPC and x86, so I think we're in good shape. Some please review and commit [1]. cr [1] http://trac.macports.org/projects/macports/ticket/11933
On May 17, 2007, at 10:31 PM, cremes.devlist@mac.com wrote:
I have submitted a modified Portfile using a date tag for checkout. It compiles cleanly on both PPC and x86, so I think we're in good shape.
Some please review and commit [1].
Committed in r25312, thanks! -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
participants (4)
-
Boey Maun Suang
-
Chuck Remes
-
cremes.devlist＠mac.com
-
Daniel J. Luke