On Tue, Feb 03, 2015 at 03:09:58PM +0100, Stefan Schmidt wrote: > Hello. > > On 30/01/15 10:36, Vasiliy Tolstov wrote: > > 2015-01-30 11:56 GMT+03:00 Martin Jansa <[email protected]>: > >> From package maintainer point of view, it would be much better with preN > >> in filenames. > >> > >> Using the same filenames will cause our source mirrors to keep > >> pre-release tarballs instead of the final ones. So I won't be updating > >> meta-efl OE layer for pre-releases. > > > > Yes, please add prefix to file names or postfix, because archives > > cached and identical file names can create collisions. > > These are not beta tarballs or anything. The intend of them is that they > are _identical_ to the final tarballs. > > Let me explain why I do it like this. I'm willing to listen and maybe > change afterwards. > > When starting with stable update releases we got the request from > packagers that they want to have the tarballs we consider final to give > us feedback on them. > > If nothing shows up, which is the case in 99% of the cases, I will just > move these into the official release folder and thus make them the final > tarballs.
What about moving and renaming tarballs at the same time? > So what you two want would break this use case as I have to change > configure.ac again and re-run distcheck. I don't mind having the "final" version inside the tarballs. Only the tarball filename is the issue for mirrors. When they aren't modified then it's even better for me, because I will just remove "pre" prefix from source URL in bitbake recipes. Re-run build to verify that source checksums are still the same and that I was testing pre-release tarball identical to final one. With the same filename, I still need to update source URL, but also remove old archives from all our source mirrors to ensure that they will be re-downloaded from final location (to catch the 1% case when they are indeed modified after pre-release check). > I personally don't see a big benefit for this pre-release tarballs but > people wanted them so I added them in the process. We they are not > longer wanted/needed I would skip this completely and directly to the > stable release. In 99% of the cases this will just work fine and it > saves me time. The rest 1% would need a instant follow up release but > should still be less time in total. > > regards > Stefan Schmidt > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
