Re: [Fink-devel] Phased decommissioning of the unstable tree.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/30/11 8:06 AM, Alexander Hansen wrote: > As most of you know, it can be a pain to test and roll packages > over to stable from unstable, particularly when they have huge > dependency trees. > > I propose the following phased process: > > Phase 1: Since people have been testing packages (presumably) > before committing them to 10.7/stable, that tree is indeed pretty > stable. We'll start by moving all packages from 10.4/unstable to > 10.4/stable that have identical (or mostly identical) counterparts > in 10.7/stable. Most importantly, we will _delete_ the > descriptions from 10.7/unstable. > > As people continue to add packages to 10.7, they should move them > from 10.4/unstable to 10.4/stable if they're the same version. > > In addition, we'll delete package descriptions from 10.4/unstable > that are identical to those in 10.4/stable. > > Phase 2: Once Phase 1 is finished, we will announce a freeze on new > commits to 10.4/unstable, and we'll start rolling maintained > packages and their dependencies over to stable. > > Once the freeze has been announced all updates should go to the > stable tree henceforth. > > Phase 3: What should be left at this point is unmaintained packages > that nothing else needs. We should test these and see (1) if they > still work, (2) if not, are there newer versions that work or can > easily be made to, and (3) if not, do we bother keeping the > packages. In cases (1) or (2) we roll them to stable. > > Any thoughts on this? I'll take that as a 'no', and we can go ahead and start Phase 1. We are not currently freezing the CVS tree. Maintainers should audit their packages in 10.4 and check for items that are identical in 10.4/stable and 10.4/unstable. Maintainers should also check concerning packages that are identical (or at least close) in 10.7/stable and 10.4/unstable. - -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6KKYYACgkQB8UpO3rKjQ8pawCeOhOTFih0oAZ3EpI082L21YV0 qmMAn2PJlxgHw3Gj8Cb2hfh73UvlFAFc =nvjF -END PGP SIGNATURE- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
On Mon, 03 Oct 2011 17:30:46 -0400, Alexander Hansen wrote: > On 9/30/11 8:06 AM, Alexander Hansen wrote: > > As most of you know, it can be a pain to test and roll packages > > over to stable from unstable, particularly when they have huge > > dependency trees. > > > I propose the following phased process: > > > Phase 1: Since people have been testing packages (presumably) > > before committing them to 10.7/stable, that tree is indeed pretty > > stable. We'll start by moving all packages from 10.4/unstable to > > 10.4/stable that have identical (or mostly identical) counterparts > > in 10.7/stable. Most importantly, we will _delete_ the > > descriptions from 10.7/unstable. > > > As people continue to add packages to 10.7, they should move them > > from 10.4/unstable to 10.4/stable if they're the same version. > > > In addition, we'll delete package descriptions from 10.4/unstable > > that are identical to those in 10.4/stable. > > > Phase 2: Once Phase 1 is finished, we will announce a freeze on new > > commits to 10.4/unstable, and we'll start rolling maintained > > packages and their dependencies over to stable. > > > Once the freeze has been announced all updates should go to the > > stable tree henceforth. > > > Phase 3: What should be left at this point is unmaintained packages > > that nothing else needs. We should test these and see (1) if they > > still work, (2) if not, are there newer versions that work or can > > easily be made to, and (3) if not, do we bother keeping the > > packages. In cases (1) or (2) we roll them to stable. > > > Any thoughts on this? > > I'll take that as a 'no', and we can go ahead and start Phase 1. > > We are not currently freezing the CVS tree. > > Maintainers should audit their packages in 10.4 and check for items > that are identical in 10.4/stable and 10.4/unstable. I just did a full sweep of 10.4/unstable and (with the exception of a few corner cases) purged it of all .info that exactly matched the one in 10.4/stable (and also the parallel-named .patch if there was one for the in-sync .info). I did no testing at all, so if it *was* in stable and somehow broken, it still is just as broken, and I also didn't look at any changed .info, so if it was broken in stable and fixed in unstable or in 10.7 it's still that same way too. dan -- Daniel Macks dma...@netspace.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
Am 04.10.2011 um 07:18 schrieb Daniel Macks: [...] >> I'll take that as a 'no', and we can go ahead and start Phase 1. >> >> We are not currently freezing the CVS tree. >> >> Maintainers should audit their packages in 10.4 and check for items >> that are identical in 10.4/stable and 10.4/unstable. > > I just did a full sweep of 10.4/unstable and (with the exception of a > few corner cases) purged it of all .info that exactly matched the one > in 10.4/stable (and also the parallel-named .patch if there was one for > the in-sync .info). Thanks! > I did no testing at all, so if it *was* in stable > and somehow broken, it still is just as broken, and I also didn't look > at any changed .info, so if it was broken in stable and fixed in > unstable or in 10.7 it's still that same way too. The semi-automatic move of packages from unstable to stable caused some collateral damage in some cases. Namely if multiple .info files shared a single patch file, and some of the .info files and the .patch were moved to stable, but the other .info file(s) were not moved. Example: /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.info /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.patch /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46-10.4.info /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46.patch /sw/fink/10.4/unstable/main/finkinfo/languages/gcc46-x86_64.info Result: gcc46-x86_64.info now does not validate nor build anymore. There is at least one more example: Error: can't find patchfile "./unstable/main/finkinfo/sci/r-cran-sp.patch" Also, one "reverse" case: Validating package file ./stable/main/finkinfo/database/sqlite3-x86_64.info... Error: can't find patchfile "./stable/main/finkinfo/database/sqlite3.patch" Cheers, Max -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
On Oct 5, 2011, at 10:31 AM, Max Horn wrote: > Also, one "reverse" case: > > Validating package file ./stable/main/finkinfo/database/sqlite3-x86_64.info... > Error: can't find patchfile "./stable/main/finkinfo/database/sqlite3.patch" That's my fault. I just deleted sqlite3-x86_64.info since it's been superseded by sqlite3.info. Daniel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/11 10:31 AM, Max Horn wrote: > > Am 04.10.2011 um 07:18 schrieb Daniel Macks: > > [...] > >>> I'll take that as a 'no', and we can go ahead and start Phase >>> 1. >>> >>> We are not currently freezing the CVS tree. >>> >>> Maintainers should audit their packages in 10.4 and check for >>> items that are identical in 10.4/stable and 10.4/unstable. >> >> I just did a full sweep of 10.4/unstable and (with the exception >> of a few corner cases) purged it of all .info that exactly >> matched the one in 10.4/stable (and also the parallel-named >> .patch if there was one for the in-sync .info). > > Thanks! > >> I did no testing at all, so if it *was* in stable and somehow >> broken, it still is just as broken, and I also didn't look at >> any changed .info, so if it was broken in stable and fixed in >> unstable or in 10.7 it's still that same way too. > > The semi-automatic move of packages from unstable to stable caused > some collateral damage in some cases. Namely if multiple .info > files shared a single patch file, and some of the .info files and > the .patch were moved to stable, but the other .info file(s) were > not moved. Example: > > > /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.info > /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.patch > /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46-10.4.info > > > /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46.patch > /sw/fink/10.4/unstable/main/finkinfo/languages/gcc46-x86_64.info > > Result: gcc46-x86_64.info now does not validate nor build anymore. > There is at least one more example: Bad example (but now rectified). This wasn't part of the semi-automatic move. The 'clipper' package which needs gcc46 got moved to stable on 12 September, and I blindly copied just gcc46.info/patch over to stable on the 23rd of September. > > Error: can't find patchfile > "./unstable/main/finkinfo/sci/r-cran-sp.patch" > > Also, one "reverse" case: > > Validating package file > ./stable/main/finkinfo/database/sqlite3-x86_64.info... Error: > can't find patchfile > "./stable/main/finkinfo/database/sqlite3.patch" > > > > Cheers, Max - -- Alexander Hansen, Ph.D. Fink User Liaison http://finkakh.wordpress.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6McDAACgkQB8UpO3rKjQ/gVgCeKUZTjJ+sKv4FxKehKsRkMLbQ oo4AnjR9YDknEOzGwouHBkW93wtTNRS8 =BM7q -END PGP SIGNATURE- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
On Wed, 5 Oct 2011 16:31:56 +0200, Max Horn wrote:
> Am 04.10.2011 um 07:18 schrieb Daniel Macks:
> >
> > I just did a full sweep of 10.4/unstable and (with the exception of
> a > few corner cases) purged it of all .info that exactly matched the
> one > in 10.4/stable (and also the parallel-named .patch if there was
> one for > the in-sync .info).
> >
> > I did no testing at all, so if it *was* in stable > and somehow
> broken, it still is just as broken, and I also didn't look > at any
> changed .info, so if it was broken in stable and fixed in > unstable
> or in 10.7 it's still that same way too. The semi-automatic move of
> packages from unstable to stable caused some collateral damage in
> some cases. Namely if multiple .info files shared a single patch
> file, and some of the .info files and the .patch were moved to
> stable, but the other .info file(s) were not moved.
> [...]
>
> Error: can't find patchfile "./unstable/main/finkinfo/sci/r-cran-sp.patch"
According to 'cvs log' there has *never* been a file by that name there
("it was like that when I got here, honest mom!"). Maintainer cc'ed
dan
--
Daniel Macks
dma...@netspace.org
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
Am 05.10.2011 um 16:56 schrieb Alexander Hansen: [...] >> >> The semi-automatic move of packages from unstable to stable caused >> some collateral damage in some cases. Namely if multiple .info >> files shared a single patch file, and some of the .info files and >> the .patch were moved to stable, but the other .info file(s) were >> not moved. Example: >> >> >> /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.info >> /sw/fink/10.4/stable/main/finkinfo/languages/gcc46.patch >> /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46-10.4.info >> >> >> > /sw/fink/10.4/unstable/main/finkinfo/10.4-EOL/languages/gcc46.patch >> /sw/fink/10.4/unstable/main/finkinfo/languages/gcc46-x86_64.info >> > >> Result: gcc46-x86_64.info now does not validate nor build anymore. >> There is at least one more example: > > Bad example (but now rectified). Thanks, and sorry -- I was blindly assuming that this was due to the moving of packages :). Anyway, glad to hear it is fixed now! Cheers, Max -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
Am 05.10.2011 um 18:41 schrieb Daniel Macks:
> On Wed, 5 Oct 2011 16:31:56 +0200, Max Horn wrote:
>> Am 04.10.2011 um 07:18 schrieb Daniel Macks:
>>>
>>> I just did a full sweep of 10.4/unstable and (with the exception of
>> a > few corner cases) purged it of all .info that exactly matched the
>> one > in 10.4/stable (and also the parallel-named .patch if there was
>> one for > the in-sync .info).
>>>
>>> I did no testing at all, so if it *was* in stable > and somehow
>> broken, it still is just as broken, and I also didn't look > at any
>> changed .info, so if it was broken in stable and fixed in > unstable
>> or in 10.7 it's still that same way too. The semi-automatic move of
>> packages from unstable to stable caused some collateral damage in
>> some cases. Namely if multiple .info files shared a single patch
>> file, and some of the .info files and the .patch were moved to
>> stable, but the other .info file(s) were not moved.
>> [...]
>
>>
>
>> Error: can't find patchfile "./unstable/main/finkinfo/sci/r-cran-sp.patch"
>
> According to 'cvs log' there has *never* been a file by that name there
> ("it was like that when I got here, honest mom!"). Maintainer cc'ed
Thanks! And again, sorry for making the blind assumption this was due to the
move.
Cheers,
Max
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
On 6 Oct 2011, at 21:25, Max Horn wrote:
>
> Am 05.10.2011 um 18:41 schrieb Daniel Macks:
>
>> On Wed, 5 Oct 2011 16:31:56 +0200, Max Horn wrote:
>>> Am 04.10.2011 um 07:18 schrieb Daniel Macks:
I just did a full sweep of 10.4/unstable and (with the exception of
>>> a > few corner cases) purged it of all .info that exactly matched the
>>> one > in 10.4/stable (and also the parallel-named .patch if there was
>>> one for > the in-sync .info).
I did no testing at all, so if it *was* in stable > and somehow
>>> broken, it still is just as broken, and I also didn't look > at any
>>> changed .info, so if it was broken in stable and fixed in > unstable
>>> or in 10.7 it's still that same way too. The semi-automatic move of
>>> packages from unstable to stable caused some collateral damage in
>>> some cases. Namely if multiple .info files shared a single patch
>>> file, and some of the .info files and the .patch were moved to
>>> stable, but the other .info file(s) were not moved.
>>> [...]
>>
>>>
>>
>>> Error: can't find patchfile "./unstable/main/finkinfo/sci/r-cran-sp.patch"
>>
>> According to 'cvs log' there has *never* been a file by that name there
>> ("it was like that when I got here, honest mom!"). Maintainer cc'ed
>
> Thanks! And again, sorry for making the blind assumption this was due to the
> move.
>
Sorry! I csa add/ci-ed to 10.7 but forgot to do cvs add 10.4 tree...
--
BABA Yoshihiko
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Phased decommissioning of the unstable tree.
Hi there, so, we should make sure this plan keeps moving on... Am 30.09.2011 um 14:06 schrieb Alexander Hansen: [..] > Phase 1: > Since people have been testing packages (presumably) before committing > them to 10.7/stable, that tree is indeed pretty stable. We'll start > by moving all packages from 10.4/unstable to 10.4/stable that have > identical (or mostly identical) counterparts in 10.7/stable. Most > importantly, we will _delete_ the descriptions from 10.7/unstable. This has been done. > As people continue to add packages to 10.7, they should move them from > 10.4/unstable to 10.4/stable if they're the same version. I hope this is being done. > > In addition, we'll delete package descriptions from 10.4/unstable that > are identical to those in 10.4/stable. This, too. > > Phase 2: > Once Phase 1 is finished, we will announce a freeze on new commits to > 10.4/unstable, and we'll start rolling maintained packages and their > dependencies over to stable. > > Once the freeze has been announced all updates should go to the stable > tree henceforth. This has not been done yet. In particular, there are still packages that are unstable-only and receive only update there. Also, many maintainers have no direct CVS access, and so can't do this by themselves. We need to offer them help with this, I guess. And I think a large majority of package maintainers has not at all started work on migrating their packages from unstable to stable. There are some bigger blockers, too. E.g. qt4-base-* is unstable-only, so anything depending on it can't be moved. And so on... > > Phase 3: > What should be left at this point is unmaintained packages that > nothing else needs. We should test these and see (1) if they still > work, (2) if not, are there newer versions that work or can easily be > made to, and (3) if not, do we bother keeping the packages. In cases > (1) or (2) we roll them to stable. We are not yet close to phase 3, I guess. Cheers, Max -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
